Network Working Group                                C. Margaria. C, Ed.
Internet-Draft                                               E. Sfeir. E
Intended status: Standards Track                           F. Rambach. F
Expires: June 30, 2010                            Nokia Siemens Networks
                                                  O. Gonzalez de Dios. O
                                                  F. Jimenez Chico. F.J.
                                              Telefonica Investigacion y
                                                              Desarrollo
                                                       December 27, 2009


                       PCEP extensions for GMPLS
              draft-margaria-pce-gmpls-pcep-extensions-00

Abstract

   This memo provides extensions for the Path Computation Element
   communication Protocol (PCEP) for the support of GMPLS control plane.

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.

   This Internet-Draft will expire on June 30, 2010.

Copyright Notice

   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



Margaria. C, et al.       Expires June 30, 2010                 [Page 1]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   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 BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.































Margaria. C, et al.       Expires June 30, 2010                 [Page 2]

Internet-Draft             PCEP Ext for GMPLS              December 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  PCEP requirements  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  PCEP existing objects related to GMPLS . . . . . . . . . .  4
     1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  PCEP objects and extensions  . . . . . . . . . . . . . . . . .  5
     2.1.  Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . .  6
     2.2.  Endpoints encoding . . . . . . . . . . . . . . . . . . . .  8
     2.3.  LABEL SET object . . . . . . . . . . . . . . . . . . . . . 10
     2.4.  LSPA extensions  . . . . . . . . . . . . . . . . . . . . . 11
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13


































Margaria. C, et al.       Expires June 30, 2010                 [Page 3]

Internet-Draft             PCEP Ext for GMPLS              December 2009


1.  Introduction

   PCEP rfcs [RFC5440], [RFC5521], [RFC5541],[RFC5520] are focused on
   path computation requests in MPLS networks.  [RFC4655] defines the
   PCE framework also for GMPLS networks.  This document complements
   these documents by providing some consideration of GMPLS applications
   and routing requests, for example for OTN and WSON networks.

   The requirements on PCE extensions to support those characteristics
   is described in [I-D.ietf-pce-gmpls-aps-req] and
   [I-D.ietf-pce-wson-routing-wavelength].

