[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                        Fatai Zhang
Internet Draft                                                Suresh B R
Category: Standards Track                                  SenthilKumarS
                                                                 Jun Sun
                                                                  Huawei
Expires: July 3, 2010                                    January 4, 2010



  Extensions to the Path Computation Element Communication Protocol for
        Traffic Engineering Label Switched Paths in SDH Networks

              draft-zhang-pce-pcep-extensions-for-sdh-00.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.

   This Internet-Draft will expire on July 3, 2010.



Abstract

   [GMPLS-REQ] describes functional requirements for Generalized Multi-
   Protocol Label Switching (GMPLS) application of Path Computation
   Element (PCE). This document explains the application-specific
   extensions for the Path Computation Element Communication Protocol
   (PCEP) to support SDH. PCEP is the communication protocol defined by
   IETF in RFC5440.




zhang                    Expires July 2010                     [Page 1]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


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

Table of Contents


   1. Introduction.................................................2
      1.1. Requirements Language...................................3
   2. Terminology..................................................3
   3. Requirements.................................................3
   4. Protocol Procedure and Extensions............................4
      4.1. RP Object Extension.....................................4
         4.1.1. Requested GMPLS Label Information..................5
      4.2. No-PATH Object Extension................................6
         4.2.1. Extensions to NO-PATH-VECTOR TLV...................6
      4.3. END-POINTS Object Extension.............................7
         4.3.1. Destination Prefix Information TLV.................7
      4.4. New Object - QoS........................................8
         4.4.1. SDH-ASON QoS Parameters TLV........................9
         4.4.2. LSP Protection Information TLV....................13
         4.4.3. QoS Object in PCReq and PCRep.....................15
      4.5. Additional Error Type and Error Values Defined.........16
   5. Manageability Considerations................................17
   6. IANA Considerations.........................................17
      6.1. New PCEP Object........................................17
      6.2. New PCEP TLVs..........................................18
      6.3. PCEP RP Object Flag Field..............................18
      6.4. PCEP NO-PATH-VECTOR TLV Flag Field.....................18
      6.5. New PCEP Error Codes...................................19
   7. Security Considerations.....................................19
   8. References..................................................20
      8.1. Normative References...................................20
      8.2. Informative References.................................20
   9. Authors' Addresses..........................................21


1. Introduction

   RFC4655 defines the PCE based architecture and explains how a PCE may
   compute LSPs in MPLS Traffic Engineering (TE) and GMPLS) networks at
   the request of Path Computation Clients (PCCs).




Zhang                    Expires July 2010                     [Page 2]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   RFC5440 specifies the PCEP for communication between a PCC and a PCE,
   or between two PCEs, in compliance with RFC4657. However, that
   specification does not provide a mechanism to request path
   computation for establishing TE LSPs in SDH network. [GMPLS-REQ]
   addresses the functional requirements for GMPLS in PCE application.

   This document describes the protocol extensions to PCEP to support
   path computation for SDH networks.

1.1. 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 RFC2119.

