Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Active".
|Authors||Young Lee , Haomian Zheng , Oscar Gonzalez de Dios , Victor Lopez , Zafar Ali|
|RFC stream||Internet Engineering Task Force (IETF)|
RTGDIR Early review (of -19) Has Nits
|Additional resources||Mailing list discussion|
|Stream||WG state||WG Document|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
PCE Working Group Y. Lee (Editor) Internet-Draft SKKU Intended status: Standards Track H. Zheng (Editor) Expires: April 30, 2020. Huawei O. G. de Dios V. Lopez Telefonica Zafar Ali Cisco Systems October 29, 2019 Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks draft-ietf-pce-pcep-stateful-pce-gmpls-12 Abstract The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. 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." Lee & Zheng, et al Expires April 2020 [Page 1] Internet-Draft Stateful PCEP for GMPLS October 2019 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 April 30, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents Table of Contents .............................................. 2 1. Introduction ................................................ 3 2. Conventions used in this document ........................... 4 3. General Context of Stateful PCE and PCEP for GMPLS .......... 4 4. Main Requirements ........................................... 5 5. Stateful PCEP Extensions for GMPLS Networks ................. 6 5.1. Capability Advertisement for Stateful PCEP in GMPLS .... 6 5.2. LSP Synchronization in GMPLS-controlled Networks........ 7 5.3. LSP Delegation and Cleanup ............................ 8 5.4. LSP Operations in Stateful PCEP for GMPLS .............. 8 5.4.1. LSP Update in GMPLS-controlled Networks ........... 8 5.4.2. LSP Initiation in GMPLS-controlled Networks ....... 9 6. Modification of Existing PCEP Messages and Procedures ....... 9 6.1. Modification for LSP Re-optimization ................... 9 6.2. Modification for Route Exclusion ...................... 10 6.2.1. Modification for SRP Object ...................... 11 7. PCEP Object Extensions ..................................... 11 7.1. Generalized Endpoint .................................. 11 7.2. GENERALIZED-BANDWIDTH object .......................... 12 7.3. The LSP Protection Information ........................ 12 Lee & Zheng Expires April 2020 [Page 2] Internet-Draft Stateful PCEP for GMPLS October 2019 7.4. ERO Extension ......................................... 12 7.4.1. ERO with explicit label control .................. 13 7.4.2. ERO with Path Keys ............................... 13 7.5. Switch Layer Object ................................... 14 8. IANA Considerations ........................................ 14 8.1. New PCEP Error Codes .................................. 14 8.2. New Subobject for the Exclude Route Object ............ 14 8.3. New "B" Flag in the SRP Object ........................ 15 9. Manageability Considerations ............................... 15 9.1. Requirements on Other Protocols and Functional Components15 10. Security Considerations ................................... 15 11. Acknowledgement ........................................... 16 12. References ................................................ 16 12.1. Normative References ................................. 16 12.2. Informative References ............................... 16 13. Contributors' Address ..................................... 18 Authors' Addresses ............................................ 19 1. Introduction [RFC4655] presents the architecture of a Path Computation Element (PCE)-based model for computing Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perform such a constrained computation, a PCE stores the network topology (i.e., TE links and nodes) and resource information (i.e., TE attributes) in its TE Database (TED). Such a PCE is usually referred as a stateless PCE. To request path computation services to a PCE, [RFC5440] defines the PCE communication Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE, or between two PCEs. PCEP as specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP extensions needed for GMPLS-controlled networks are provided in [PCEP-GMPLS]. Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [RFC8051]. Further discussion of concept of a stateful PCE can be found in [RFC7399]. In order for these applications to able to exploit the capability of stateful PCEs, extensions to PCEP are required. [RFC8051] describes how a stateful PCE can be applicable to solve various problems for MPLS-TE and GMPLS networks and the benefits it brings to such deployments. [RFC8231] provides the fundamental extensions needed for stateful PCE to support general functionality. Furthermore, [RFC8281] Lee & Zheng Expires April 2020 [Page 3] Internet-Draft Stateful PCEP for GMPLS October 2019 describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC. However, both the documents left out the specification for technology-specific objects/TLVs, and does not cover the GMPLS networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). This document focuses on the extensions that are necessary in order for the deployment of stateful PCEs and the requirements for remote- initiated LSPs in GMPLS-controlled networks. Section 3 provides General context of Stateful PCE and PCEP for GMPLS are provided in Section 3, and PCE initiation requirement for GMPLS is provided in section 4. Protocol extensions is included in section 5, as a solution to address such requirements. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. General Context of Stateful PCE and PCEP for GMPLS This section is built on the basis of Stateful PCE in [RFC8231] and PCEP for GMPLS in [PCEP-GMPLS]. The operation for Stateful PCE on LSPs can be divided into two types, active stateful PCE and passive stateful PCE. For active stateful PCE, PCUpd message is sent from PCE to PCC to update the LSP state for the LSP delegated to PCE. Any changes to the delegated LSPs generate a PCRpt message by the PCC to PCE to convey the changes of the LSP. Any modifications to the Objects/TLVs that are identified in this document to support GMPLS technology- specific attributes will be carried in the PCRpt and PCUpd messages. For passive stateful PCEs, PCReq/PCRep messages are used to convey path computation instructions. GMPLS-technology specific Objects and TLVs are defined in [PCEP-GMPLS], so this document just points at that work and only adds the stateful PCE aspects where applicable. Passive Stateful PCE makes use of PCRpt messages when reporting LSP State changes sent by PCC to PCEs. Any modifications to the Objects/TLVs that are identified in this document to support GMPLS technology-specific attributes will be carried in the PCRpt message. Lee & Zheng Expires April 2020 [Page 4] Internet-Draft Stateful PCEP for GMPLS October 2019 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this document makes use of these Objects/TLVs without modifications where applicable. Some of these Objects/TLVs may require modifications to incorporate stateful PCE where applicable. The remote-initiated LSP would follow the principle specified in [RFC8281], and GMPLS- specific extensions are also included in this document. 4. Main Requirements This section notes the main functional requirements for PCEP extensions to support stateful PCE for use in GMPLS-controlled networks, based on the description in [RFC8051]. Many requirements are common across a variety of network types (e.g., MPLS-TE networks and GMPLS networks) and the protocol extensions to meet the requirements are already described in [RFC8231]. This document does not repeat the description of those protocol extensions. This document presents protocol extensions for a set of requirements which are specific to the use of a stateful PCE in a GMPLS-controlled network. The requirements for GMPLS-specific stateful PCE are as follows: o Advertisement of the stateful PCE capability. This generic requirement is covered in Section 5.4 of [RFC8231], and the GMPLS capability TLV as per [PCE-GMPLS] MUST be advertised as well. This document assumes that STATEFUL-PCE-CAPABILITY TLV specified in [RFC8231] can be used for GMPLS Stateful PCE capability advertisement and there is no further extensions. o Active LSP update is covered in Section 6.2 of [RFC8231]. Section 5.1 of this document provides extension for its application in GMPLS-controlled networks. o LSP state synchronization and LSP state report. This is a generic requirement already covered in Section 5.6. of [RFC8231]. However, there are further extensions required specifically for GMPLS-controlled networks and discussed in Section 5.2. o LSP delegation is already covered in Section 5.7 of [RFC8231]. The delegation procedure is reused in this document without any further extensions. Statement can be found in section 5.3 in this document. o All the PCEP messages need to be capable to indicate GMPLS- specific switching capabilities per TE link basis. GMPLS LSP creation requires knowledge of LSP switching capability (e.g., Lee & Zheng Expires April 2020 [Page 5] Internet-Draft Stateful PCEP for GMPLS October 2019 TDM, L2SC, OTN-TDM, LSC, etc.) to be used according to [RFC3471], [RFC3473]. o In order to create/modify/delete GMPLS LSPs, the PCEP messages also need to indicate knowledge of the encoding type (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) to be used by the LSP according to [RFC3471], [RFC3473]. o GMPLS LSP creation/modification/deletion requires information of the generalized payload (G-PID) to be carried by the LSP per [RFC3471], [RFC3473]. It also requires the specification of data flow specific traffic parameters (also known as Tspec), which are technology specific. Such information would be needed for PCEP message. o GMPLS extends the addressing to include unnumbered interface identifiers, as defined in [RFC3477]. o In some technologies path calculation is tightly coupled with label selection along the route. For example, path calculation in a WDM network may include lambda continuity and/or lambda feasibility constraints and hence a path computed by the PCE is associated with a specific lambda (label). Hence, in such networks, the label information needs to be provided to a PCC in order for a PCE to initiate GMPLS LSPs under the active stateful PCE model, i.e., explicit label control may be required. o Stateful PCEP message also need to indicate the protection context information for the LSP specified by GMPLS, as defined in [RFC4872], [RFC4873]. 5. Stateful PCEP Extensions for GMPLS Networks 5.1. Capability Advertisement for Stateful PCEP in GMPLS Capability Advertisement has been specified in [RFC8231], and can be achieved by using the "STATEFUL-PCE-CAPABILITY TLV". GMPLS- CAPABILITY TLV has been defined in [PCEP-GMPLS], and would be useful for stateful PCEP in GMPLS network as well. Besides the above, this document does not have additional extension regarding the capability advertisement. Lee & Zheng Expires April 2020 [Page 6] Internet-Draft Stateful PCEP for GMPLS October 2019 5.2. LSP Synchronization in GMPLS-controlled Networks PCCs need to report the attributes of LSPs to the PCE to enable stateful operation of a GMPLS network. This process is known as LSP state synchronization. The LSP attributes include bandwidth, associated route, and protection information etc., are stored by the PCE in the LSP database (LSP-DB). Note that, as described in [RFC8231], the LSP state synchronization covers both the bulk reporting of LSPs at initialization as well the reporting of new or modified LSP during normal operation. Incremental LSP-DB synchronization may be desired in a GMPLS-controlled network and it is specified in [RFC8232]. [RFC8231] describes mechanisms for LSP synchronization using the Path Computation State Report (PCRpt) message, but does not cover reporting of technology-specific attributes. As stated in [RFC8231], the <path> construct is further composed of a compulsory Explicit Route Object (ERO) and a compulsory attribute-list and an optional Record Route Object (RRO). In order to report LSP states in GMPLS networks, this specification allows the use within a PCRpt message both of technology- and GMPLS-specific attribute objects and TLVs defined in [PCEP-GMPLS] as follows: o Include Route Object (IRO)/ Exclude Route Object (XRO) Extensions to support the inclusion/exclusion of labels and label sub-objects for GMPLS. (See Section 2.6 and 2.7 in [PCEP- GMPLS]) o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 in [PCEP-GMPLS]) o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 in [PCEP-GMPLS]) o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. The END-POINTS object SHOULD be carried within the attribute-list to specify the endpoints pertaining to the reported LSP. The XRO object MAY be carried to specify the network resources that the reported LSP avoids and a PCE SHOULD consider avoid these network resources during the process of re-optimizing after this LSP is delegated to the PCE. To be more specific, the <attribute-list> is updated as follows using the notations of [RFC5511]: <attribute-list> ::= [<END-POINTS>] [<LSPA>] [<BANDWIDTH>] Lee & Zheng Expires April 2020 [Page 7] Internet-Draft Stateful PCEP for GMPLS October 2019 [<metric-list>] [<IRO>] [<XRO>] <metric-list>::= <METRIC>[<metric-list>] If the LSP being reported protects another LSP, the PROTECTION- ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to describe its attributes and restrictions. Moreover, if the status of the protecting LSP changes from non-operational to operational, the PCC SHOULD synchronize the state change of the LSPs to the stateful PCE using a PCRpt message. This use case arises, for example, when the protecting LSP becomes operational due to the failure of the primary LSP. 5.3. LSP Delegation and Cleanup LSP delegation and cleanup procedure specified in [RFC8231] are equally applicable to GMPLS LSPs and this document does not modify the associated usage. 5.4. LSP Operations in Stateful PCEP for GMPLS Both passive and active stateful PCE mechanism in [RFC8231] are applicable in GMPLS-controlled networks. 5.4.1. LSP Update in GMPLS-controlled Networks [RFC8231] defines the Path Computation LSP Update Request (PCUpd) message to enable to update the attributes of an LSP. However, [RFC8231] does not define technology-specific parameters. A key element of the PCUpd message is the attribute-list construct defined in [RFC5440] and extended by many other PCEP specifications. For GMPLS purposes we note that the BANDWIDTH object used in the attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be included to indicate technology-specific attributes. There are other technology-specific attributes that need to be conveyed in the <intended-attribute-list> of the <path> construct in the PCUpd message. Note that these path details in the PCUpd message are the same as the <attribute-list> of the PCRep message. See Section 5.3 for the details. Lee & Zheng Expires April 2020 [Page 8] Internet-Draft Stateful PCEP for GMPLS October 2019 5.4.2. LSP Initiation in GMPLS-controlled Networks PCInitiate message defined in [RFC8281] needs to be extended in GMPLS network to support the LSP initiation. The extension includes the following objects: 6. Modification of Existing PCEP Messages and Procedures [Editor Notes]: the whole section would need re-working, the objective is to indicate the RBNF model for the PCEP extension, especially where new objects and TLVs are specified. One of the advantages mentioned in [RFC8051] is that the stateful nature of a PCE simplifies the information conveyed in PCEP messages, notably between PCC and PCE, since it is possible to refer to PCE managed state for active LSPs. To be more specific, with a stateful PCE, it is possible to refer to an LSP with a unique identifier in the scope of the PCC-PCE session and thus use such identifier to refer to that LSP. Note this is also applicable to packet networks. 6.1. Modification for LSP Re-optimization The Request Parameters (RP) object on a Path Computation Request (PCReq) message carries the R bit. When set, this indicates that the PCC is requesting re-optimization of an existing LSP. Upon receiving such a PCReq, a stateful PCE SHOULD perform the re- optimization in the following cases: o The existing bandwidth and route information of the LSP to be re-optimized is provided in the PCReq message using the BANDWIDTH object and the ERO. o The existing bandwidth and route information is not supplied in the PCReq message, but can be found in the PCE's LSP-DB. In this case, the LSP MUST be identified using an LSP identifier carried in the PCReq message, and that fact requires that the LSP identifier was previously supplied either by the PCC in a PCRpt message or by the PCE in a PCRep message. [RFC8231] defines how this is achieved using a combination of the per-node LSP identifier (PLSP-ID) and the PCC's address. If no LSP state information is available to carry out re- optimization, the stateful PCE should report the error "LSP state information unavailable for the LSP re-optimization" (Error Type = TBD1, Error value= TBD2). Lee & Zheng Expires April 2020 [Page 9] Internet-Draft Stateful PCEP for GMPLS October 2019 6.2. Modification for Route Exclusion [RFC5521] defines a mechanism for a PCC to request or demand that specific nodes, links, or other network resources are excluded from paths computed by a PCE. A PCC may wish to request the computation of a path that avoids all link and nodes traversed by some other LSP. To this end this document defines a new sub-object for use with route exclusion defined in [RFC5521]. The LSP exclusion sub-object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Type (TBD3) | Length | Attributes | Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Symbolic Path Name // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X bit and Attribute fields are defined in [RFC5521]. Type: Subobject Type for an LSP exclusion sub-object. Value of TBD3. To be assigned by IANA. Length: The Length contains the total length of the subobject in bytes, including the Type and Length fields. Flags: This field may be used to further specify the exclusion constraint with regard to the LSP. Currently, no values are defined. Symbolic Path Name: This is the identifier given to an LSP and is unique in the context of the PCC address as defined in [RFC8231]. Reserved: MUST be transmitted as zero and SHOULD be ignored on receipt. This sub-object is OPTIONAL in the exclude route object (XRO) and can be present multiple times. When a stateful PCE receives a PCReq message carrying this sub-object, it SHOULD search for the identified LSP in its LSP-DB and then exclude from the new path computation all resources used by the identified LSP. If the stateful PCE cannot recognize one or more of the received LSP identifiers, it should send an error message PCErr reporting "The LSP state information for route exclusion purpose cannot be found" Lee & Zheng Expires April 2020 [Page 10] Internet-Draft Stateful PCEP for GMPLS October 2019 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide with the unrecognized identifier information to the requesting PCC using the error reporting techniques described in [RFC5440]. 6.2.1. Modification for SRP Object The format of the SRP object is defined in [RFC8231]. The object is used in PCUpd and PCInitiate messages for GMPLS. This document defines a new flag to be carried in the Flags field of the SRP object. This flag indicates a bidirectional co-routed LSP setup operation initiated by the PCE as follows: o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a request to create a uni-directional LSP. If set to 1, it indicates a request to create a bidirectional co-routed LSP. The bit position is TBD5 as assigned by IANA (see Section 5.3) 7. PCEP Object Extensions 7.1. Generalized Endpoint This document does not modify the usage of END-POINTS object for PCE initiated LSPs as specified in [RFC8281] . It augments the usage as specified below. END-POINTS object has been extended by [PCEP-GMPLS] to include a new object type called "Generalized Endpoint". PCInitiate message sent by a PCE to a PCC to trigger a GMPLS LSP instantiation SHOULD include the END-POINTS with Generalized Endpoint object type. Furthermore, the END-POINTS object MUST contain "label request" TLV. The label request TLV is used to specify the switching type, encoding type and G-PID of the LSP being instantiated by the PCE. If the END-POINTS Object of type Generalized Endpoint is missing the label request TLV, the PCC MUST send a PCErr message with Error- type=6 (Mandatory Object missing) and Error-value= TBA (label request TLV missing). Lee & Zheng Expires April 2020 [Page 11] Internet-Draft Stateful PCEP for GMPLS October 2019 If the PCC does not support the END-POINTS Object of type Generalized Endpoint, the PCC MUST send a PCErr message with Error- type = 3(Unknown Object), Error-value = 2(unknown object type). The unnumbered endpoint TLV can be used to specify unnumbered endpoint addresses for the LSP being instantiated by the PCE. The END-POINTS MAY contain other TLVs defined in [PCEP-GMPLS]. 7.2. GENERALIZED-BANDWIDTH object LSP initiate message defined in [RFC8281] can optionally include the BANDWIDTH object. However, the following possibilities cannot be represented in the BANDWIDTH object: o Asymmetric bandwidth (different bandwidth in forward and reverse direction), as described in [RFC6387]. o Technology specific GMPLS parameters (e.g., Tspec for SDH/SONET, G.709, ATM, MEF, etc.) are not supported. GENERALIZED-BANDWIDTH object has been defined in [PCEP-GMPLS] to address the above-mentioned limitation of the BANDWIDTH object. This document specifies the use of GENERALIZED-BANDWIDTH object in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH object MAY be included in the PCInitiate message. The GENERALIZED-BANDWIDTH object in PCInitiate message is used to specify technology specific Tspec and asymmetrical bandwidth values for the LSP being instantiated by the PCE. 7.3. The LSP Protection Information LSPA in the PCEP message can be used to specify protection attributes of the LSP being instantiated by the stateful PCE. 7.4. ERO Extension GMPLS network does not have special requirement on modifying the usage of ERO object for stateful PCEP in [RFC8231] and PCE initiated LSPs as specified in [RFC8281]. It augments the usage as specified in the following sections. Lee & Zheng Expires April 2020 [Page 12] Internet-Draft Stateful PCEP for GMPLS October 2019 7.4.1. ERO with explicit label control As mentioned earlier, there are technologies and scenarios where active stateful PCE requires explicit label control in order to instantiate an LSP. Explicit label control (ELC) is a procedure supported by RSVP-TE, where the outgoing label(s) is (are) encoded in the ERO. [PCEP-GMPLS] extends the ERO object of PCEP to include explicit label control. The ELC procedure enables the PCE to provide such label(s) directly in the path ERO. The extended ERO object in PCInitiate message can be used to specify label along with ERO to PCC for the LSP being instantiated by the active stateful PCE. 7.4.2. ERO with Path Keys There are many scenarios in packet and optical networks where the route information of an LSP may not be provided to the PCC for confidentiality reasons. A multi-domain or multi-layer network is an example of such networks. Similarly, a GMPLS User- Network Interface (UNI) [RFC4208] is also an example of such networks. In such scenarios, ERO containing the entire route cannot be provided to PCC (by PCE). Instead, PCE provides an ERO with Path Keys to the PCC. For example, in the case UNI interface between the router and the optical nodes, the ERO in the LSP Initiate Message may be constructed as follows: o The first hop is a strict hop that provides the egress interface information at PCC. This interface information is used to get to a network node that can extend the rest of the ERO. (Please note that in the cases where the network node is not directly connected with the PCC, this part of ERO may consist of multiple hops and may be loose). o The following(s) hop in the ERO may provide the network node with the path key [RFC5520] that can be resolved to get the contents of the route towards the destination. o There may be further hops but these hops may also be encoded with the path keys (if needed). Lee & Zheng Expires April 2020 [Page 13] Internet-Draft Stateful PCEP for GMPLS October 2019 This document does not change encoding or processing roles for the path keys, which are defined in [RFC5520]. 7.5. Switch Layer Object [I-D.ietf-pce-inter-layer-ext] specifies the SWITCH-LAYER object which defines and specifies the switching layer (or layers) in which a path MUST or MUST NOT be established. A switching layer is expressed as a switching type and encoding type. [PCEP-GMPLS], which defines the GMPLS extensions for PCEP, suggests using the SWITCH- LAYER object. Thus, SWITCH-LAYER object can be used in the PCInitiate message to specify the switching layer (or layers) of the LSP being remotely initiated. 8. IANA Considerations 8.1. New PCEP Error Codes IANA is requested to make the following allocation in the "PCEP- ERROR Object Error Types and Values" registry. Error Type Meaning Reference TBD1 LSP state information missing [This.I-D] Error-value TBD2: LSP state information unavailable [This.I-D] for the LSP re-optimization Error-value TBD4: LSP state information for route exclusion purpose cannot be found [This.I-D] This document defines the following new Error-Value: Error-Type Error-Value Reference 6 Error-value TBD5: Label Request TLV missing [This.I-D] 8.2. New Subobject for the Exclude Route Object IANA maintains the "PCEP Parameters" registry containing a subregistry called "PCEP Objects". This registry has a subregistry Lee & Zheng Expires April 2020 [Page 14] Internet-Draft Stateful PCEP for GMPLS October 2019 for the XRO (Exclude Route Object) listing the sub-objects that can be carried in the XRO. IANA is requested to assign a further sub- object that can be carried in the XRO as follows: Value Description Reference ----------+------------------------------+------------- TBD3 LSP identifier sub-object [This.I-D] 8.3. New "B" Flag in the SRP Object IANA maintains a subregistry, named the "SRP Object Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the SRP object. IANA is requested to make an assignment from this registry as follows: Bit Description Reference --- ---------------------------- ---------- TDB5 Bi-directional co-routed LSP [This.I-D] 9. Manageability Considerations The description and functionality specifications presented related to stateful PCEs should also comply with the manageability specifications covered in Section 8 of [RFC4655]. Furthermore, a further list of manageability issues presented in [RFC8231] should also be considered. Additional considerations are presented in the next Update. 9.1. Requirements on Other Protocols and Functional Components When the detailed route information is included for LSP state synchronization (either at the initial stage or during LSP state report process), this requires the ingress node of an LSP carry the RRO object in order to enable the collection of such information. 10. Security Considerations This draft provides additional extensions to PCEP so as to facilitate stateful PCE usage in GMPLS-controlled networks, on top of [RFC8231]. The PCEP extensions to support GMPLS-controlled networks should be considered under the same security as for MPLS Lee & Zheng Expires April 2020 [Page 15] Internet-Draft Stateful PCEP for GMPLS October 2019 networks, as noted in [RFC7025]. Therefore, the security considerations elaborated in [RFC5440] still apply to this draft. Furthermore, [RFC8231] provides a detailed analysis of the additional security issues incurred due to the new extensions and possible solutions needed to support for the new stateful PCE capabilities and they apply to this document as well. 11. Acknowledgement We would like to thank Adrian Farrel, Cyril Margaria, George Swallow and Jan Medved for the useful comments and discussions. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017. [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, September 2017. [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, December 2017. [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP extensions for GMPLS", draft-ietf-pce-gmpls-pcep- extensions, work in progress. 12.2. Informative References [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. Lee & Zheng Expires April 2020 [Page 16] Internet-Draft Stateful PCEP for GMPLS October 2019 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful Path Computation Element (PCE) ", RFC 8051, January 2017. [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, September 2017. [I-D.ietf-pce-inter-layer-ext] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-ext. work in progress. [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "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. [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. Lee & Zheng Expires April 2020 [Page 17] Internet-Draft Stateful PCEP for GMPLS October 2019 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, September 2011. 13. Contributors' Address Xian Zhang Huawei Technologies F1 R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972645 Email: email@example.com Dhruv Dhody Huawei Technology India Email: firstname.lastname@example.org Yi Lin Huawei Technologies Email: email@example.com Fatai Zhang Huawei Technologies Email: firstname.lastname@example.org Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Email: email@example.com Siva Sivabalan Cisco Systems Email: firstname.lastname@example.org Clarence Filsfils Cisco Systems Email: email@example.com Lee & Zheng Expires April 2020 [Page 18] Internet-Draft Stateful PCEP for GMPLS October 2019 Robert Varga Pantheon Technologies Email: firstname.lastname@example.org Authors' Addresses Young Lee (Editor) Sung Kyun Kwan University (SKKU) Email: email@example.com Haomian Zheng (Editor) Huawei Technologies H1-1-A043S Huawei Industrial Base, Songshanhu Dongguan, Guangdong 523808 P.R.China Email: firstname.lastname@example.org Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Phone: +34 913374013 Email: email@example.com Victor Lopez Telefonica Email: firstname.lastname@example.org Zafar Ali Cisco Systems Email: email@example.com Lee & Zheng Expires April 2020 [Page 19]