PCE Working Group Quintin Zhao Internet-Draft Katherine Zhao Intended status: Standards Track Robin Li Expires: April 24, 2014 Huawei Technologies Zekun Ke Tencent Holdings Ltd. October 21, 2013 The User cases for Using PCE as the Central Controller(PCECC) of LSPs draft-zhao-pce-central-controller-user-cases-00 Abstract In certain deployment networks deployment scenarios, service providers would like to keep all the existing MPLS functionalities in both MPLS and GMPLS network while removing the complexity of existing signaling protocols such as LDP and RSVP-TE. In this document, we propose to use the PCE as a central controller so that LSP can be calculated/signaled/initiated/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 describes the user cases for using the PCE as the central controller where LSPs are calculated/setup/initiated/downloaded through extending the existing PCE architectures and extending the 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 April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Zhao, et al. Expires April 24, 2014 [Page 1] Internet-Draft PCECC October 2013 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. Using the PCE as the Central Controller (PCECC) Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. MPLS Label Resource Reservation through PCECCP . . . . . . 5 1.3. Using PCECCP to Distribute the LSP Forwarding Entry from PCECC server to each PCECC clients . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4. User Cases for PCECC's Label Resource Reservations . . . . . . 7 5. User Cases for PCECC for LSP Setup in the New PCECC Enabled Network . . . . . . . . . . . . . . . . . . . . . . . 8 6. User Cases for PCECC for LSP Setup in the Network Migration . 8 7. Using Extended PCEP to download LSP infor for Each Network Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. The Considerations for PCECC Procedure and PCEP extensions . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Zhao, et al. Expires April 24, 2014 [Page 2] Internet-Draft PCECC October 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, SDN has provides additional flexibility in how the network is operated comparing 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 achives the goal of having a centralized controller to provide the functionalities needed for the central 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-crabbe-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-crabbe-pce-pce-initiated-lsp] by addressing the requirements for remote-initiated GMPLS LSPs. 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 and OSPF Zhao, et al. Expires April 24, 2014 [Page 3] Internet-Draft PCECC October 2013 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.crabbe-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, the LSP is need to be signaled through the head end LER to the tail end LER, there are either RSVP-TE signaling protocol need to be deployed in the MPLS/GMPLS network, or extend TGP protocol with node/adjacency segment identifiers signaling capability to be deployed. The PCECC solution proposed in this document 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 consists legacy network nodes and the new network nodes which are centrally controlled, the PCECC solution provides a smooth transition step for users. 1.1. Using the PCE as the Central Controller (PCECC) Approach With PCECC, it not only removes the existing MPLS signaling totally from the control plane without losing any existing MPLS functionalities, but also PCECC achives this goal through utilizing the existing PCEP without introducing a new protocol into the network. The following diagram illustrates the PCECC architecture. Zhao, et al. Expires April 24, 2014 [Page 4] Internet-Draft PCECC October 2013 +------------------------------------------------------------------+ | PCECC | | +-----------------------------------------------------+ | | | LSP-Database RSVP-TE Signal Control Module | | | | TE-Database LDP signaling Control Module | | | | Label-Database LSP/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. 1.2. MPLS Label Resource Reservation through PCECCP Current MPLS label has local meaning. That is, MPLS label allocated locally and signaled through the LDP/RSVP-TE/BGP etc dynamic signaling protocol. As the SDN(Service-Driven Network) technology develops, MPLS global label has been proposed again for new solutions. [I-D.li-mpls- global-label-usecases] proposes possible usecases of MPLS global label. MPLS global label can be used for identification of the location, the service and the network in different application scenarios. From these usecases we can see that no matter SDN or traditional application scenarios, the new solutions based on MPLS global label can gain advantage over the existing solutions to facilitate service provisions. To ease the label allocation and signaling mechanism, also with the new applications such as concentrated LSP controller is introduced, PCE can be conveniently used as a central controller and MPLS global label range negotiator. The later section of this draft describes the user cases for PCE Zhao, et al. Expires April 24, 2014 [Page 5] Internet-Draft PCECC October 2013 server and PCE clients to have the global label range negotiation and local label range negotiation functionality. 1.3. Using PCECCP to Distribute the LSP Forwarding Entry from PCECC server to each PCECC clients To empower networking with centralized controllable modules, there are many choices for downloading the forwarding entries to the data plane, one way is the use of the OpenFlow protocol, which helps devices populate their forwarding tables according to a set of instructions to the data plane. There are other andidate protocols to convey specific configuration information towards devices also. Since the PCEP protocol is already deployed in some of the service network, to leverave the PCEP to populated the MPLS forwarding table is a possible good choice. 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. PCEP Requirements Following key requirements associated PCECC should be considered when designing the PCECC based solution: 1. Path Computation Element (PCE) clients supporting this draft MUST have the capability to advertise its PCECC capability to the PCECC. 2. Path Computation Element (PCE) supporting this draft MUST have the capability to negotiate a global label range for a group of clients. Zhao, et al. Expires April 24, 2014 [Page 6] Internet-Draft PCECC October 2013 3. Path Computation Client (PCC) MUST be able ask for global label range assigned in path request message . 4. PCE are not required to support label reserve service. Therefore, it MUST be possible for a PCE to reject a Path Computation Request 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 the reply message. 6. PCEP SHOULD provide a means to download the MPLS forwarding entry to the PCECC's clients. 4. User Cases for PCECC's Label Resource Reservations Example 1 to 3 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 | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | +------------------------------+ +------------------------------+ Example 1: 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 Zhao, et al. Expires April 24, 2014 [Page 7] Internet-Draft PCECC October 2013 o PCECC1 sends a indication message with global label reservation range 100 to 1000 confirmed to PCECC2. o PCECC2 sends indication messages with global label reservation range 100 to 1000 confirmed to Node21,..., node2n 5. User Cases for PCECC for LSP Setup in the New PCECC Enabled Network Example 2: Tunnel Head End 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. Example 3: 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. 6. User Cases for PCECC for LSP Setup in the Network Migration Example 4 is based on network configurations illustrated using the following figure: Zhao, et al. Expires April 24, 2014 [Page 8] Internet-Draft PCECC October 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 | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | +------------------------------------------------------------------+ Example 4: PCECC Initiated LSP Setup In the Network Migration In this example, there five 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. 7. Using Extended PCEP to download LSP infor for Each Network Device The existing PCEP is used to communicate between the PCE server and PCE's client 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. In the example 4, the LSP segment between node3 and node4 for destination node5 is setup from PCECC and downloaded into node3 and Zhao, et al. Expires April 24, 2014 [Page 9] Internet-Draft PCECC October 2013 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 | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | | +------------------------------------------------------------------+ 8. The Considerations for PCECC Procedure and PCEP extensions The PCECC's procedures and PCEP extensions will be defined in a separate document. 9. Acknowledgments We would like to thank Robert Tao, Changjing Yan, Tieying Huang for their useful comments and suggestions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Zhao, et al. Expires April 24, 2014 [Page 10] Internet-Draft PCECC October 2013 10.2. Informative References [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward- Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009. [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft- ietf-pce-stateful-pce- 07 (work in progress), October 2013. [I-D.crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE- initiated LSP Setup in a Stateful PCE Model", draft-crabbe-pce-pce- initiated-lsp-03 (work in progress), October 2013. [I-D.ali-pce-remote-initiated-gmpls-lsp] Ali, Z., Sivabalan, S., Filsfils, C., Varga, R., Lopez, V., and O. Dios, "Path Computation Element Zhao, et al. Expires April 24, 2014 [Page 11] Internet-Draft PCECC October 2013 Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup", draft-ali- pce-remote-initiated- gmpls-lsp-01 (work in progress), July 2013. [I-D.previdi-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and S. Litkowski, "IS-IS Extensions for Segment Routing", draft- previdi-isis-segment- routing-extensions-03 (work in progress), October 2013. [I-D.psenak-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., and W. Henderickx, "OSPF Extensions for Segment Routing", draf t-psenak-ospf-segment- routing-extensions-03 (work in progress), October 2013. [I-D.sivabalan-pce-segment-routing] Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and R. Raszuk, "PCEP Extensions for Segment Routing", draft- sivabalan-pce-segment- routing-02 (work in progress), October 2013. [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global Label", dr aft-li-mpls-global- label-usecases-00 (work in progress), July 2013. Zhao, et al. Expires April 24, 2014 [Page 12] Internet-Draft PCECC October 2013 Authors' Addresses Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 US EMail: quintin.zhao@huawei.com Katherine Zhao Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA EMail: Katherine.zhao@huawei.com Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China EMail: lizhenbin@huawei.com Zekung Ke Tencent Holdings Ltd. Shenzhen China EMail: kinghe@tencent.com Zhao, et al. Expires April 24, 2014 [Page 13]