[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-otani-pce-gmpls-aps-req) 00 01 02 03 04 05 06 07 08 09 RFC 7025

Network Working Group                                    Tomohiro Otani
Internet-Draft                                                     KDDI
Intended status: Informational                            Kenichi Ogaki
Expires: January, 2010                                    KDDI R&D Labs
                                                         Diego Caviglia
                                                               Ericsson
                                                            Fatai Zhang
                                                                 Huawei
                                                           July 8, 2009


                 Requirements for GMPLS applications of PCE

               Document: draft-ietf-pce-gmpls-aps-req-01.txt



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   The initial effort of PCE WG is specifically focused on MPLS (Multi-
   protocol label switching). As a next step, this draft describes
   functional requirements for GMPLS (Generalized MPLS) application of
   PCE (Path computation element).


Table of Contents

   Status of this Memo..............................................1
   Abstract.........................................................1
   1. Introduction..................................................3
   2. Conventions used in this document.............................3
   3. GMPLS applications of PCE.....................................3
   4. Requirement for GMPLS application of PCE......................5
   5. Security consideration........................................6

T. Otani et al.  Informational - Expires December 2009         [Page 1]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009
   6. IANA Considerations...........................................7
   7. Acknowledgement...............................................7
   8. Intellectual Property.........................................7
   9. Informative references........................................8
   Author's Addresses...............................................9
   Full Copyright statement.........................................9

















































T. Otani et al.          Expires January 2010                  [Page 2]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009
1. Introduction

   The initial effort of PCE WG is focused on solving the path
   computation problem over different domains in MPLS networks. As the
   same case with MPLS, service providers (SPs) have also come up with
   requirements for path computation in GMPLS networks such as photonics,
   TDM-based or Ethernet-based networks as well.

   [PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for
   PCE on both packet MPLS networks and (non-packet switch capable)
   GMPLS networks. This document complements these documents by
   providing some consideration of GMPLS applications in the intra-
   domain and inter-domain networking environments and indicating a set
   of requirements for the extended definition of series of PCE related
   protocols.

   Constraint based shortest path first (CSPF) computation within a
   domain or over domains for signaling GMPLS Label Switched Paths
   (LSPs) is more stringent than that of MPLS LSPs [MPLS-AS], because
   the additional constraints, e.g., interface switching capability,
   link encoding, link protection capability and so forth need to be
   considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol
   [RFC3471, RFC3473] is designed taking into account bi-directionality,
   switching type, encoding type, SRLG, and protection attributes of the
   TE links spanned by the path, as well as LSP encoding and switching
   type for the end points, appropriately.

   This document provides the investigated results of GMPLS applications
   of PCE for the support of GMPLS path computation. This document also
   provides requirements for GMPLS applications of PCE in the GMPLS
   intra-domain and inter-domain environments.


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].


3. GMPLS applications of PCE

   3.1 GMPLS network model

   Figure 1 depicts a typical network, consisting of several GMPLS
   domains, assumed in this document. D1, D2, D3 and D4 have multiple
   GMPLS inter-domain connections, and D5 has only one GMPLS inter-
   domain connection. These domains follow the definition in [RFC4726].








T. Otani et al.          Expires January 2010                  [Page 3]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009

                     +---------+
           +---------|GMPLS  D2|----------+
           |         +----+----+          |
      +----+----+         |          +----+----+   +---------+
      |GMPLS  D1|         |          |GMPLS  D4|---|GMPLS  D5|
      +----+----+         |          +----+----+   +---------+
           |         +----+----+          |
           +---------|GMPLS  D3|----------+
                     +---------+

                Figure 1: GMPLS Inter-domain network model.

   Each domain is configured using various switching and link
   technologies defined in [Arch] and an end-to-end route needs to
   respect TE link attributes like switching capability, encoding type,
   etc., making the problem a bit different from the case of classical
   (packet) MPLS. In order to route from one GMPLS domain to another
   GMPLS domain appropriately, each domain manages traffic engineering
   database (TED) by PCE, and exchanges or provides route information of
   paths, while concealing its internal topology information.

   3.2 Path computation in GMPLS network

   [CSPF] describes consideration of GMPLS TE attributes during path
   computation.


             Ingress             Transit             Egress
   +-----+   link1-2   +-----+   link2-3   +-----+   link3-4   +-----+
   |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
   |     |<------------|     |<------------|     |<------------|     |
   +-----+   link2-1   +-----+   link3-2   +-----+   link4-3   +-----+

               Figure 2: Path computation in GMPLS networks.


   For the simplicity in consideration, the below basic assumptions are
   made when the LSP is created.

        (1) Switching capabilities of outgoing links from the ingress
            and egress nodes (link1-2 and link4-3 in Figure 2) must be
            consistent with each other.
        (2) Switching capabilities of all transit links including
            incoming links to the ingress and egress nodes (link2-1 and
            link3-4) should be consistent with switching type of a LSP
            to be created.
        (3) Encoding-types of all transit links should be consistent
            with encoding type of a LSP to be created.

   [CSPF] indicates the possible table of switching capability, encoding
   type and bandwidth at the ingress link, transiting links and the
   egress link which need to be satisfied with the created LSP.

   The non-packet GMPLS networks (e.g., TDM networks) are usually
   responsible for transmitting data for the client layer. These GMPLS