1.1.  PCEP requirements

   This section provides a set of PCEP requirements to support signal
   compatibility constraints.  When requesting a path computation
   (PCReq) to PCE, the PCC should be able to indicate, according to
   [I-D.ietf-pce-gmpls-aps-req], the following additional attributes:

      (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 [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
      [I-D.ietf-ccamp-gmpls-g-694-lambda-labels]





Margaria. C, et al.       Expires June 30, 2010                 [Page 4]

Internet-Draft             PCEP Ext for GMPLS              December 2009


      (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
      protection, 1:1 protection, (pre-planned) rerouting, etc.

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

   We describe in this document a proposal to fulfill those
   requirements.

1.2.  PCEP existing objects related to GMPLS

   PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext],
   supports the following information (in the PCReq and PCRep) related
   to the described RSVP-TE information.

   From [RFC5440]:

   o  numbered endpoints

   o  bandwidth (float)

   o  ERO

   o  LSP attribute (setup and holding priorities)

   o  Request attribute (include some LSP attributes)

   From [RFC5521]:

   o  Extensions to PCEP for Route Exclusions define a XRO object and a
      new semantic (F bit): Fail bit indicating that the existing route
      is failed and resources present in the RRO can be reused.  This
      object also allows to exclude (strict or not) resources; XRO
      include the diversity level (node, link, SRLG).  The requested
      diversity is expressed in the XRO.

   From [I-D.ietf-pce-inter-layer-ext]:

   o  INTER-LAYER : indicates if inter-layer computation is allowed

   o  SWITCH-LAYER : indicates which layer(s) should be considered, can
      be used to represent the RSVP-TE generalized label request

   o  REQ-ADAP-CAP : indicates the adaptation capabilities requested,
      can also be used for the endpoints in case of mono-layer
      computation

   The shortcomings of the existing PCEP information are:




Margaria. C, et al.       Expires June 30, 2010                 [Page 5]

Internet-Draft             PCEP Ext for GMPLS              December 2009


      BANDWIDTH does not describe the details of the signal (for example
      NVC, multiplier) in the context of TDM or OTN networks.

      END-POINTS does not allow specifying an unnumbered interface, nor
      the labels on the interface.  Those parameters are of interest in
      case of switching constraints.

   Current attributes do not allow to express the requested link level
   protection and end-to-end protection attributes.

   In order to improve the PCEP, a new object is introduced
   (GENERALIZED-BANDWIDTH), a new object type is introduced for the END-
   POINTS object (generalized-unnumbered), and a TLV is added to the
   LSPA object.  In order to allow to restrict the range of labels
   returned, an additional object is added : LABEL SET

1.3.  Requirements Language

   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.


2.  PCEP objects and extensions

   This section describes the required PCEP objects and extensions.  The
   PCReq/PCRep message is defined in [RFC5440], with extensions
   (GENERALIZED BANDWIDTH and LABEL Set)























Margaria. C, et al.       Expires June 30, 2010                 [Page 6]

Internet-Draft             PCEP Ext for GMPLS              December 2009


               <request>::= <RP>
               <END-POINTS>
               [<LSPA>]
               [<BANDWIDTH>]
               [<GENERALIZED-BANDWIDTH>][<GENERALIZED-BANDWIDTH>]
               [<metric-list>]
               [<RRO>[<BANDWIDTH>]
               [<GENERALIZED-BANDWIDTH>][< GENERALIZED-BANDWIDTH>]
               ]
               [<IRO>]
               [<LABEL SET>]
               [<LOAD-BALANCING>]

               <response>::=<RP>
               [<NO-PATH>]
               [<attribute-list>]
               [<path-list>]

               <path-list>::=<path>[<path-list>]

               <path>::= <ERO><attribute-list>


   Where:

               <attribute-list>::=[<LSPA>]
               [<BANDWIDTH>]
               [<GENERALIZED-BANDWIDTH>]
               [<GENERALIZED-BANDWIDTH>]
               [<metric-list>]
               [<IRO>]

2.1.  Traffic parameters encoding, GENERALIZED-BANDWIDTH

   The PCEP BANDWIDTH does not describe the details of the signal (for
   example NVC, multiplier), hence the bandwidth information should be
   extended to use the RSVP Tspec.  The PCEP BANDWIDTH object defines
   two types: 1 and 2.  Ctype 2 is representing the existing bandwidth
   in case of re-optimization.

   The following possibilities cannot be represented in the BANDWIDTH
   object:

   o  Asymmetric bandwidth (different bandwidth in forward and reverse
      direction), as described in [RFC5467]

   o  Optical (SDH/SONET, G.709, ATM, MEF etc) parameters are not
      supported.



Margaria. C, et al.       Expires June 30, 2010                 [Page 7]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   We propose to add a new Object named GENERALIZED-BANDWIDTH having the
   following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Reserved                     |R|O|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Traffic Spec                                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The bits R and O have the following meaning:

      O bit : set when the value refer to the previous bandwidth in case
      of re-optimization

      R bit : set when the value refer to the bandwidth of the reverse
      direction

   The Object type determine which type of bandwidth is represented by
   the object.  The Following object type are defined:

   1.  Intserv

   2.  SONET/SDH

   3.  G.709

   4.  Ethernet MEF (see [I-D.ietf-ccamp-ethernet-traffic-parameters])

   The encoding of the field Traffic Spec is the same as in RSVP-TE, it
   can be found in the following references.

   Object Type  Name        Reference
   2            Intserv     [RFC2210]
   4            SONET/SDH   [RFC4606]
   5            G.709       [RFC4328]
   6 (TBA by    Ethernet    [I-D.ietf-ccamp-ethernet-traffic-parameters]
   IANA)        MEF

                        Traffic Spec field encoding

   The GENERALIZED-BANDWIDTH MAY appear more than once in a PCReq
   message.  If more than one GENERALIZED-BANDWIDTH have the same Object
   Type, Reserved, R and O values, only the first one is processed, the
   others are ignored.  On the response those objects MAY be included.





Margaria. C, et al.       Expires June 30, 2010                 [Page 8]

Internet-Draft             PCEP Ext for GMPLS              December 2009


2.2.  Endpoints encoding

   In GMPLS context the endpoints can:

   o  Be unnumbered

   o  Have label(s) associated to them

   o  May have different switching capabilities

   The traffic type is expressed in the following objects/type:

   o  Endpoint label types (Enc, switch, gpid),

   o  TSPEC: Signal type

   o  SWITCH layer (enc, switching)

   Only the TSPEC and SWITCH layer need to be coherent, the endpoint
   labels could be different The PCE might know the node internal
   adaptation capabilities, and handle the internal routing, but this is
   not a requirement.  Since the PCEP ENDPOINTS object does not support
   unnumbered endpoints information, a new Ctype is proposed.  In any
   case the unnumbered interface id has to be encoded as an object new
   Ctype.  The proposed format is (generalized unnumbered interface id
   endpoint):

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Source LSR's Router ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Source Interface ID (32 bits)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Destination LSR's Router ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Destination Interface ID (32 bits)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                           sub-TLVs                            ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Label or label range may be specified for the TE-LSP endpoints.
   Those are encoded in the sub-TLVs.  The label value cannot be
   interpreted without a description on the Encoding and switching type.
   The REQ-ADAP-CAP object from [I-D.ietf-pce-inter-layer-ext] can be
   used in case of mono-layer request, however in case of multilayer it



Margaria. C, et al.       Expires June 30, 2010                 [Page 9]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   is possible to have in the future more than one object, so it is
   better to have a dedicated subtlv for the label (the scope is then
   more clear).  TLVs are encoded as follow (following [RFC5440]) :

   o  Sub-TLV Label, Type = TBA by IANA, Length is variable, Encoding is
      as follow:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type                  |  Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Enc. Type |Switching Type |             G-PID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                Reserved   |I|U|Label-Type (2) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Label                             |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  Sub-TLV Label Set, Type = TBA by IANA , Length is variable,
      Encoding is as follow:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type                  |  Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Enc. Type |Switching Type |             G-PID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Action     |      Reserved |I|U|        Label Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Subchannel 1                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                               :                               :
     :                               :                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Subchannel N                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   A label subTlv represent the label used on the unnumbered interface,
   bits I and U are used to indicate which exact unnumbered interface/
   direction is considered. the fields are encoded as in the RSVP-TE.
   The Encoding Type indicates the encoding type, e.g., SONET/SDH/GigE



Margaria. C, et al.       Expires June 30, 2010                [Page 10]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   etc., that will be used with the data associated with the LSP.  The
   Switching type indicates the type of switching that is being
   requested on the link.  G-PID identifies the payload of the TE-LSP.
   The label type indicates which type of label (2) for generalized
   label is carried.  A Label Set Sub-TLV represents a set of possible
   labels that can be used on the unnumbered interface.  The action
   parameter in the Label set indicates the type of list provided.
   Those parameters are described by [RFC3471]

                The I and U bits have the following meaning

   I: Ingress bit, set when the label or label set is applicable to the
      ingress endpoint
   U: Upstream direction : set when the label or label set is in the
      reverse direction

2.3.  LABEL SET object

   The LABEL SET object is carried within a PCReq message to restrict
   the set of labels to be assigned during the routing.  Any label
   included in the ERO object on the response must comply with the
   restrictions stated in the LABEL SET, whose encoding is defined as


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Enc. Type |Switching Type |             reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Action     |      Reserved   |U|        Label Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Subchannel 1                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                               :                               :
     :                               :                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Subchannel N                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields and U bit are as defined in Section 2.2, See also
   [RFC3471] and [RFC3473] for the definitions of the fields.

   It is allowed to have more than one LABEL SET object per PCEReq (for
   example in case of multiple SWITCH-LAYER present).




Margaria. C, et al.       Expires June 30, 2010                [Page 11]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   In the case of unsuccessful path computation, the PCRep message also
   contains a NO-PATH object, and the LABEL SET object MAY be used to
   indicate the set of constraint that could not be satisfied.

2.4.  LSPA extensions

   The LSPA carries the LSP attributes.  In the end-to-end protection
   context this also includes the protection state information.  The
   LSPA object can be extended by a protection TLV type: Type TBA by
   IANA: protection attribute

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type                  |  Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|P|N|O|  Reserved | LSP Flags |     Reserved      | Link Flags|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The content is as defined in [RFC4872], [RFC4873].

   LSP Flags can be considered for routing policy based on the
   protection type.  The other attributes are only meaningful for a
   stateful PCE.


3.  IANA Considerations

   A future revision of this document will present requests to IANA for
   codepoint allocation.


4.  Security Considerations

   None.


5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, September 1997.



Margaria. C, et al.       Expires June 30, 2010                [Page 12]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

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

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

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

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

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

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, May 2007.

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

   [RFC5520]  Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
              Topology Confidentiality in Inter-Domain Path Computation
              Using a Path-Key-Based Mechanism", RFC 5520, April 2009.

   [RFC5521]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
              Path Computation Element Communication Protocol (PCEP) for
              Route Exclusions", RFC 5521, April 2009.

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541, June 2009.



Margaria. C, et al.       Expires June 30, 2010                [Page 13]

Internet-Draft             PCEP Ext for GMPLS              December 2009


5.2.  Informative References

   [I-D.ietf-ccamp-ethernet-traffic-parameters]
              Papadimitriou, D., "Ethernet Traffic Parameters",
              draft-ietf-ccamp-ethernet-traffic-parameters-09 (work in
              progress), November 2009.

   [I-D.ietf-ccamp-gmpls-g-694-lambda-labels]
              Otani, T., Tsuritani, T., Li, D., Rabbat, R., Shiba, S.,
              Guo, H., Miyazaki, K., and D. Caviglia, "Generalized
              Labels for Lambda-Switching Capable Label Switching
              Routers", draft-ietf-ccamp-gmpls-g-694-lambda-labels-05
              (work in progress), December 2009.

   [I-D.ietf-pce-gmpls-aps-req]
              Otani, T., Ogaki, K., Caviglia, D., and F. Zhang,
              "Document: draft-ietf-pce-gmpls-aps-req-01.txt",
              draft-ietf-pce-gmpls-aps-req-01 (work in progress),
              July 2009.

   [I-D.ietf-pce-inter-layer-ext]
              Oki, E., Takeda, T., Roux, J., and A. Farrel, "Extensions
              to the Path Computation Element communication Protocol
              (PCEP) for Inter-Layer MPLS and GMPLS Traffic
              Engineering", draft-ietf-pce-inter-layer-ext-03 (work in
              progress), September 2009.

   [I-D.ietf-pce-wson-routing-wavelength]
              Lee, Y., Bernstein, G., Martensson, J., Takeda, T., and T.
              Tsuritani, "PCEP Requirements for WSON Routing and
              Wavelength Assignment",
              draft-ietf-pce-wson-routing-wavelength-00 (work in
              progress), September 2009.

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

   [RFC5467]  Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
              Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
              Switched Paths (LSPs)", RFC 5467, March 2009.











Margaria. C, et al.       Expires June 30, 2010                [Page 14]

Internet-Draft             PCEP Ext for GMPLS              December 2009


Authors' Addresses

   Cyril Margaria (editor)
   Nokia Siemens Networks
   St Martin Strasse 76
   Munich,   81541
   Germany

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


   Elie Sfeir
   Nokia Siemens Networks
   St Martin Strasse 76
   Munich,   81541
   Germany

   Phone: +49 89 5159 16159
   Email: elie.sfeir@nsn.com


   Franz Rambach
   Nokia Siemens Networks
   St Martin Strasse 76
   Munich,   81541
   Germany

   Phone: +49 89 5159 31188
   Email: franz.rambach@nsn.com


   Oscar Gonzalez de Dios
   Telefonica Investigacion y Desarrollo
   C/ Emilio Vargas 6
   Madrid,   28043
   Spain

   Phone: +34 91 3374013
   Email: ogondio@tid.es











Margaria. C, et al.       Expires June 30, 2010                [Page 15]

Internet-Draft             PCEP Ext for GMPLS              December 2009


   Francisco Javier Jimenez Chico
   Telefonica Investigacion y Desarrollo
   C/ Emilio Vargas 6
   Madrid,   28043
   Spain

   Phone: +34 91 3379037
   Email: fjjc@tid.es











































Margaria. C, et al.       Expires June 30, 2010                [Page 16]