Network Working Group                                    Tomohiro                                           T. Otani
Internet-Draft                                                      KDDI
Intended status: Informational                            Kenichi                                  K. Ogaki
Expires: September 13, 2013                               KDDI R&D Labs
                                                         Diego Labs.
                                                             D. Caviglia
                                                                Ericsson
                                                            Fatai
                                                                F. Zhang
                                           Huawei
Expires: December 27, 2012                                June 27, 2012 Technologies Co., Ltd.
                                                                C. Cyril
                                          Nokia Siemens Networks Optical
                                                                    GmbH
                                                          March 12, 2013

               Requirements for GMPLS applications of PCE

               Document: draft-ietf-pce-gmpls-aps-req-06.txt
                  draft-ietf-pce-gmpls-aps-req-07.txt

Abstract

   The initial effort of the 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).

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. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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.

   This Internet-Draft will expire on December 27, 2012.

Abstract

   The initial effort of PCE WG September 13, 2013.

Copyright Notice

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

   This document is specifically focused subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on MPLS (Multi-
   protocol label switching). As a next step, this draft describes
   functional requirements for GMPLS (Generalized MPLS) application the date of
   publication of
   PCE (Path computation element).

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", document.  Please review these documents
   carefully, as they describe your rights and "OPTIONAL" in restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are to be interpreted provided without warranty as
   described in RFC-2119 [RFC2119]. the Simplified BSD License.

Table of Contents

   1.  Introduction ................................................. 2
   2. Terminology .................................................. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.
   2.  GMPLS applications of PCE .................................... 3
      3.1. GMPLS network model .....................................  . . . . . . . . . . . . . . . . . .  3
      3.2.
     2.1.  Path computation in GMPLS network ....................... 4
      3.3.  . . . . . . . . . . . .  3
     2.2.  Unnumbered Interfaces ................................... Interface . . . . . . . . . . . . . . . . . . .  6
      3.4.
     2.3.  Asymmetric Bandwidth Path Computation ...................  . . . . . . . . . .  6
   4.
   3.  Requirements for GMPLS application of PCE ....................  . . . . . . . . . .  6
      4.1.
     3.1.  Requirements of on Path Computation Request ................ . . . . . . . . .  6
      4.2.
     3.2.  Requirements of on Path Computation Reply .................. 8
      4.3. . . . . . . . . . .  7
     3.3.  GMPLS PCE Management .................................... 9
   5. . . . . . . . . . . . . . . . . . . .  8
   4.  Security consideration ....................................... 9
   6. Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations ..........................................  . . . . . . . . . . . . . . . . . . . . .  9
   7.
   6.  Acknowledgement ..............................................  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.
   7.  References ................................................... . . . . . . . . . . . . . . . . . . . . . . . . . .  9
      8.1.
     7.1.  Normative References..................................... References . . . . . . . . . . . . . . . . . . .  9
      8.2.
     7.2.  Informative References................................... 11
   9. References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses ........................................... 13 . . . . . . . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   The initial effort of the PCE WG is focused on solving the path
   computation problem within a domain or 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 GMPLS-
   controlled networks such as wavelength, TDM-based or Ethernet-based
   networks as well.

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

   Note that the requirements for inter-layer traffic engineering
   described in [RFC6457] are outside of the scope of this document.

   Constraint based

   Constraint-based shortest path first (CSPF) computation within a
   domain or over domains for signaling GMPLS Label Switched Paths
   (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216],
   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]. LSPs.  GMPLS signaling
   protocol [RFC3471, RFC3473] [RFC3473] is designed taking into account bi-directionality,
   switching type, encoding type, SRLG, SRLGs and protection attributes of the
   TE links spanned by the path, as well as LSP encoding and switching
   type for of 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 GMPLS intra-domain intra-
   domain and inter-domain environments.