T. Otani et al.          Expires January 2010                  [Page 4]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009
   networks can provide different types of connections for customer
   services based on different service bandwidth requests.

   The applications and the corresponding additional requirements for
   applying PCE in non-packet networks, for example, GMPLS-based TDM
   networks, are described in Figure 3. In order to simplify the
   description, this document just discusses the scenario in SDH
   networks as an example. The scenarios in SONET or G.709 ODUk layer
   networks are similar.


                     N1                    N2
    +-----+       +------+              +------+
    |     |-------|      |--------------|      |       +-------+
    +-----+       |      |---|          |      |       |       |
       A1         +------+   |          +------+       |       |
                     |       |             |           +-------+
                     |       |             |              PCE
                     |       |             |
                     |      +------+       |
                     |      |      |       |
                     |      |      |-----| |
                     |      +------+     | |
                     |         N5        | |
                     |                   | |
                  +------+              +------+
                  |      |              |      |        +-----+
                  |      |--------------|      |--------|     |
                  +------+              +------+        +-----+
                     N3                    N4              A2

                       Figure 3: A simple SDH network

   Figure 3 shows a simple network topology, where N1, N2, N3, N4, and
   N5 are all SDH switches. Assume that one Ethernet service with 100M
   bandwidth is required from A1 to A2 over this network. The client
   Ethernet service could be provided by a VC4 connection from N1 to N4,
   and it could also be provided by three concatenated VC3 connections
   (Contiguous or Virtual concatenation) from N1 to N4.

   The type of connection(s) (one VC4 or three concatenated VC3) that is
   required needs to be specified by PCC (e.g., N1 or NMS), but could
   also be determined by PCE automatically based on policy [RFC5394].

   Therefore, the signal type, the type of the concatenation and the
   number of the concatenation should also be considered during path
   computation for PCE.

4. Requirement for GMPLS application of PCE

   In this section, we describe requirements for GMPLS applications of
   PCE in order to establish GMPLS LSP.

   4.1 PCE requirements


