PCE Working Group Quintin Zhao Internet-Draft Katherine Zhao Intended status: Standards Track Robin Li Expires: Auguest 5, 2014 Dhruv Dhody Huawei Technologies Boris Zhang Telus Ltd. Feb 2014 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs draft-zhao-pce-pcep-extension-for-pce-controller-00 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 signaling protocols such as LDP and RSVP-TE. In [I-D.draft-zhao-pce-central-controller-user-cases], we propose to use the PCE as a central controller so that LSP can be calculated/ signaled/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. 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." This Internet-Draft will expire on August 5, 2014. Zhao, et al. Expires August 5, 2014 [Page 1] Internet-Draft PCECC November 2013 Copyright Notice Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4. Procedures for Using the PCE as the Central Controller (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Procedure-1 for PCECC Capability Advertisement . . . . . . 7 4.2. Procedure-2 for PCECC's Label Resource Reservations . . . 8 4.3. Procedure-3 for PCECC for LSP Setup in the New PCECC Enabled Network . . . . . . . . . . . . . . . . . . . . . 9 4.4. Procedure-4 for PCECC for LSP Setup in the Network Migration . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Procedure-5 for Using Extended PCEP to download LSP information for Each Network Device . . . . . . . . . . . 10 5. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. PCEP Extension for Label Range Reservation Request . . 12 5.1.2. PCEP Extension for Label Range reservation Notify . . 13 5.1.3. The LSP Setup Request Message . . . . . . . . . . . . 14 5.1.4. The LSP Delete Request Message . . . . . . . . . . . . 14 5.1.5. PCEP Extension for LFIB Entry Downloading . . . . . . 15 5.1.6. PCEP Extension for LFIB Entry Cleanup . . . . . . . . 16 5.1.7. The PCErr Message . . . . . . . . . . . . . . . . . . 17 5.2. Object Formats . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . 17 5.2.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . 17 5.2.2. SRQ Object . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Manageability Considerations . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Zhao, et al. Expires August 5, 2014 [Page 2] Internet-Draft PCECC November 2013 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Zhao, et al. Expires August 5, 2014 [Page 3] Internet-Draft PCECC November 2013 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 leverages the existing PCE network components. 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 draft [I-D. draft-ietf-pce- stateful-pce] describes a set of extensions to PCEP to enable active control of MPLS-TE and GMPLS tunnels. [I-D. draft-ietf-pce-pce-initiated-lsp] describes the setup and teardown 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.draft-ali-pce-remote-initiated-gmpls-lsp-01] complements [I-D. draft-ietf-pce-pce-initiated-lsp] by addressing the requirements for remote-initiated GMPLS LSPs. Segment Routing (SR) technology leverages the source routing and tunneling paradigms. A source node can choose a path without relying on hop-by-hop signaling 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.filsfils-rtgwg-segment-routing] provides an introduction to SR technology. The corresponding IS-IS Zhao, et al. Expires August 5, 2014 [Page 4] Internet-Draft PCECC November 2013 and OSPF extensions are specified in [I-D.previdi-isis-segment- routing-extensions] and [I-D.psenak-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.draft-sivabalan-pce-segment-routing]. By using the solutions provided from above drafts, LSP in both MPLS and GMPLS network can be setup/delete/maintained/synchronized through a centrally controlled dynamic MPLS network. Since in these solutions, either the LSP is need to be signaled through the head end LER to the tail end LER, RSVP-TE signaling protocol need to be deployed in the MPLS/GMPLS network, or extend IGP protocol with node/ adjacency segment identifiers signaling capability to be deployed. The PCECC solution introduced in [I-D.draft-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 signaling capability while providing all the key MPLS functionalities needed by the service providers. In the case that one LSP path consist legacy network nodes and the new network nodes which are centrally controlled, the PCECC solution provides a smooth transition steps for the users. 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. 2. Terminology The following terminology is used in this document. Zhao, et al. Expires August 5, 2014 [Page 5] Internet-Draft PCECC November 2013 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. 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. Path Computation Element (PCE) supporting this draft MUST have the capability to negotiate a global label range for a group of clients. 3. Path Computation Client (PCC) MUST be able ask for global label range assigned in a request message . 4. PCE are not required to support label range reserve service. Therefore, it MUST be possible for a PCE to reject a label range reserve message with a reason code that indicates no support for label reserve service. 5. PCEP SHOULD provide a means to return global label range and LSP label assignments of the computed path in a reply message. 6. PCEP SHOULD provide a means to request for LSP setup in the request message. 7. PCEP SHOULD provide a means to download the MPLS forwarding entry to the PCECC's clients. 4. Procedures for Using the PCE as the Central Controller (PCECC) The procdures specified in this document are based on the following PCECC architecture. Zhao, et al. Expires August 5, 2014 [Page 6] Internet-Draft PCECC November 2013 +------------------------------------------------------------------+ | PCECC | | +-----------------------------------------------------+ | | | LSP-Database RSVP-TE Signal Control Module | | | | TE-Database LDP signaling Control Module | | | | Label-Database LP/label/TE MGRs | | | +-----------------------------------------------------+ | | ^ ^ ^ ^ ^ | | IGP|LDP/RSVP-TE |PCEP |PCEP PCEP| IGP|LDP/RSVP-TE| | |PCEP | | | |PCEP | | V V V V V | | +--------+ +--------+ +--------+ +--------+ +--------+ | | |NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | |...| |...| |...| |...| | | | | Legacy |IGP| |IGP| |IGP| PCC4 |IGP| Legacy | | | | Node | | | | | | | | Node | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | +------------------------------------------------------------------+ Through the draft, we call the combination of the functionality for global label range signaling and the functionality of LSP setup/ download/cleanup using the combination of global labels and local labels as PCECC functionality. 4.1. Procedure-1 for 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 5.2.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 cental controller for LSP setup/download/label-reservation. 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 with error-type TBD (Invalid Operation), error-value TBD (Attempted LSP setup/download/label-reservarion if PCECC capability was not advertised) will be generated and the PCEP session will be Zhao, et al. Expires August 5, 2014 [Page 7] Internet-Draft PCECC November 2013 terminated. 4.2. Procedure-2 for PCECC's Label Resource Reservations 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 neighboring upstream node and downstream node. The label allocation is done locally and signaled through the LDP/RSVP-TE/BGP protocol. To ease the label allocation and signaling mechanism, also with the new applications such as centralized LSP controllers are introduced, PCE can be conveniently used as a central controller and MPLS global label range negotiator. The label range reservation procedures are based on network configurations illustrated using the following figure: +------------------------------+ +------------------------------+ | PCE DOMAIN 1 | | PCE DOMAIN 2 | | +--------+ | | +--------+ | | | | | | | | | | | PCECC1 |<------------------------>| PCECC2| | | | | | | | | | | | | | | | | | | +--------+ | | +--------+ | | ^ ^ | | ^ ^ | | / \ | | / \ | | V V | | V V | | +--------+ +--------+ | | +--------+ +--------+ | | |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | | | | ...... | | | | | | ...... | | | | | PCECC | | PCECC | | | | PCECC | |PCECC | | | |Enabled | | Enabled| | |Enabled | |Enabled | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | +------------------------------+ +------------------------------+ Procedure-2 for global Label Range Reservation o Node11 sends a label request message to PCECC1 with global label reservation range 100 to 1000. o PCECC1 sends a reply message with global label reservation range 100 to 1000 confirmed to node1, ..., node1n o PCECC1 sends a indication message with global label reservation range 100 to 1000 confirmed to PCECC2. Zhao, et al. Expires August 5, 2014 [Page 8] Internet-Draft PCECC November 2013 o PCECC2 sends indication messages with global label reservation range 100 to 1000 confirmed to Node21,..., node2n 4.3. Procedure-3 for PCECC for LSP Setup in the New PCECC Enabled Network Procedure-3-1: Tunnel Head End PCC-Initiated LSP Setup Using Global Label Range Reserved o Node1 sends a path request message for LSP setup from Node11 to Node2n. o PCE1 sends a indication message LSP setup with [Label(to2n), Node2n] to Node12, ..., Node1n. o PCE1 sends a indication message LSP setup with [Label(to2n), Node2n] to PCE2; o PCE2 sends a indication message LSP setup with [Label(to2n), Node2n] to Node22, ..., Node2n. Procedure-3-2: LSP Delete Using global Label Range Reserved o Node1 sends a path request message for LSP cleanup from Node11 to Node2n. o PCE1 sends a indication message LSP cleanup with [Label(to2n), Node2n] to Node12, ..., Node1n. o PCE1 sends a indication message LSP cleanup with [Label(to2n), Node2n] to PCE2; o PCE2 sends a indication message LSP cleanup with [Label(to2n), Node2n] to Node22, ..., Node2n. 4.4. Procedure-4 for PCECC for LSP Setup in the Network Migration procedure-4 is based on network configurations illustrated using the following figure: Zhao, et al. Expires August 5, 2014 [Page 9] Internet-Draft PCECC November 2013 +------------------------------------------------------------------+ | PCE DOMAIN | | +-----------------------------------------------------+ | | | PCECC | | | +-----------------------------------------------------+ | | ^ ^ ^ ^ | | |if11 RSVP-TE | if33 if44|RSVP-TE |i55 | | V V V V | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | |...| |...| |...| |...| | | | | Legacy |if1| Legacy |if2|PCCEC |if3| PCECC |if4| Legacy | | | | Node | | Node | |Enabled | |Enabled | | Node | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | +------------------------------------------------------------------+ Procedures for Using PCECC Initiated LSP Setup In the Network Migration In this scenaro, there are multiple nodes for the LSP from head end (node1) to the tail end (node5). Where the node3 and node4 with the PCECC capability, and other nodes are legacy nodes. o Node1 sends a path request message for LSP setup to Node5. o PCE sends a reply message for LSP setup with path (node1, i1), (node2, i2), (node-PCECC, if33), (node-PCECC, if55), Nnode5. o PCE sends an indication message for LSP segment setup with [Label(toN5), Node5] for node3 to node4. o Node1, Node2, Node-PCECC, Node-PCECC, Node 5 will setup the LSP to Node5 normally using the local label as normal. After the LSP is setup, then the PCECC will program the node 3 and node 4 to replace the LSP segment from node3-node-PCECC-node5 to node3- node4-node5. 4.5. Procedure-5 for Using Extended PCEP to download LSP information for Each Network Device The existing PCEP is used to communicate between the PCE server and PCC for exchanging the path request and reply information regarding to the LSP info. With minor extensions, we can use the PCEP to download the complete LSP forwarding entries for each node in the network. Zhao, et al. Expires August 5, 2014 [Page 10] Internet-Draft PCECC November 2013 In procedure-5, the LSP segment between node3 and node4 for destination node5 is setup from PCECC and downloaded into node3 and node4 directly from PCECC through the extended PCEP. +------------------------------------------------------------------+ | PCE DOMAIN | | +-----------------------------------------------------+ | | | PCECC | | | +-----------------------------------------------------+ | | PCEP | PCEP| | | MPLS Forwarding | | MPLS Forwarding | | Entry Download V V Entry Download | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | |...| |...| |...| |...| | | | | Legacy |if1| Legacy |if2|PCCEC |if3| PCECC |if4| Legacy | | | | Node | | Node | |Enabled | |Enabled | | Node | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | +------------------------------------------------------------------+ 5. PCEP Extensions 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. 5.1. New Messages In this document, we define the following new PCEP messages: Zhao, et al. Expires August 5, 2014 [Page 11] Internet-Draft PCECC November 2013 (LabelRRq): a PCEP message sent by a PCC to a PCE to ask for the gloabl label range reservation. (LabelRN): a PCEP message sent by a PCE to a PCC to indicate the globallabel range reserved. (LSPSetupRq): a PCEP message sent by a PCC to a PCE to ask for the setup of LSPs. (LSPSetupRq): a PCEP message sent by a PCC to a PCE to ask for the delete of LSPs. (LFIBdownload): a PCEP message sent by a PCE to a PCC to download the LFIB. (LFIBCleanup): a PCEP message sent by a PCE to a PCC to download the LFIB. The new functions defined in this document are mapped onto the new messages as shown in the following table. +----------------------------------------+--------------------------+ | Function | Message | +----------------------------------------+--------------------------+ | LSP Label Range Reserve Request | LabelRRq | | LSP Label Range Reserve Notify | LabelRN | | LSP Setup Request | LSPSetupRq | | LSP Delete Request | LSPDeleteRq | | LIFB Download | LFibDownLoad | | LIFB Cleanup | LFibCleanup | +----------------------------------------+--------------------------+ 5.1.1. PCEP Extension for Label Range Reservation Request A Label Range Request message (also referred to as LabelRRq message) is a PCEP message sent by a PCC or an application to a PCE to request the setup of an LSP. The Message-Type field of the PCEP common header for the LabelRRq message is set to [TBD]. The format of a LabelRRq message is as follows: Zhao, et al. Expires August 5, 2014 [Page 12] Internet-Draft PCECC November 2013 ::= Where: ::= is as defined in [RFC3209]. There are three mandatory objects that MUST be included within each label range Request in the labelRRq message: the SQR Object, two label objects. If the SQR object is missing, the receiving PCE MUST send a PCErr message. If the label object is missing, the receiving PCE MUST send a PCErr message with Error- type=[TBD] (Mandatory Object missing) and Error-value=[TBD] (Lable object missing). A PCE only acts on an label range reservation equest if permitted by the local policy configured by the network manager. Each label range reservation Request that the PCC acts on results in an LSP setup operation. An LSP MUST contain all LSP parameters that a PCC need to resrve the label range. A PCC MAY set missing parameters from locally configured defaults. 5.1.2. PCEP Extension for Label Range reservation Notify The Label Range Notify Message (also referred to as LabelRN) is a PCEP message sent by a PCE to a PCC to notify the global label range reserved for the network. The Message-Type field of the PCEP common header for the LabelRN message is set to [TBD]. The format of the LabelRN message is as follows: > ::= [] Where: the label range is between Minumum-Lable and Maxmum-Lable, which is as defined as the