2. Terminology

   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 [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
   inter-domain links, while D5 has only one inter-domain link. These
   domains follow the definition in [RFC4726].

                      +---------+
            +---------|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 [RFC3945] 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.

2.1.  Path computation in GMPLS network

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

   Figure 2 1 depicts a typical GMPLS network, consisting of an ingress
   link, a transit link as well as an egress link, to investigate a
   consistent guideline for GMPLS path computation.  Each link at each
   interface has its own switching capability, encoding type and
   bandwidth.

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

                Figure 2: 1: Path computation in GMPLS networks. 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 1) are 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 are
   consistent with switching type of a LSP to be created.

   (3) Encoding-types of all transit links should be are consistent with encoding
   type of a LSP to be created.

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

   The non-packet GMPLS

   GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are
   usually responsible for transmitting data for the client layer.
   These GMPLS GMPLS-controlled 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 to non-packet networks, to, for example, GMPLS-based TDM networks, are described
   in Figure 3. 2.  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 to this
   scenario.

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

                  Figure 3: 2: A simple TDM(SDH) TDM (SDH) network

   Figure 3 2 shows a simple TDM(SDH) TDM (SDH) 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.

   In this scenario, when the ingress node (e.g., N1) receives a client
   service transmitting request, the type of connections (one VC4 or
   three concatenated VC3) could be determined by PCC (e.g., N1 or NMS),
   but could also be determined by PCE automatically based on policy
   [RFC5394].  If it is determined by PCC, PCC should be capable of
   specifying the ingress node and egress node, signal type, the type of
   the concatenation and the number of the concatenation in a PCReq
   message.  PCE should consider those parameters during path
   computation.  The route information (co-route or separated-route)
   should be specified in a PCRep message if path computation is
   performed successfully.

3.3.

   As described above, PCC should be capable of specifying TE attributes
   defined in the next section and PCE should compute a path
   accordingly.

   Where a GMPLS network is consisting of inter-domain (e.g., inter-AS
   or inter-area) GMPLS-controlled networks, requirements on the path
   computation follows [RFC5376] and [RFC4726].

2.2.  Unnumbered Interfaces Interface

   GMPLS supports unnumbered interface ID that is defined in [RFC 3477], [RFC3477],
   which means that the endpoints of the path may be unnumbered.  It
   should also be possible to request a path consisting of the mixture
   of numbered links and unnumbered links, or a P2MP path with different
   types of endpoints.  Therefore, the PCC should be capable of
   indicating the unnumbered interface ID of the endpoints in the PCReq
   message.

3.4.

2.3.  Asymmetric Bandwidth Path Computation

   As per [RFC6387], GMPLS signaling can be used for setting up an
   asymmetric bandwidth bidirectional LSP.  If a PCE is responsible for
   the path computation, the PCE should be capable of computing a path
   for the bidirectional LSP with asymmetric bandwidth.  It means that
   the PCC should be able to indicate the asymmetric bandwidth
   requirements in forward and reverse directions in the PCReq message.

4.

3.  Requirements for GMPLS application of PCE

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

4.1.

3.1.  Requirements of on Path Computation Request

   As for path computation in GMPLS GMPLS-controlled networks as discussed in
   section 3, 2, the PCE should 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
   must contain the information specifying appropriate attributes.
   According to [RFC5440],[PCEP-EXT],[ PCE-
   WSON-REQ] [RFC5440], [PCE-WSON-REQ] and to RSVP procedures like
   explicit label control(ELC),the additional attributes introduced are
   as follows:
   [RFC5440]

   (1) Switching capability: PSC1-4, L2SC, DCSC [RFC6002], EVPL
   [RFC6004], 802_1 PBB-TE [RFC6060], TDM, lambda, 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] , [RFC4328]and  See [RFC4606], [RFC4328] and [OSPF-G709] or [RSVP-TE-
   G709]. [RSVP-TE-G709].

   (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) Technology specific Technology-specific label(s) such as wavelength label as defined
   in [RFC6205], or labels defined in [RFC4606], [RFC6060]
   [RFC6060], [RFC6002] or [RFC6002]. [RFC6205].

   (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]. [RFC3630]

   (9) Link Protection type: as defined in [RFC4203]. [RFC4203]

   (10)Support for unnumbered interfaces: as defined in [RFC3477]. [RFC3477]

   (11)Support for asymmetric bandwidth request: as defined in
   [RFC6387]. [RFC6387]

   (12)Support for explicit label control during the path computation.

   (13) The PCC/PCE should be able to provide

   (13)Support of label restrictions
   similar to RSVP on in the requests/responses

4.2. requests/responses,
   similarly to RSVP-TE ERO and XRO as defined in [RFC3473] and
   [RFC4874].