2. Terminology

   The following terminology is used in this document.

   PCC:  Path Computation Client. Any client application requesting a
      path computation to be performed by the Path Computation Element.

   PCE:  Path Computation Element. An entity (component, application, or
      network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   PCEP:  Path Computation Element Communication Protocol. PCEP is a
      request/response protocol used for the communication between a
      PCC and a PCE, or between two PCEs.

   PCEP Peer:  An element involved in a PCEP session (For example, a PCC
      or a PCE).

   PCEP Session:  The PCEP session is a logical connection established
      automatically between the PCEP peers.

   This document also uses the terminology defined in RFC4655, and
   RFC5440.

3. Requirements

   This section summarizes the PCEP extensions for GMPLS requirements
   specific to SDH networks. This document introduces no new messages
   for PCEP. However, extensions have been introduced to the existing
   PCEP objects, sub-objects and TLVs. Also, few new objects and TLVs



Zhang                    Expires July 2010                     [Page 3]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   have been introduced to support SDH. The details on the PCEP objects
   and TLVs are mentioned below:

   Enhanced Objects

       o  PCEP RP Object
       o  PCEP End Point (IPv4/Node ID) Object

   Newly Introduced Object

      o  PCEP QoS Object

   Newly Introduced TLVs

       o  Requested GMPLS Label
       o  Destination Prefix Information
       o  SONET/SDH QoS Parameters
       o  LSP Protection Information

4. Protocol Procedure and Extensions

4.1. RP Object Extension

   The PCE architecture can be extended to support various network types
   such as SDH, WDM, OTN, PTN and so on. The application-specific PCEP
   requirements and protocol enhancements varies from network to network.
   PCE MAY select the appropriate policy profile depending on the
   current path request which is applicable to a particular network type.

   The PCC can specify its network type in the RP object of the PCEP
   protocol. The RP (Request Parameters) object MUST be carried within
   each PCReq and PCRep messages and MAY be carried within PCNtf and
   PCErr messages. The RP object can handle the requests and responses
   of various network types for the computation of TE LSPs.

   The RP object can also specify the next hop information. The simple
   routing implementation can perform route look-up using the
   destination IP address ignoring the additional information contained
   in the request. More sophisticated routing implementations can use
   additional information contained in the request to influence route
   selection. This additional information includes resource class, input
   network interface, traffic and service parameters.

   The modified RP object carrying the additional information is as
   follows:




Zhang                    Expires July 2010                     [Page 4]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Object Class  |   OT  |Res|P|I|        Object Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  NT |              Flags                          |O|B|R| Pri |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request-ID-number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NT - Network Type (3-bits). This field denotes the network type.

           Bit                    NT Type

           000        DC: Data Communication Networks (default)

           001       SDH: Synchronous Digital Hierarchy Network

           010       WDM: Wavelength Division Multiplexing Network

           011       OTN: Optical Transport Network

           100       PTN: Packet Transport Network

           111       Multi-layered path request

   The RP object carrying bits ranging from 101 to 110 in the NT flag
   must be ignored. In future these bits can be used to represent new
   network types.

4.1.1. Requested GMPLS Label Information

   The Requested GMPLS Label Information TLV is a new OPTIONAL TLV and
   MUST only appear inside RP object. The receiver SHOULD ignore the TLV
   if it appears in any other object other than RP object. This TLV will
   appear only when the resources required are requested using
   generalized label. If multiple instance of this TLV is present, the
   receiver SHOULD accept the first instance and SHOULD ignore the rest.

   The format of Requested GMPLS Label Information TLV is as follows:





Zhang                    Expires July 2010                     [Page 5]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


    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 = 13              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Encoding    |   Switching   |            Carried            |
   |     Type      |      Type     |           Payload ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (16-bits) - Specifies the type of the TLV (Value = 13).

   Length (16-bits) - Specifies the length of the value field (Value =
   4).

   Encoding Type (8-bits) - Specifies the encoding type of the LSP being
   requested.

   The details of Encoding type is discussed in RFC 3471.

   Switching Type (8-bits) - Specifies the switching type requested by
   the LSP.

   The details of Switching type is discussed in RFC 3471.

   Carried Payload ID (16-bits) - Specifies the ID of the payload
   carried by the LSP.

4.2. No-PATH Object Extension

   The NO-PATH object is used in PCRep messages in response to an
   unsuccessful path computation request (the PCE could not find a path
   by satisfying the set of constraints). In this scenario, PCE MUST
   include a NO-PATH object in the PCRep message.

   The N0-PATH object carries the NO-PATH-VECTOR TLV that specifies more
   information on the reasons that led to a negative reply. In case of
   SDH networks there could be some more additional constraints that led
   to the failure like protection mismatch, lack of resources, and so on.
   Few new flags have been introduced in 32-bit flag field of the NO-
   PATH-VECTOR TLV and no modifications have been made in the NO-PATH
   object.

4.2.1. Extensions to NO-PATH-VECTOR TLV

   The modified NO-PATH-VECTOR TLV carrying the additional information
   is as follows:



Zhang                    Expires July 2010                     [Page 6]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


    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 = 1             |           Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Flags                         |N|P|U|U|N|
   |                       Field                         |R|M|S|D|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   New fields PM and NR are defined in the 28th and 27th bit of the
   Flags field respectively.

   PM - Protection Mismatch (1-bit). Specifies the mismatch of the
   protection type in the request.

   NR - No Resource (1-bit). Specifies that the resources are not

   currently sufficient to provide the path.

4.3. END-POINTS Object Extension

   The END-POINTS object is used in a PCReq message to specify the
   source IP address and the destination IP address of the path for
   which a path computation is requested. New OPTIONAL TLVs are defined
   that are to be carried in the END-POINTS object for the path that
   depends on the previous hop address, destination prefix, and
   additional interface information.

4.3.1. Destination Prefix Information TLV

   The Destination Prefix Information TLV is a new OPTIONAL TLV. It MUST
   only appear inside END-POINTS (IPv4/Node ID) object. The receiver
   SHOULD ignore the Destination Prefix Information TLV if it appears in
   any other object other than END-POINTS object. This TLV contains the
   prefix length for the destination IPv4 address and will appear when
   prefix length is in the range between 0 and 32 (inclusive).

   The format of the Destination Prefix Information TLV is as follows:

    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 = 20            |           Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Destination  |     Flags   |E|            Reserved           |
   | Prefix Length |     Field   |M|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Zhang                    Expires July 2010                     [Page 7]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   Destination Prefix Length (8-bits) - Specifies the prefix length of
   the destination IPv4 address.

   Flags Field (7-bits) - Reserved for future to define new flags. It
   MUST be filled with zeros and SHOULD be ignored by the receiver.

   EM- Exact Prefix Match (1-bit) - Specifies whether exact prefix match
   is required for the destination IPv4 address.

      Bit                EM Type

       0       Exact prefix match is not required

       1       Exact prefix match is required

   Reserved (16-bits) - Reserved. MUST be set to zero and SHOULD be
   ignored by the receiver.

4.4. New Object - QoS

   When a PCC requests a PCE for a route, and if PCE provides the
   response to the request, it MAY be useful for the PCC and the PCE to
   include the traffic parameters. These traffic parameters specify a
   base set of capabilities for SDH networks such as Service Level
   Agreement (SLA), protection scheme, segment recovery, concatenation,
   transparency, and so on. The QoS object handles the quality of
   service parameters for TE-LSPs in SDH networks.

   The QoS object can be included in the PCReq and PCRep messages by the
   PCC and PCE respectively. It represents the parameters that become
   necessary to manage bandwidth in the networks. When a PCE cannot find
   a path by satisfying a set of constraints requested by the PCC, the
   PCE may also include the original constraint so as to indicate the
   reason for an unsuccessful computation in the NO-PATH object. Based
   on the available service parameters proposed by a PCE, the PCC MAY
   decide to resend the path requests. These parameters ensure that the
   applications are guaranteed the network resources they need, despite
   varying traffic load.

   The format of the QoS object is as follows:









Zhang                    Expires July 2010                     [Page 8]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Object Class  |   OT  |Res|P|I|        Object Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         SDH-ASON QoS                        //
   |                         Parameters TLV                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                   LSP Protection Information                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Object Class (8-bits) - Specifies the class of the object (Value =
   25).

   OT - Object Type (4-bits) - Specifies the type of the object (Value =
   1).

   Object Length (16-bits) - Specifies the length of the object (Value =
   16).

   Res - Reserved (2-bits). It MUST be set to zero on transmission and
   MUST be ignored on receipt.

   P - Processing Rule (1-bit). The P flag allows a PCC to specify in a
   PCReq message sent to a PCE whether the object must be taken into
   account by the PCE during path computation or is just optional. When
   the P flag is set, the object MUST be taken into account by the PCE.
   Conversely, when the P flag is cleared, the object is optional and
   the PCE can ignore it.

   I - Ignore (1-bit). The I flag is used by a PCE in a PCRep message to
   indicate to a PCC whether an optional object is processed or not. The
   PCE MAY include the ignored optional object in its reply and set the
   I flag to indicate that the optional object was ignored during path
   computation. When the I flag is cleared, the PCE indicates that the
   optional object was processed during the path computation. The
   setting of the I flag for optional objects are purely indicative and
   optional. The I flag has no meaning in a PCRep message when the P
   flag has been set in the corresponding PCReq message.

4.4.1. SDH-ASON QoS Parameters TLV

   The SDH-ASON QoS Parameters TLV is a new OPTIONAL TLV. It MUST only
   appear inside QoS object. The receiver SHOULD ignore the SDH-ASON QoS
   Parameters TLV if it appears in any other object other than QoS
   object. Only one instance of this TLV MUST be present inside QoS


Zhang                    Expires July 2010                     [Page 9]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   object. This TLV contains the parameters such as signal-type,
   Requested Contiguous Concatenation (RCC), multiplier, Number of
   Virtual Components (NVC), Number of Contiguous Concatenation (NCC),
   transparency, and profile.

   The format of the SDH-ASON QoS Parameters TLV is as follows:

    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 = 34            |          Length = 16          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  |      RCC      |        Multiplier (MT)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NVC               |                NCC            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Transparency (T)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Profile (P)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (16-bits) - Specifies the type of the TLV (Value = 34).

   Length (16-bits) - Specifies the length of the value field (Value =
   16).

   ST - Signal Type (8-bits). Specifies the type of elementary signal
   that comprises the requested LSP. Several transforms can be applied
   successively on the elementary signal to build the final signal being
   actually requested for the LSP.

   Each transform application is optional and must be ignored if zero,
   except the Multiplier (MT) that cannot be zero and is ignored if
   equal to one.

   Transforms must be applied strictly in the following order:

   o  First, contiguous concatenation (by using the RCC and NCC fields)
      can be optionally applied on the elementary signal, resulting in
      a contiguously concatenated signal.

   o  Second, virtual concatenation (by using the NVC field) can be
      optionally applied on the elementary signal resulting in
      virtually concatenated signal.





Zhang                    Expires July 2010                    [Page 10]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   o  Third, some transparency (by using the Transparency field) can be
      optionally specified when requesting a frame as signal rather
      than an SPE or VC based signal.

   o  Fourth, a multiplication (by using the MT field) can be optionally
      applied either directly on the elementary signal, or on the
      contiguously concatenated signal obtained from the first phase,
      or on the virtually concatenated signal obtained from the second
      phase, or on these signals combined with some transparency.

   The permitted values for SDH-ASON are as follows:

      Bit       Type (Elementary Signal)
       1        VT1.5  SPE / VC-11
       2        VT2    SPE / VC-12
       4        VT6    SPE / VC-2
       5        STS-1  SPE / VC-3
       6        STS-3c SPE / VC-4
       7        STS-1      / STM-0 (only when requesting transparency)
       8        STS-3      / STM-1 (only when requesting transparency)
       9        STS-12     / STM-4 (only when requesting transparency)
      10        STS-48     / STM-16(only when requesting transparency)
      11        STS-192    / STM-64(only when requesting transparency)
      12        STS-768    / STM-256(only when requesting transparency)

   RCC - Requested Contiguous Concatenation (8 bits). This field is used
   to request the optional SDH contiguous concatenation of the
   elementary signal. This field is a vector of flags. Each flag
   indicates the support of a particular type of contiguous
   concatenation. Several flags can be set at the same time to indicate
   a choice.

   All the bits should be cleared if contiguous concatenation is not
   requested. A non-zero field indicates that some contiguous
   concatenation is requested.

   NCC - Number of Contiguous Components (16 bits). Specifies the number
   of identical SDH VCs (for example, elementary signal) that are
   requested to be concatenated, as specified in the RCC field.

   When requesting a transparent STS-N/STM-N signal limited to a single
   contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be
   STS-N/STM-N, RCC with flag 1 and NCC set to 1. The NCC value must be
   consistent with the type of contiguous concatenation being requested
   in the RCC field. In particular, this field is irrelevant if no
   contiguous concatenation is requested (RCC = 0), in that case it must
   be set to zero when sent, and should be ignored when received. A RCC


Zhang                    Expires July 2010                    [Page 11]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   value different from 0 must imply a number of contiguous components
   greater than 1.

   NVC - Number of Virtual Components (16 bits). Specifies the number of
   signals that are requested to be virtually concatenated. These
   signals are all of the same type by definition. They are elementary
   signal SPEs/VCs for which signal types are VT1.5_SPE/VC-11, VT2_SPE/
   VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS-3c_SPE/VC-4.

   This field is set to 0 (default value) to indicate that no virtual
   concatenation is requested.

   MT - Multiplier (16 bits). Specifies the number of identical signals
   that are requested for the LSP to form the final signal. These
   signals can be either identical elementary signals, or identical
   contiguous concatenated signals, or identical virtual concatenated
   signals. Note that all these signals belong to the same LSP.

   This field is set to one (default value) to indicate that exactly one
   instance of a signal is being requested.

   T - Transparency (32 bits). Specifies a vector of flags that
   indicates the type of transparency being requested. Several flags can
   be combined to provide different types of transparency. Not all
   combinations are necessarily valid. The default value for this field
   is zero, which means no transparency is requested.

   Note as well that transparency is only applicable when using the
   following signal types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, STS-
   48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one
   transparency type must be specified when requesting such a signal
   type.

   The different transparency flags are the following:

   o  Flag 1 (bit 1): Section/Regenerator Section layer
   o  Flag 2 (bit 2): Line/Multiplex Section layer

   Where bit 1 is the low order bit. Other flags are reserved, they
   should be set to zero when sent, and should be ignored when received.
   A flag is set to one to indicate that the corresponding transparency
   is requested.

   P - Profile (32 bits). This field is intended to indicate particular
   capabilities that must be supported for the LSP, for example
   monitoring capabilities.



Zhang                    Expires July 2010                    [Page 12]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   No standard profile is currently defined and this field SHOULD be set
   to zero when transmitted and SHOULD be ignored when received. In the
   future TLV based extensions may be created.

4.4.2. LSP Protection Information TLV

   This is a new OPTIONAL TLV and MUST only appear inside QoS object.
   This TLV contains the constraints related to protection which
   includes SLA, protection scheme, segment recovery, and so on.

   The format of the LSP Protection Information TLV is as follows:

    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 = 40            |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|U|S|D|D|L|R|              Reserved             |R|I|O|N|W|E|P|
   |T|P|H|T|P|E|R|                                   | |P| | |P|P|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protection  |    Segment    |           Associated          |
   |     Scheme    |    Recovery   |             LSP ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (16-bits) - Specifies the type of the TLV (Value = 40).

   Length (16-bits) - Specifies the length of the value field (Value =
   8).

   Protection Flags

   o  ET - Extra Traffic Flag (1-bit). Specifies the extra traffic flag.
      It basically stands for the iron traffic that is preemptible. The
      LSP should use links that are protecting other (primary) traffic.
      Such LSPs may be preempted when the links carrying the (primary)
      traffic fails.

   o  UP - Unprotected Flag (1-bit).  Specifies the unprotected traffic,
      copper. The LSP will not use any link layer protection.

   o  SH - Shared Flag (1-bit).  Specifies the shared traffic, silver. A
      shared link layer protection scheme, such as 1:N protection,
      should be used to support the LSP.

   o  DT - Dedicated 1:1 Flag (1-bit).  Specifies the dedicated 1:1
      service, gold. A dedicated link layer protection scheme (1:1
      protection) should be used to support the LSP.


Zhang                    Expires July 2010                    [Page 13]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   o  DP - Dedicated 1+1 Flag (1-bit).  Specifies the dedicated 1+1
      service, diamond. A dedicated link layer protection scheme (1+1
      protection) should be used to support the LSP.

   o  LE - Link Enhanced Flag (1 bit).  Specifies the enhanced features
      for a link, where a protection scheme that is more reliable than
      dedicated 1+1 should be used, such as 4 fiber BLSR/MS-SPRING.

   o  RR - Reroute Flag (1-bit).  Specifies the reroute flag. If set the
      service is rerouted.

   Reserved (18 bits) - Reserved for future. This field MUST be set to
   zero on transmission and MUST be ignored on receipt.

   Additional Protection Flags

   o  R - Required Flag (1-bit).

   o  IP - In Place Flag (1-bit).

   o  O - Operational Flag (1 bit).

   o  N - Change Notification Flag (1-bit).  Specifies the change in the
      protection flags.

   o  WP - Working or Protection Flag (1-bit).  Specifies the working
      LSP (bit value = 0) or protection LSP (bit value = 1).

   o  EP - Extended Protection Flag (1-bit).

   o  PS - Primary or Secondary Flag (1-bit).  Specifies whether to
      signal and reserve the resources of the primary LSP (bit value =
      0) or secondary LSP (bit value = 1).

   Protection Scheme (8-bits) - Specifies the protection scheme of the
   LSP. It can carry the following values based on the requested
   protection type:

       Value            Protection Scheme Type

       0x00      No end-to-end protection (iron service)

       0x01      Reroute protection (silver service)

       0x02      1:1 protection without extra traffic (gold service)

       0x03      1+1 protection and is uni-directional (diamond service)


Zhang                    Expires July 2010                    [Page 14]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


       0x04      1+1 protection, and is bi-directional (diamond service)

       0x05      Reserved for new protection schemes

       0xFE      Reserved for new protection schemes

       0xFF      Reserved for future

   Segment Recovery (8-bits) - Specifies the recovered segment of the
   LSP.

   Associated LSP ID (16-bits) - Specifies the LSP ID of the associated
   service. During re-routing or optimization, the traffic prevents the
   route of the associated one.

4.4.3. QoS Object in PCReq and PCRep

   As mentioned earlier the QoS object MAY be included in the PCReq
   message specifying the traffic parameters. This object is OPTIONAL,
   and if present only one instance of SDH-ASON QoS parameters TLV or
   LSP protection TLV must be included. If multiple instances of TLV or
   some other TLV is present, then the complete message has to be
   discarded without performing any further processing.

   The format of the PCReq message including the QoS object is as
   follows:

   <PCReq Message> ::= <Common Header>
                       [<svec-list>]
                       <request-list>

   where:

          <svec-list> ::= <SVEC>[<svec-list>]

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

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



Zhang                    Expires July 2010                    [Page 15]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   The format of the PCRep message is as follows:

   <PCRep Message> ::= <Common Header>
                       <response-list>

   where:

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

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

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

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

   where:

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

          <metric-list> ::= <METRIC>[<metric-list>]

4.5. Additional Error Type and Error Values Defined

   A PCEP-ERROR object is used to report a PCEP error and is
   characterized by an Error-Type that specifies the type of error and
   an Error-value that provides additional information about the error
   type. An additional error type and few error values are defined to
   represent some of the errors related to the newly identified objects
   related to SDH networks.

   For each PCEP error, an Error-Type and an Error-value are defined.
   Error-Type 1 to 10 are already defined in RFC5440. Additional Error-
   values are defined for Error-Type 10 and a new Error-Type 14 is
   introduced.

     Error-Type          Error-value

         10        Reception of an invalid object




Zhang                    Expires July 2010                    [Page 16]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


                   Error-value=2: Requested GMPLS Label information TLV
                                 missing in RP object.

                   Error-value=3: LSP Protection Information TLV missing
                                 in QoS object.

                   Error-value=4: TLV missing in QoS object.

                   Error-value=5: Multiple instance of TLV present in
                                 QoS object.

                   Error-value=6: Unsupported TLV present in QoS object.

                   Error-value=7: SONET/SDH QoS parameters TLV missing
                                 in QoS object.

         14        Path computation failure

                   Error-value=1: Unacceptable response message.

                   Error-value=2: QoS object missing in request message.

5. Manageability Considerations

   Liveness Detection and Monitoring

   This document makes no change to the basic operation of PCEP and so
   there are no changes to the requirements for liveness detection and
   monitoring set out in RFC4657 and RFC5440.

6. IANA Considerations

   IANA assigns values to the PCEP protocol objects and TLVs. IANA is
   requested to make some allocations for the newly defined objects and
   TLVs introduced in this document. Also, IANA is requested to manage
   the space of flags that are newly added in the TLVs.

6.1. New PCEP Object

   IANA is requested to make some allocations for the QoS object:

   Object-Class Value         Name              Reference
         25             QoS Object-Type-1   This document (section 4.4)






Zhang                    Expires July 2010                    [Page 17]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


6.2. New PCEP TLVs

   IANA is requested to create a registry for the following TLVs:

    Value         Meaning                         Reference

      13   Requested GMPLS Label            This document (section 4.1.1)

      20   Destination Prefix Information   This document (section 4.3.1)

      34   SDH-ASON QoS Parameters          This document (section 4.4.1)

      40   LSP Protection Information       This document (section 4.4.2)

6.3. PCEP RP Object Flag Field

   IANA is requested to create a registry to manage the Flag field of
   the RP object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Name Flag

   o  Reference

   Code space of the Flag field (RP object).

   Bit Number       Name                 Reference

      0,1,2    Network Type (NT)         This document (section 4.1)

6.4. PCEP NO-PATH-VECTOR TLV Flag Field

   IANA is requested to create a registry to manage the Flag field of
   the NO-PATH-VECTOR TLV.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Name Flag

   o  Reference


Zhang                    Expires July 2010                    [Page 18]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   Code space of the Flag field (NO-PATH-VECTOR TLV).

   Bit Number     Name                   Reference

     27       No Resource (NR)           This document (section 4.2.1)

     28       Protection Mismatch (PM)   This document (section 4.2.1)

6.5. New PCEP Error Codes

   As descried in Section 4.5, new PCEP Error-Type and Error Values are
   defined. IANA is requested to manage the code space of the Error
   object.

   Error-Type          Error-value

      10          Reception of an invalid object

                  Error-value=2: Requested GMPLS Label information TLV
                                 missing in RP object.

                  Error-value=3: LSP Protection Information TLV missing
                                 in QoS object.

                  Error-value=4: TLV missing in QoS object.

                  Error-value=5: Multiple instance of TLV present in QoS
                                 object.

                  Error-value=6: Unsupported TLV present in QoS object.

                  Error-value=7: SONET/SDH QoS parameters TLV missing in
                                 QoS object.

      14          Path computation failure

                  Error-value=1: Unacceptable response message.

                  Error-value=2: QoS object missing in request message.

7. Security Considerations

   The protocol extensions defined in this document do not substantially
   change the nature of PCEP. Therefore, the security considerations set
   out in RFC5440 apply unchanged.




Zhang                    Expires July 2010                    [Page 19]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


8. References

8.1. Normative References

   [GMPLS-REQ]  Otani, Ogaki, Caviglia, and Fatai Zhang, "Requirements
                for GMPLS applications of PCE", July 2009.

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

   [RFC3209]    Bradner, S., "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", March 1997.

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

   [RFC3477]    Kompella, K. and Y. Rekhter, "Signaling Unnumbered Links
                in Resource Reservation Protocol - Traffic Engineering
                (RSVP-TE)", January 2003.

   [RFC4090]    Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
                Extensions to RSVP-TE for LSP Tunnels", May 2005.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", May 2008.

8.2. Informative References

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

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

   [RFC4657]    Ash, J. and J. Roux, "Path Computation Element (PCE)
                Communication Protocol Generic Requirements", September
                2006.

   [RFC4674]    Roux, J., "Requirements for Path Computation Element
                (PCE) Discovery", October 2006.

   [RFC5088]    Roux, J., "OSPF Protocol Extensions for PCE Discovery",
                January 2008.



Zhang                    Expires July 2010                    [Page 20]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   [RFC5440]    Ash, J. and J. Roux, "Path Computation Element (PCE)
                communication Protocol (PCEP)", March 2009.

9. Authors' Addresses


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

   Suresh BR
   Huawei Technologies
   Shenzhen
   China
   Email: sureshbr@huawei.com

   SenthilKumar S
   Huawei Technologies
   Shenzhen
   China
   Email: senthilkumars@huawei.com

   Jun Sun
   Huawei Technologies
   Shenzhen
   China
   Email: sunjun@huawei.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



Zhang                    Expires July 2010                    [Page 21]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010


   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.



Zhang                    Expires July 2010                    [Page 22]


draft-zhang-pce-pcep-extensions-for-sdh-00.txt             January 2010



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.





































Zhang                    Expires July 2010                    [Page 23]