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: ::= [] where: ::= [] ::= [] ::= [] [] [] [] [[]] [] [] 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: ::= where: ::= [] ::= [] [] [] ::= [] ::= where: ::= [] [] [] [] [] ::= [] 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]