3.2.  Requirements of on Path Computation Reply

   As described above, a PCC must support to initiate a PCReq message
   specifying above mentioned attributes. The PCE should compute the path that satisfies the
   constraints which are specified in the PCReq message.  Then the PCE
   should send a PCRep message including the computation result to the
   PCC.  For Path Computation Reply message (PCRep) in GMPLS networks,
   there are some additional requirements.  The PCEP PCRep message must
   be extended to meet the following requirements.

   (1) Concatenation path Path computation with concatenation

   In the case of concatenation path computation, computation involving concatenation, when a PCE
   receives the PCReq message specifying the concatenation constraints
   described in section 4.1, 3.1, the PCE should compute the a path which satisfies the
   specified concatenation constraints. accordingly.

   For contiguous concatenation path computation, the routes of each
   member signal must be co-routed computation involving contiguous concatenation, a single
   route is required and all the interfaces along the route should
   support contiguous concatenation capability.  Therefore, the PCE
   should compute a path based on the contiguous concatenation
   capability of each interface and only one ERO which should carry the
   route information for the response.

   For virtual concatenation path computation, computation involving virtual concatenation, only the
   ingress/egress interfaces need to support virtual concatenation
   capability and
   maybe there are may be diverse routes for the different member
   signals.  Therefore, multiple EROs may be needed for the response.
   Each ERO may represent the route of one or multiple member signals.
   In the case that where one ERO represents several member signals among the
   total member signals, the number of member signals along the route of
   the ERO must be specified.

   (2) Label constraint

   In the case that a PCC doesn't does not specify the label exact label(s) when
   requesting a label-resctricted path and the PCE is capable of
   performing the route computation and label assignment computation
   procedure, the PCE needs to be able to specify the label of the path
   in a PCRep message.

   Wavelength restriction is a typical case of label restriction but is
   only one instance of it. restriction.  More
   generally in GMPLS GMPLS-controlled networks label switching and selection constraint
   constraints may apply and a PCC may request a PCE to take label
   constraint into account and return an ERO containing the labels label or set
   of label that fulfill fulfil the PCC request.

   The PCReq aspects are covered in section 4.1 in the requirements 6,
   12 and 13.

   (3) Roles of the routes

   When a PCC specifies the protection type of an LSP, the PCE should
   compute the working route and the corresponding protection route(s).
   Therefore, the PCRep should be capable of indicating which one is allow to distinguish the working or
   (nominal) and the protection route.

4.3. routes.

3.3.  GMPLS PCE Management

   PCE related

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

5.

4.  Security consideration

   PCE Considerations

   PCEP extensions to support GMPLS should be considered under the same
   security as current PCE work.  This extension will not change the
   underlying security issues.

6.

5.  IANA Considerations

   This document has no actions for IANA.

7.

6.  Acknowledgement

   The author would like to express the thanks to Ramon Casellas, Julien
   Meulic and Shuichi Okamoto for their comments.

8.

7.  References

8.1.

7.1.  Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
             requirements levels", RFC 2119, March 1997.

   [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)
              (GMPLS) Signaling - Resource ReserVation Protocol Traffic Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3477] K.Kompella,et al,"Signalling  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol-Traffic Engineering(RSVP-TE)",January Protocol - Traffic Engineering
              (RSVP-TE)", RFC 3477, January 2003.

   [RFC3630]  Katz, D., Kompella, K., and D. Katz et al., Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC3630, RFC 3630,
              September 2003.

   [RFC3945] E.  Mannie, et al, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC3945, October, RFC 3945, October 2004.

   [RFC4202] K.  Kompella, K. and Y. Rekhter, "Routing Extensions in
              Support of Generalized Multi-Protocol Label Switching",
             RFC4202, Oct. Switching
              (GMPLS)", RFC 4202, October 2005.

   [RFC4203] K.  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
              of Generalized Multi-Protocol Label Switching", RFC4203,
             Oct. Switching (GMPLS)",
              RFC 4203, October 2005.

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

   [RFC6387]  Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
             Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
             Switched Paths (LSPs)", RFC 6387, September 2011.

   [RFC4606]  Mannie, E. Mannie and D. Papadimitriou, "Generalized Multi-
              Protocol Label Switching (GMPLS) Extensions for
              Synchronous Optical Network (SONET) and Synchronous
              Digital Hierarchy (SDH) Control", RFC4606, RFC 4606, August 2006.

   [RFC4802]  Nadeau, T. Nadeau and A. Farrel, Ed., "Generalized Multiprotocol Label
              Switching (GMPLS) Traffic Engineering Management
              Information Base", RFC4802, Feb. RFC 4802, February 2007.

   [RFC4872] J.P.  Lang, Ed., J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
              Extensions in Support of End-to-
             End End-to-End Generalized Multi-Protocol Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC4872, RFC 4872,
              May 2007.

    [RFC5440] J.P. Vasseur, et al,

   [RFC4927]  Le Roux, J., "Path Computation Element (PCE) Communication
              Protocol (PCEP)", RFC5440, March 2009.

   [RFC6002] Lou Berger, et al.,"Generalized (PCECP) Specific Requirements for Inter-Area MPLS (GMPLS) Data Channel
             Switching Capable (DCSC)
              and Channel Set Label Extensions",
             RFC6002, October GMPLS Traffic Engineering", RFC 4927, June 2007.

   [RFC5376]  Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
              Requirements for the Path Computation Element
              Communication Protocol (PCECP)", RFC 5376, November 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

   [RFC6002]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
              Channel Switching Capable (DCSC) and Channel Set Label
              Extensions", RFC 6002, October 2010.

   [RFC6004]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
              for Metro Ethernet Forum and G.8011 Ethernet Service
              Switching", RFC 6004, October 2010.

   [RFC6060] Don  Fedyk, et al., D., Shah, H., Bitar, N., and A. Takacs,
              "Generalized Multiprotocol Label Switching (GMPLS) control Control
              of Ethernet PBB-TE", RFC6060, Provider Backbone Traffic Engineering
              (PBB-TE)", RFC 6060, March 2011.

   [RFC6205] T.  Otani, Ed., T. and D. Li, "Generalized Labels for G.694 Lambda-
             Switching Capable
              Switch-Capable (LSC) Label Switching Routers", RFC6205, RFC 6205,
              March
             2011 2011.

   [RFC6387]  Takacs, et. al., A., Berger, L., Caviglia, D., Fedyk, D., and J.
              Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
              Switched Paths (LSPs)", RFC6387, RFC 6387, September 2011