T. Otani et al.          Expires January 2010                  [Page 5]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009
   As for path computation in GMPLS networks as discussed in section 3,
   the PCE needs to consider the GMPLS TE attributes appropriately
   according to tables in [CSPF] once a PCC or another PCE requests a
   path computation. Indeed, the path calculation request message from
   the PCC or the PCE needs to contain the information specifying
   appropriate attributes. Additional attributes to those already
   defined in [PCECP] are as follows.

        (1) Switching capability: PSC1-4, L2SC, TDM, LSC, FSC
        (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g.,
            Ethernet, SONET/SDH, Lambda, etc.
        (3) Signal Type: Indicates the type of elementary signal that
            constitutes the requested LSP. A lot of signal types with
            different granularity have been defined in SONET/SDH and
            G.709 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and
            ODU1, ODU2 and ODU3 in G.709 ODUk. See [RFC4606] and
            [RFC4328].
        (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks,
            two kinds of concatenation modes are defined: contiguous
            concatenation which requires co-route for each member signal
            and requires all the interfaces along the path to support
            this capability, and virtual concatenation which allows
            diverse routes for the member signals and only requires the
            ingress and egress interfaces to support this capability.
            Note that for the virtual concatenation, it also may specify
            co-routed or separated-routed. See [RFC4606] and [RFC4328]
            about Concatenation information.
        (5) Concatenation Number: Indicates the number of signals that
            are requested to be contiguously or virtually concatenated.
            Also see [RFC4606] and [RFC4328].
        (6) Wavelength Label: as defined in [Lambda-label]
        (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
            protection, 1:1 protection, (pre-planned) rerouting, etc.
        (8) Administrative group: as defined in [RFC3630]
        (9) Link Protection type: as defined in [RFC4203]


   4.2 PCC requirements

   As described above, a PCC needs to support to initiate path
   computation request specifying abovementioned attributes. Afterwards,
   GMPLS signaling will be invoked according to the responded messages
   from the PCE.

   4.3 GMPLS PCE Management

   PCE related Management Information Bases need to consider extensions
   to be satisfied with requirements for GMPLS applications. For
   extensions, [GMPLS-TEMIB] are defined to manage TE database and may
   be referred to accommodate GMPLS TE attributes in the PCE.


5. Security consideration



T. Otani et al.          Expires January 2010                  [Page 6]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009
   PCE extensions to support GMPLS should be considered under the same
   security as current work. This extension will not change the
   underlying security issues.


6. IANA Considerations

   This document has no actions for IANA.

7. Acknowledgement

   The author would like to express the thanks to Shuichi Okamoto for
   his comments.


8. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   any IETF Document or the extent to which any license under such
   rights might or might not be available; nor does it represent that it
   has made any independent effort to identify any such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.

T. Otani et al.          Expires January 2010                  [Page 7]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009


9. Informative references
   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.
   [PCE-ARCH]     A. Farrel, et al, "A Path Computation Element (PCE)-
                   Based Architecture", RFC4655, Aug., 2006.
   [PCECP-REQ]    J. Ash, et al, "Path computation element (PCE)
                   communication protocol generic requirements", RFC4657,
                   Sept., 2007.
   [MPLS-AS]      R. Zhan, et al, "MPLS Inter-Autonomous System (AS)
                   Traffic Engineering (TE) Requirements", RFC4216,
                   November 2005.
   [CSPF]         T. Otani, et al, "Considering Generalized
                   Multiprotocol Label Switching Traffic Engineering
                   Attributes During Path Computation", draft-otani-
                   ccamp-gmpls-cspf-constraints-07.txt, Feb., 2008.
   [RFC3471]      Berger, L., "Generalized Multi-Protocol Label
                   Switching (MPLS) Signaling Functional Description",
                   RFC 3471, January 2003.
   [RFC3473]      Berger, L., "Generalized Multi-Protocol Label
                   Switching (MPLS) Signaling - Resource ReserVation
                   Protocol Traffic Engineering (RSVP-TE) Extensions",
                   RFC 3473, January 2003.
   [RFC4726]      A. Farrel, et al, "A framework for inter-domain MPLS
                   traffic engineering", RFC4726, November 2006.
   [Arch]         E. Mannie, et al, "Generalized Multi-Protocol Label
                   Switching Architecture", RFC3945, October, 2004.
   [PCECP]        J.P. Vasseur, et al, "Path Computation Element (PCE)
                   Communication Protocol (PCEP)", RFC5440, March 2009.
   [RFC4202]      K. Kompella, and Y. Rekhter, "Routing Extensions in
                   Support of Generalized Multi-Protocol Label
                   Switching", RFC4202, Oct. 2005.
   [RFC4203]      K. Kompella, and Y. Rekhter, "OSPF Extensions in
                   Support of Generalized Multi-Protocol Label
                   Switching", RFC4203, Oct. 2005.
   [RFC4872]      J.P. Lang, Ed., "RSVP-TE Extensions in Support of
                   End-to-End Generalized Multi-Protocol Label Switching
                   (GMPLS) Recovery", RFC4872, May 2007.
   [GMPLS-TEMIB]   T. Nadeau and A. Farrel, Ed., "Generalized
                   Multiprotocol Label Switching (GMPLS) Traffic
                   Engineering Management Information Base", RFC4802,
                   Feb. 2007.
   [RFC3630]      D. Katz et al., "Traffic Engineering (TE) Extensions
                   to OSPF Version 2", RFC3630, September 2003.
   [Lambda-label] T. Otani, Ed., "Generalized Labels for G.694 Lambda-
                   Switching Capable Label Switching Routers", draft-
                   ietf-ccamp-gmpls-g-694-lambda-labels-04.txt, Mar.
                   2009.
   [RFC5394]      I. Bryskin et al., " Policy-Enabled Path Computation
                   Framework", RFC5394, December 2008.
   [RFC4606]      E. Mannie and D. Papadimitriou, "Generalized Multi-
                   Protocol Label Switching (GMPLS) Extensions for
                   Synchronous Optical Network (SONET) and Synchronous


T. Otani et al.          Expires January 2010                  [Page 8]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009

                   Digital Hierarchy (SDH) Control", RFC4606, August
                   2006.
   [RFC4328]      D. Papadimitriou, Ed., "Generalized Multi-Protocol
                   Label Switching (GMPLS) Signaling Extensions for
                   G.709 Optical Transport Networks Control", RFC4328,
                   January 2006.


Author's Addresses

   Tomohiro Otani
   KDDI Corporation
   2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan
   Phone:  +81-3-3347-6006
   Email:  tm-otani@kddi.com

   Kenichi Ogaki
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Fujimino-shi, Saitama 356-8502 Japan
   Phone:  +81-49-278-7897
   Email:  ogaki@kddilabs.jp

   Diego Caviglia
   Ericsson
   16153 Genova Cornigliano, ITALY
   Phone: +390106003736
   Email: diego.caviglia@ericsson.com

   Fatai Zhang
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China
   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com


Full Copyright statement

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE

T. Otani et al.          Expires January 2010                  [Page 9]


   Internet Drafts         Reqs for GMPLS apps of PCE          July 2009

   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.





















































T. Otani et al.          Expires January 2010                 [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/