PCE Working Group Q. Zhao Internet-Draft Z. Li Intended status: Experimental D. Dhody Expires: September 17, 2016 Huawei Technologies C. Zhou Cisco Systems March 16, 2016 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs draft-zhao-pce-pcep-extension-for-pce-controller-03 Abstract In certain networks deployment scenarios, service providers would like to keep all the existing MPLS functionalities in both MPLS and GMPLS while removing the complexity of existing signalling protocols such as LDP and RSVP-TE. In [I-D.zhao-pce-central-controller-user-cases], we propose to use the PCE [RFC5440] as a central controller (PCECC) so that LSP can be calculated/ signalled/initiated and label forwarding entries are downloaded through a centralized PCE server to each network devices along the LSP path while leveraging the existing PCE technologies as much as possible. This draft specify the procedures and PCEP protocol extensions for using the PCE as the central controller and user cases where LSPs are calculated/setup/initiated and label forwarding entries are downloaded through extending the existing PCE architectures and PCEP. This document also discuss the role of PCECC in Segment Routing (SR). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Zhao, et al. Expires September 17, 2016 [Page 1] Internet-Draft PCECC March 2016 This Internet-Draft will expire on September 17, 2016. Copyright Notice Copyright (c) 2016 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. PCECC Modes . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 5. Procedures for Using the PCE as the Central Controller (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 7 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 7 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 8 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 9 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 5.5.1. Basic PCECC Mode . . . . . . . . . . . . . . . . . . 9 5.5.1.1. PCECC LSP Setup . . . . . . . . . . . . . . . . . 9 5.5.1.2. Label Operations . . . . . . . . . . . . . . . . 11 5.5.2. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 14 5.5.3. PCECC LSP Update . . . . . . . . . . . . . . . . . . 16 5.5.4. PCECC LSP State Report . . . . . . . . . . . . . . . 19 5.5.5. PCECC Segment Routing (SR) . . . . . . . . . . . . . 19 5.5.5.1. PCECC SR-BE . . . . . . . . . . . . . . . . . . . 19 5.5.5.2. PCECC SR-TE . . . . . . . . . . . . . . . . . . . 20 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 22 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 22 6.1.2. The PCInitiate message . . . . . . . . . . . . . . . 23 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 23 7.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . . 23 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 24 Zhao, et al. Expires September 17, 2016 [Page 2] Internet-Draft PCECC March 2016 7.3. Label Object . . . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 25 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Manageability Considerations . . . . . . . . . . . . . . . . 29 9.1. Control of Function and Policy . . . . . . . . . . . . . 29 9.2. Information and Data Models . . . . . . . . . . . . . . . 29 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 29 9.6. Impact On Network Operations . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 Appendix B. Label Range Handling . . . . . . . . . . . . . . . . 32 B.1. Label Range Reservation . . . . . . . . . . . . . . . . . 33 B.2. The PCLRResv message . . . . . . . . . . . . . . . . . . 34 B.3. LABEL-RANGE Object . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction In certain network deployment scenarios, service providers would like to have the ability to dynamically adapt to a wide range of customer's requests for the sake of flexible network service delivery, Software Defined Networks(SDN) has provides additional flexibility in how the network is operated compared to the traditional network. The existing networking ecosystem has become awfully complex and highly demanding in terms of robustness, performance, scalability, flexibility, agility, etc. By migrating to the SDN enabled network from the existing network, service providers and network operators must have a solution which they can evolve easily from the existing network into the SDN enabled network while keeping the network services remain scalable, guarantee robustness and availability etc. Taking the smooth transition between traditional network and the new SDN enabled network into account, especially from a cost impact assessment perspective, using the existing PCE components from the current network to function as the central controller of the SDN network is one choice, which not only achieves the goal of having a centralized controller, but also leverage the existing PCE network components. Zhao, et al. Expires September 17, 2016 [Page 3] Internet-Draft PCECC March 2016 The Path Computation Element communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform route computations in response to Path Computation Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to enable active control of MPLS-TE and GMPLS tunnels. [I-D.ietf-pce-pce-initiated-lsp] describes the setup and tear down of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic MPLS network that is centrally controlled and deployed. [I-D.ietf-pce-remote-initiated-gmpls-lsp] complements [I-D.ietf-pce-pce-initiated-lsp] by addressing the requirements for remote-initiated GMPLS LSPs. Segment Routing (SR) technology leverage the source routing and tunnelling paradigms. A source node can choose a path without relying on hop-by-hop signalling protocols such as LDP or RSVP-TE. Each path is specified as a set of "segments" advertised by link- state routing protocols (IS-IS or OSPF). [I-D.ietf-spring-segment-routing] provides an introduction to SR technology. The corresponding IS-IS and OSPF extensions are specified in [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions], respectively. A Segment Routed path (SR path) can be derived from an IGP Shortest Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE paths) may not follow IGP SPT. Such paths may be chosen by a suitable network planning tool and provisioned on the source node of the SR-TE path. It is possible to use a stateful PCE for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is chosen, the stateful PCE can instantiate an SR-TE path on a PCC using PCEP extensions specified in [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP extensions described in [I-D.ietf-pce-segment-routing]. PCECC may further use PCEP protocol for SR label distribution instead of IGP extensions with some benefits. Current MPLS label has local meaning. That is, MPLS label is always allocated by the downstream node to the upstream node. Then the MPLS label is only identified by the neighbouring upstream node and downstream node. The label allocation is done locally and signalled through the LDP/RSVP-TE/BGP protocol. To ease the label allocation and signalling mechanism, PCE can be conveniently used as a central Zhao, et al. Expires September 17, 2016 [Page 4] Internet-Draft PCECC March 2016 controller with Label download capability. Further PCE can also be used to manage the label range and Segment Routing Global Block (SRGB) etc. The PCECC solution introduced in [I-D.zhao-pce-central-controller-user-cases] allow for a dynamic MPLS network that is eventually controlled and deployed without the deployment of RSVP-TE protocol or extended IGP protocol with node/ adjacency segment identifiers signalling capability while providing all the key MPLS functionalities needed by the service providers. This draft specify the procedures and PCEP protocol extensions for using the PCE as the central controller and user cases where LSPs are calculated/setup/initiated/downloaded through extending the existing PCE architectures and PCEP. 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. IGP: Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS). PCC: Path Computation Client: any client application requesting a path computation to be performed by a 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. TE: Traffic Engineering. 3. PCECC Modes The following PCECC modes are supported - o Basic PCECC. o PCECC SR. Zhao, et al. Expires September 17, 2016 [Page 5] Internet-Draft PCECC March 2016 * PCECC SR-BE (Best Effort). * PCECC SR-TE (Traffic Engineered). In basic PCECC mode, the forwarding is similar to RSVP-TE signalled LSP without the RSVP-TE signalling. The PCECC allocates and download the label entries along the LSP. The rest of processing is similar to the existing stateful PCE mechanism. In case of SR, there are two modes for SR-BE and SR-TE. For SR-BE, the forwarding is similar to LDP LSP without LDP signalling or IGP-SR extension. The SR Node label are allocated and distributed in the domain centrally by the PCE via PCEP. Each node (PCC) relies on local IGP for the nexthop calculation. For SR-TE, the forwarding uses label stack similar to IGP based SR-TE without IGP-SR extension. The SR node and adjacency labels are allocated and distributed in the domain centrally by the PCE via PCEP by PCECC. Rest of the processing is similar to existing stateful PCE with SR mechanism. 4. PCEP Requirements Following key requirements associated PCECC should be considered when designing the PCECC based solution: 1. PCEP speaker supporting this draft MUST have the capability to advertise its PCECC capability to its peers. 2. PCEP speaker not supporting this draft MUST be able to reject PCECC related message with a reason code that indicates no support for PCECC. 3. PCEP SHOULD provide a means to identify PCECC based LSP in the PCEP messages. 4. PCEP SHOULD provide a means to update (or cleanup) the label- download or label-map entry to the PCC. 5. Path Computation Client (PCC) supporting this draft MAY support a capability to communicate local label range or global label range or both to PCE. (see xref target="sec_lr"/>) 6. Path Computation Element (PCE) supporting this draft MAY have the capability to negotiate a global label range for a group of clients and communicate the final global label range to PCC. (see xref target="sec_lr"/>) Zhao, et al. Expires September 17, 2016 [Page 6] Internet-Draft PCECC March 2016 5. Procedures for Using the PCE as the Central Controller (PCECC) 5.1. Stateful PCE Model Active stateful PCE is described in [I-D.ietf-pce-stateful-pce]. PCE as a central controller (PCECC) reuses existing Active stateful PCE mechanism as much as possible to control the LSP. 5.2. New LSP Functions This document defines the following new PCEP messages and extends the existing messages to support PCECC: (PCRpt): a PCEP message described in [I-D.ietf-pce-stateful-pce]. PCRpt message MAYBE used to send PCECC LSP Reports. (PCInitiate): a PCEP message described in [I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message is used to setup PCE-Initiated LSP based on PCECC mechanism. (PCUpd): a PCEP message described in [I-D.ietf-pce-stateful-pce]. PCUpd message is used to send PCECC LSP Update. Per Node Label Operations: a PCEP mechanism to instruct label operations on each node. An approach to this could be - (PCLabelUpd): a new PCEP message sent by a PCE to a PCC to download or cleanup the Label entry. The PCLabelUpd message described in Section 6.1.1. (PCInitiate): reuse an existing PCEP message described in [I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message. The new LSP functions defined in this document are mapped onto the messages as shown in the following table. Zhao, et al. Expires September 17, 2016 [Page 7] Internet-Draft PCECC March 2016 +----------------------------------------+--------------------------+ | Function | Message | +----------------------------------------+--------------------------+ | PCECC Capability advertisement | Open | | Label entry Update | PCLabelUpd/PCInitiate | | Label entry Cleanup | PCLabelUpd/PCInitiate | | PCECC Initiated LSP | PCInitiate | | PCECC LSP Update | PCUpd | | PCECC LSP State Report | PCRpt | | PCECC LSP Delegation | PCRpt | +----------------------------------------+--------------------------+ 5.3. PCECC Capability Advertisement During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of PCECC extensions. A PCEP Speaker includes the "PCECC Capability" TLV, described in Section 7.1.1 of this document, in the OPEN Object to advertise its support for PCECC extensions. The presence of the PCECC Capability TLV in PCC's OPEN Object indicates that the PCC is willing to function as a PCECC client. The presence of the PCECC Capability TLV in PCE's OPEN message indicates that the PCE is interested in function as a PCECC server. The PCEP protocol extensions for PCECC MUST NOT be used if one or both PCEP Speakers have not included the PCECC Capability TLV in their respective OPEN message. If the PCEP Speakers support the extensions of this draft but did not advertise this capability then a PCErr message with Error-Type=19(Invalid Operation) and Error- Value=[TBD] (Attempted LSP setup/download/label-range reservation if PCECC capability was not advertised) will be generated and the PCEP session will be terminated. A PCC or a PCE MUST include both PCECC-CAPABILITY TLV and STATEFUL- PCE-CAPABILITY TLV ([I-D.ietf-pce-stateful-pce]) in OPEN Object to support the extensions defined in this document. If PCECC-CAPABILITY TLV is advertised and STATEFUL-PCE-CAPABILITY TLV is not advertised in OPEN Object, it SHOULD send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=[TBD](stateful PCE capability was not advertised) and terminate the session. PCECC-CAPABILITY TLV includes a S-bit to indicate support for PCECC- SR. A PCEP speaker MUST set S-bit in PCECC-CAPABILITY TLV and include SR-PCE-CAPABILITY TLV ([I-D.ietf-pce-segment-routing]) in OPEN Object to support the PCECC SR-TE extensions defined in this Zhao, et al. Expires September 17, 2016 [Page 8] Internet-Draft PCECC March 2016 document. If S-bit is set in PCECC-CAPABILITY TLV and SR-PCE- CAPABILITY TLV is not advertised in OPEN Object, PCEP speaker SHOULD send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=[TBD](SR capability was not advertised) and terminate the session. 5.4. PCEP session IP address and TEDB Router ID PCE may construct its TEDB by participating in the IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An alternative is offered by BGP-LS [I-D.ietf-idr-ls-distribution] and [I-D.dhodylee-pce-pcep-ls]. PCEP [RFC5440] speaker MAY use any IP address while creating a TCP session. It is important to link the session IP address with the Router ID in TEDB for successful PCECC operations. During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping information. Thus a PCC includes the "Node Attributes TLV" [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", in the OPEN Object for this purpose. [I-D.ietf-idr-ls-distribution] describes the usage as auxiliary Router-IDs that the IGP might be using, e.g., for TE purposes. If there are more than one auxiliary Router-ID of a given type, then multiple TLVs are used to encode them. If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP address is directly used for the mapping purpose. 5.5. LSP Operations The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly identify the PCECC LSP is intended. 5.5.1. Basic PCECC Mode 5.5.1.1. PCECC LSP Setup In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate the LSP by sending a PCRpt message with Path Setup Type set for basic PCECC (see Section 7.2) and D (Delegate) flag (see [I-D.ietf-pce-stateful-pce]) set in the LSP object. LSP-IDENTIFIER TLV MAY be included for PCECC LSP, the LSP-ID SHOULD be generated by the PCE for PCECC LSP. In the first PCRpt message of PCECC LSP, LSP ID of LSP-IDENTIFIER TLV is set to zero. Zhao, et al. Expires September 17, 2016 [Page 9] Internet-Draft PCECC March 2016 When a PCE receives PCRpt message with P and D flags set, it MAY generates LSP ID; calculates the path and assigns labels along the path; and setups the path by sending PCLabelUpd or PCInitiate message to each node along the path of the LSP. In response to the delegate PCRpt message, the PCE SHOULD send the PCUpd message with the same PLSP-ID to the Ingress PCC. The PCECC LSPs MUST be delegated to a PCE at all times. LSP deletion operation for PCECC LSP is same as defined in [I-D.ietf-pce-stateful-pce]. If the PCE receives PCRpt message for LSP deletion then it does Label cleanup operation as described in Section 5.5.1.2.1.2 for the corresponding LSP. The Basic PCECC LSP setup sequence is as shown below using a new message PCLabelUpd. +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP |PCC +--------+ | (LSP ID=0) |(LSPID=1) |Egress | | | | +--------+ | | | | | | | |<------ PCLabelUpd,PLSP-ID=1 ------------------ | Label | | | (LSP ID=1) | download | | | | | |<----- PCLabelUpd,PLSP-ID=1 ----------- | Label | | | (LSP ID=1) | download | | | | | | |<--- PCLabelUpd,PLSP-ID=1 ------- | Label | | | (LSP ID=1) | download | | | | | | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP | | | (LSP ID=1) | Update | | | | Figure 2: Using PCLabelUpd For Label Operations Zhao, et al. Expires September 17, 2016 [Page 10] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP |PCC +--------+ | (LSP ID=0) |(LSPID=1) |Egress | | | | +--------+ | | | | | | | |<------ PCInitiate,PLSP-ID=1 ------------------ | Label | | | (LSP ID=1) | download |------- PCRpt ---------------------------------->| | | | | | |<----- PCInitiate,PLSP-ID=1 ----------- | Label | | | (LSP ID=1) | download | |----- -PCRpt---------------------------->| | | | | | | |<--- PCInitiate,PLSP-ID=1 ------- | Label | | | (LSP ID=1) | download | | |-----PCRpt------------------------>| | | | | | | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP | | | (LSP ID=1) | Update | | | | Some open issue - * PCC send PCRpt messages for each PCInitiate message? * Should one use PCInitiate at Ingress too? How to link this with existing tunnel at the PCC? Figure 3: Using PCInitiate For Label Operations The PCECC LSP are considered to be 'up' by default. The Ingress MAY further choose to deploy a data plane check mechanism and report the status back to the PCE via PCRpt message. 5.5.1.2. Label Operations 5.5.1.2.1. Via a new PCLabelUpd Message The new label operations in PCEP can be done via a new message and by defining new PCEP Objects for Label operations and FEC. Zhao, et al. Expires September 17, 2016 [Page 11] Internet-Draft PCECC March 2016 5.5.1.2.1.1. Label Download In order to setup an LSP based on PCECC, the PCE sends a PCLabelUpd message to each node of the LSP to download the Label entry as described in Section 5.5.1.1. The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV. If a node (PCC) receives a PCLabelUpd message but failed to download the Label entry, it MUST send a PCErr message with Error-type=[TBD] (label download failed) and Error-value=[TBD]. Two new PCEP objects for LABEL and FEC are defined in Section 7.3 and Section 7.4 to encode the Label operations and its associated FEC. 5.5.1.2.1.2. Label Cleanup In order to delete an LSP based on PCECC, the PCE sends a PCLabelUpd message to each node along the path of the LSP to cleanup the Label entry. If the PCC receives a PCLabelUpd message but does not recognize the label, the PCC MUST generate a PCErr message with Error-Type 19(Invalid operation) and Error-Value=3, "Unknown Label". The R flag in SRP object defined in [I-D.ietf-pce-pce-initiated-lsp] specifies the deletion of Label Entry in the new PCLabelUpd message. Zhao, et al. Expires September 17, 2016 [Page 12] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| PCECC LSP |PCC +--------+ | (LSP ID=1) | remove |Egress | | | | +--------+ | | | | | | | |<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label | | | (LSP ID=1, R=1) | cleanup | | | | | |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label | | | (LSP ID=1, R=1) | cleanup | | | | | | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label | | | (LSP ID=1, R=1) | cleanup | | | | 5.5.1.2.2. Via an existing PCInitiate Message The new label operations in PCEP can be done via existing PCInitiate message and by reusing PCEP Objects (and subobjects) to encode Label operations and FEC. A TE LSP can be envisioned as a series of "cross-connects" and ERO in the PCInitiate message can be used to indicate each such cross-connect along the path. The use of PCInitiate message would also require each node to send the PCRpt message. The handling of PLSP-ID, LSP Identifiers, Symbolic path name would need to be taken into consideration. The PATH-SETUP-TYPE TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object can identify the PCECC LSP. 5.5.1.2.2.1. Label Download In order to setup an LSP based on PCECC, the PCE sends a PCInitiate message to each node of the LSP to download the Label entry as described in Section 5.5.1.1 represented as a "cross-connect". If a node (PCC) receives a PCInitiate message with setup type indicated as PCECC, it should not try to initiate a complete tunnel. The error-handling and other processing would remain unchanged. The ERO in the PCInitiate message would indicate the cross-connect as {input interface, input label, output interface, output label}. For Zhao, et al. Expires September 17, 2016 [Page 13] Internet-Draft PCECC March 2016 Egress only input interface/label would be present and for Ingress only output interface/label. For Ingress either PCInitiate is used or the same information can be put in PCUpd message as well. 5.5.1.2.2.2. Label Cleanup In order to delete an LSP based on PCECC, one can use existing PCInitiate message (with R flag) to each node along the path of the LSP to cleanup the Label entry. The R flag in SRP object defined in [I-D.ietf-pce-pce-initiated-lsp] is used during cleanup. The error-handling and other processing would remain unchanged. 5.5.2. PCE Initiated PCECC LSP The LSP Instantiation operation is same as defined in [I-D.ietf-pce-pce-initiated-lsp]. In order to setup a PCE Initiated LSP based on PCECC mechanism, a PCE sends PCInitiate message with Path Setup Type set for basic PCECC (see Section 7.2) to the Ingress PCC. The Ingress PCC MUST also set D (Delegate) flag (see [I-D.ietf-pce-stateful-pce]) and C (Create) flag (see [I-D.ietf-pce-pce-initiated-lsp]) in LSP object of PCRpt message. The PCC responds with first PCRpt message with the status as "GOING- UP" and assigned PLSP-ID. The rest of the PCECC LSP setup operations are same as those described in Section 5.5.1.1. The LSP deletion operation for PCE Initiated PCECC LSP is same as defined in [I-D.ietf-pce-pce-initiated-lsp]. The PCE should further perform Label entry cleanup operation as described in Section 5.5.1.2.1.2 for the corresponding LSP. The PCE Initiated PCECC LSP setup sequence is shown below using a new PCLabelUpd message. Zhao, et al. Expires September 17, 2016 [Page 14] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP |PCC +--------+ | | Initiate |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 | | | | assigned) |<------ PCLabelUpd, PLSP-ID=2 ------------------ | Label | | | (LSP ID=2) | download | | | | | |<----- PCLabelUpd, PLSP-ID=2 ----------- | Label | | | (LSP ID=2) | download | | | | | | |<--- PCLabelUpd, PLSP-ID=2 ------- | Label | | | (LSP ID=2) | download | | | | | | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP | | | (LSP ID=2) | Update | | | | The PCE Initiated PCECC LSP setup sequence is shown below using existing PCInitiate message. Zhao, et al. Expires September 17, 2016 [Page 15] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP |PCC +--------+ | | Initiate |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP +--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2 | | | | assigned) |<------ PCInitiate, PLSP-ID=2 ------------------ | Label | | | (LSP ID=2) | download |------- PCRpt ---------------------------------->| | | | | | |<----- PCInitiate, PLSP-ID=2 ----------- | Label | | | (LSP ID=2) | download | |----- -PCRpt---------------------------->| | | | | | | |<--- PCInitiate, PLSP-ID=2 ------- | Label | | | (LSP ID=2) | download | | |-----PCRpt------------------------>| | | | | | | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP | | | (LSP ID=2) | Update | | | | Some open issue - * PCC send PCRpt messages for each PCInitiate message? * How to link 2 PCInitiate message at Ingress one to initiate the full tunnel, and one to download the cross-connect (label)? 5.5.3. PCECC LSP Update Incase of a modification of PCECC LSP with a new path, a PCE sends a PCUpd message to the Ingress PCC. When a PCC receives a PCUpd message for an existing LSP, a PCC MAY follow the make-before-break procedure i.e. first download labels for the updated LSP and then switch traffic, before cleaning up the old labels. On successful traffic switch over to the new LSP, PCC sends a PCRpt message to the PCE for the deletion of old LSP. Further the PCE does cleanup operation for the old LSP as described in Section 5.5.1.2.1.2. Zhao, et al. Expires September 17, 2016 [Page 16] Internet-Draft PCECC March 2016 The PCECC LSP Update and make-before-break sequence is shown below using a new PCLabelUpd message. +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | | | |PCC +--------+ | | |Egress | | | | +--------+ | | | | | | | Modify LSP |<------ PCLabelUpd, PLSP-ID=1 ------------------ | (LSPID=3 | | | (LSP ID=3) | assigned) | | | | | |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label | | | (LSP ID=3) | download | | | | | | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label | | | (LSP ID=3) | download | | | | | | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC | | | (LSP ID=3) | LSP Update | | | | | | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete | | | (LSP ID=1) | old LSP | | | | |<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label | | | (LSP ID=1, R=1) | cleanup | | | | | |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label | | | (LSP ID=1, R=1) | cleanup | | | | | | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label | | | (LSP ID=1, R=1) | cleanup The PCECC LSP Update and make-before-break sequence is shown below using existing PCInitiate message. Zhao, et al. Expires September 17, 2016 [Page 17] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |Ingress| +-------+ +------| | | | PCC +-------+ | | Transit| | | +------| | | | |PCC +--------+ | | |Egress | | | | +--------+ | | | | | | | Modify LSP |<------ PCInitiate, PLSP-ID=1 ------------------ | (LSPID=3 | | | (LSP ID=3) | assigned) |------- PCRpt ---------------------------------->| | | | | | |<----- PCInitiate, PLSP-ID=1 ----------- | Label | | | (LSP ID=3) | download | |----- -PCRpt---------------------------->| | | | | | | |<--- PCInitiate, PLSP-ID=1 ------- | Label | | | (LSP ID=3) | download | | |-----PCRpt------------------------>| | | | | | | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC | | | (LSP ID=3) | LSP Update | | | | | | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete | | | (LSP ID=1) | old LSP | | | | |<------ PCInitiate, PLSP-ID=1 ------------------ | Label | | | (LSP ID=1, R=1) | cleanup |------- PCRpt ---------------------------------->| | | | | | |<----- PCInitiate, PLSP-ID=1 ----------- | Label | | | (LSP ID=1, R=1) | cleanup | |----- -PCRpt---------------------------->| | | | | | | |<--- PCInitiate, PLSP-ID=1 ------- | Label | | | (LSP ID=1, R=1) | cleanup | | |-----PCRpt------------------------>| The modified PCECC LSP are considered to be 'up' by default. The Ingress MAY further choose to deploy a data plane check mechanism and report the status back to the PCE via PCRpt message. Zhao, et al. Expires September 17, 2016 [Page 18] Internet-Draft PCECC March 2016 5.5.4. PCECC LSP State Report As mentioned before, an Ingress PCC MAY choose to apply any OAM mechanism to check the status of LSP in the Data plane and MAY further send its status in PCRpt message to the PCE. 5.5.5. PCECC Segment Routing (SR) Segment Routing (SR) as described in [I-D.ietf-spring-segment-routing] depends on "segments" that are advertised by Interior Gateway Protocols (IGPs). The SR-node allocates and advertises the SID (node, adj etc) and flood via the IGP. This document proposes a new mechanism where PCE allocates the SID (label) centrally and uses PCEP to advertise the SID. In some deployments PCE (and PCEP) are better suited than IGP because of centralized nature of PCE and direct TCP based PCEP session to the node. PCECC SR capability (S-bit) MUST be advertised in Open message. [EDITOR NOTE: Currently only the use of a new message PCLabelUpd is discussed in this section, the editors feel that use of existing PCInitiate message for SR node and adjacency label would be problematic.] 5.5.5.1. PCECC SR-BE Each node (PCC) is allocated a node-SID (label) by the PCECC. The PCECC sends PCLabelUpd to update the label map of each node to all the nodes in the domain. The TE router ID is determined from the TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. It is RECOMMENDED that PCEP session with PCECC SR capability to use a different session IP address during TCP session establishment than the node Router ID in TEDB, to make sure that the PCEP session does not get impacted by the SR-BE node label maps (Section 5.4). On receiving the label map, each node (PCC) uses the local information to determine the next-hop and download the label forwarding instructions accordingly. The PCLabelUpd message in this case MUST NOT have LSP object but use the new FEC object. Zhao, et al. Expires September 17, 2016 [Page 19] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |3.3.3.3| +-------+ +------| | | | PCC +-------+ | | 2.2.2.2| | | +------| | | | |PCC +--------+ | | |1.1.1.1 | | | | +--------+ | | | | | | | |<------ PCLabelUpd, FEC=1.1.1.1----------------- | Label Map | | | Label=X | update |Find | | | |Nexthop|<----- PCLabelUpd, FEC=1.1.1.1---------- | Label Map |locally| | Label=X | update | | | | | | |<--- PCLabelUpd, FEC=1.1.1.1------ | Label Map | | | Label=X | update | | | | The forwarding behaviour and the end result is similar to IGP based "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node. PCE relies on the Node label cleanup using the same PCLabelUpd message. 5.5.5.2. PCECC SR-TE A Segment Routed Best Effort path (SR-BE path) can be derived from an IGP Shortest Path Tree (SPT) as explained above. On the other hand, SR-TE paths may not follow IGP SPT. Such paths may be chosen by a PCE and provisioned on the source node of the SR-TE path. [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE to compute and initiate SR-TE paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. For SR-TE, apart from node-SID, Adj-SID is used where each adjacency is allocated an Adj-SID (label) by the PCECC. The PCECC sends PCLabelUpd to update the label map of each Adj to the corresponding nodes in the domain. Each node (PCC) download the label forwarding instructions accordingly. Similar to SR-BE, the PCLabelUpd message in this case MUST NOT have LSP object but use the new FEC object. Zhao, et al. Expires September 17, 2016 [Page 20] Internet-Draft PCECC March 2016 +-------+ +-------+ |PCC | | PCE | |3.3.3.3| +-------+ +------| | | | PCC +-------+ | | 2.2.2.2| | | +------| | | | |PCC +--------+ | | |1.1.1.1 | | | | +--------+ | | | | | | | |<------ PCLabelUpd, FEC=10.1.1.1 / ------------- | Label Map | | | 10.1.1.2 | update | | | Label=A | | | | | | |<----- PCLabelUpd, FEC=10.1.1.2--------- | Label Map | | | 10.1.1.1 | update | | | Label=B | | | | | The forwarding behavior and the end result is similar to IGP based "Adj-SID" in SR. The Path Setup Type for segment routing MUST be set for PCECC SR-TE (see Section 7.2). All PCEP procedures and mechanism are similar to [I-D.ietf-pce-segment-routing]. PCE relies on the Adj label cleanup using the same PCLabelUpd message. 6. PCEP messages As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made of a set of objects that can be either mandatory or optional. An object is said to be mandatory in a PCEP message when the object must be included for the message to be considered valid. For each PCEP message type, a set of rules is defined that specify the set of objects that the message can carry. An implementation MUST form the PCEP messages using the object ordering specified in this document. LSP-IDENTIFIERS TLV MAY be included in the LSP object for PCECC LSP. Zhao, et al. Expires September 17, 2016 [Page 21] Internet-Draft PCECC March 2016 6.1. Label Operations 6.1.1. The PCLabelUpd message A new Label Update Message (also referred to as PCLabelUpd) is a PCEP message sent by a PCE to a PCC to download label or update the label map. The same message is also used to cleanup the Label entry. The Message-Type field of the PCEP common header for the PCLabelUpd message is set to [TBD]. The format of the PCLabelUpd message is as follows: ::= Where: ::= [] ::= (|) Where: ::= ::=