8.2. 2011.

7.2.  Informative References

   [OSPF-G709]
              Ceccarelli, D., "Traffic Engineering Extensions to OSPF
              for Generalized MPLS(GMPLS) Control of Evolving G.709 OTN
              Networks", draft-ietf-ccamp-gmpls-ospf-g709v3-05 (work in
              progress), January 2013.

   [PCE-WSON-REQ]
              Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
              Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON
              Routing and Wavelength Assignment",
              draft-ietf-pce-wson-routing-wavelength-08 (work in
              progress), October 2012.

   [RFC4216]  Zhang, R. Zhan, et al, and J. Vasseur, "MPLS Inter-Autonomous System
              (AS) Traffic Engineering (TE) Requirements", RFC4216, RFC 4216,
              November 2005.

   [RFC4655]                  A.  Farrel, et al, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC4655, Aug., RFC 4655, August 2006.

   [RFC4657] J.  Ash, et al, J. and J. Le Roux, "Path computation element Computation Element (PCE)
             communication protocol generic requirements", RFC4657,
             Sept., 2007.
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

   [RFC4726] A.  Farrel, et al, A., Vasseur, J., and A. Ayyangar, "A framework Framework for inter-domain MPLS
             traffic engineering", RFC4726,
              Inter-Domain Multiprotocol Label Switching Traffic
              Engineering", RFC 4726, November 2006.

   [RFC4874]  Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
              Extension to Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE)", RFC 4874, April 2007.

   [RFC5394] I. Bryskin et al.,  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC5394, RFC 5394,
              December 2008.

   [RFC6457] T.Takeda,et al,"PCC-PCE  Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
              Discovery Requirements for Inter-Layer
             Engineering",RFC6457,December 2011.

   [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.

   [PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-ietf-
             pce-gmpls-PCEP-EXTs, in progress.

   [PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and
             Wavelength Assignment",draft-ietf-pce-wson-routing-
             wavelength, in progress.

   [OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to
             OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709
             OTN Networks", in progress.
              Engineering", RFC 6457, December 2011.

   [RSVP-TE-G709] Fatai Zhang,et al,"Generalized
              Zhang, F., "Generalized Multi-Protocol Label
             Switching(GMPLS) Switching
              (GMPLS) Signaling Extensions for the evolving G.709
              Optical Transport Network Networks Control",
              draft-ietf-ccamp-gmpls-signaling-g709v3-06 (work in progress.

9.
              progress), January 2013.

Authors' Addresses

   Tomohiro Otani
   KDDI Corporation
   2-3-2 Nishi-shinjuku
   Shinjuku-ku, Tokyo 163-8003
   Japan

   Phone:  +81-3-3347-6006 +81-(3) 3347-6006
   Email: tm-otani@kddi.com

   Kenichi Ogaki
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Fujimino-shi,
   Kamifukuoka, Saitama 356-8502
   Japan

   Phone:  +81-49-278-7897 +81-(49) 278-7897
   Email: ogaki@kddilabs.jp

   Diego Caviglia
   Ericsson
   16153 Genova Cornigliano, ITALY 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 District, Shenzhen 518129
   P.R.China

   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com
   Cyril Margaria
   Nokia Siemens Networks Optical GmbH
   St Martin Strasse 76
   Munich, 81541
   Germany

   Phone: +49 89 5159 16934
   Email: cyril.margaria@nsn.com

Intellectual Property

   The IETF Trust 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
   any 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.

Disclaimer of Validity

   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
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Full Copyright Statement

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.