PCE Working Group U. Palle Internet-Draft D. Dhody Intended status: Standards Track Huawei Technologies Expires: July 30, 2014 January 26, 2014 PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE Model draft-palle-pce-stateful-pce-initiated-p2mp-lsp-00 Abstract The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE LSPs. The extensions described in [I-D.ietf-pce-stateful-pce] provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCE communication Protocol (PCEP), for a model where the Path Computation Client (PCC) delegates control over one or more locally configured LSPs to the PCE. Further [I-D.ietf-pce-pce-initiated-lsp] describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. This document provides extensions required for PCEP so as to enable stateful PCE- Initiated point-to-multipoint (P2MP) TE LSP instantiation. 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 July 30, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Palle & Dhody Expires July 30, 2014 [Page 1]
Internet-Draft PCE-INITIATED-P2MP January 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 4. Support of PCE Initiated P2MP TE LSPs . . . . . . . . . . . . 4 5. PCE-initiated P2MP TE LSP Operations . . . . . . . . . . . . 5 5.1. The PCInitiate message . . . . . . . . . . . . . . . . . 5 5.2. P2MP TE LSP Instantiation . . . . . . . . . . . . . . . . 6 5.3. P2MP TE LSP Deletion . . . . . . . . . . . . . . . . . . 6 5.4. P2MP TE LSP Delegation and Cleanup . . . . . . . . . . . 6 6. PCInitiate Message Fragmentation . . . . . . . . . . . . . . 6 6.1. PCInitiate Fragmentation Procedure . . . . . . . . . . . 6 7. Non-Support of P2MP TE LSP Instantiation for Stateful PCE . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Manageability Considerations . . . . . . . . . . . . . . . . 7 9.1. Control of Function and Policy . . . . . . . . . . . . . 7 9.2. Information and Data Models . . . . . . . . . . . . . . . 7 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 8 9.6. Impact On Network Operations . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8 1. Introduction As per [RFC4655], the Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. Palle & Dhody Expires July 30, 2014 [Page 2]
Internet-Draft PCE-INITIATED-P2MP January 2014 [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]). The PCEP is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. The extensions of PCEP to request path computation for P2MP TE LSPs are described in [RFC6006]. Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the fundamental extensions needed for stateful PCE to support general functionality for P2P TE LSP. Further [I-D.palle-pce-stateful-pce-p2mp] focuses on the extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs. It includes mechanisms to effect P2MP LSP state synchronization between PCCs and PCEs, delegation of control of P2MP LSPs to PCEs, and PCE control of timing and sequence of P2MP path computations within and across PCEP sessions and focuses on a model where P2MP LSPs are configured on the PCC and control over them is delegated to the PCE. [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental extensions needed for stateful PCE-initiated P2P TE LSP instantiation. This document describes the setup, maintenance and teardown of PCE- initiated P2MP LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. 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 Terminology used in this document is same as terminology used in [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp] and [RFC6006]. Palle & Dhody Expires July 30, 2014 [Page 3]
Internet-Draft PCE-INITIATED-P2MP January 2014 3. Architectural Overview 3.1. Motivation [I-D.palle-pce-stateful-pce-p2mp] provides stateful control over P2MP TE LSPs that are locally configured on the PCC. This model relies on the Ingress taking an active role in delegating locally configured P2MP TE LSPs to the PCE, and is well suited in environments where the P2MP TE LSP placement is fairly static. However, in environments where the P2MP TE LSP placement needs to change in response to application demands, it is useful to support dynamic creation and tear down of P2MP TE LSPs. The ability for a PCE to trigger the creation of P2MP TE LSPs on demand can be seamlessly integrated into a controller-based network architecture, where intelligence in the controller can determine when and where to set up paths. Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further describes the motivation behind the PCE-Initiated capability, which are equally applicable for P2MP TE LSPs instantiation. 3.2. Operation Overview A PCC or PCE indicates its ability to support PCE provisioned dynamic LSPs and P2MP operations during the PCEP Initialization Phase via mechanism described in Section 4. As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends a Path Computation LSP Initiate Request (PCInitiate) message to the PCC to instantiate or delete a P2P TE LSP. This document extends the PCInitiate message to support P2MP TE LSP Instantiation (see details in Section 5.1). P2MP TE LSP instantiation and deletion operations are same as P2P LSP Instantiation as described in section 5.3 and 5.4 of [I-D.ietf-pce-pce-initiated-lsp]. This document focuses on extensions needed for further handling of P2MP TE LSP Instantiation (see details in Section 5.2). 4. Support of PCE Initiated P2MP TE LSPs As per Section 3.1 of [RFC6006], PCE advertises P2MP capability via IGP discovery or a P2MP capable TLV in open message. To support instantiation of PCE-initiated P2MP TE LSPs, this document extends the advertisement of P2MP capable TLV in open message by all PCEP speakers. As per Section 4 of [I-D.ietf-pce-pce-initiated-lsp], PCC or PCE advertises capability for instantiation of PCE-initiated LSPs via Stateful PCE Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) in Palle & Dhody Expires July 30, 2014 [Page 4]
Internet-Draft PCE-INITIATED-P2MP January 2014 open message. These mechanism when used together indicates the instantiation capability for P2MP TE LSPs by the PCEP speaker. 5. PCE-initiated P2MP TE LSP Operations 5.1. The PCInitiate message As defined in section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], PCE sends a PCInitiate message to a PCC to instantiate a P2P TE LSP, this document extends the format of PCInitiate message for the creation of P2MP TE LSPs but the creation and deletion operations of P2MP TE LSP are same to the P2P TE LSP. The format of PCInitiate message is as follows: <PCInitiate Message> ::= <Common Header> <PCE-initiated-lsp-list> Where: <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> [<PCE-initiated-lsp-list>] <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|<PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-instantiation> ::= <SRP> <LSP> <end-point-path-pair-list> [<attribute-list>] <PCE-initiated-lsp-deletion> ::= <SRP> <LSP> Where: <end-point-path-pair-list>::= [<END-POINTS>] <path> [<end-point-path-pair-list>] <path> ::= (<ERO>|<SERO>) [<path>] <attribute-list> is defined in [RFC5440] and extended by PCEP extensions. The PCInitiate message with an LSP object with N bit (P2MP) set is used to convey operation on a P2MP TE LSP. The SRP object is used to Palle & Dhody Expires July 30, 2014 [Page 5]
Internet-Draft PCE-INITIATED-P2MP January 2014 correlate between initiation requests sent by the PCE and the error reports and state reports sent by the PCC as described in [I-D.ietf-pce-stateful-pce]. 5.2. P2MP TE LSP Instantiation The Instantiation operation of P2MP TE LSP is same as defined in section 5.3 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error codes remains unchanged. Further, as defined in section 6.1 of [I-D.palle-pce-stateful-pce-p2mp], N bit MUST be set in LSP object in PCInitiate message by PCE to specify the instantiation is for P2MP TE LSP and the PCC or PCE MUST follow the mechanism defined in [I-D.palle-pce-stateful-pce-p2mp] for delegation and updation of P2MP TE LSPs. 5.3. P2MP TE LSP Deletion The deletion operation of P2MP TE LSP is same as defined in section 5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate Message with an LSP object carrying the PLSP-ID of the LSP to be removed and an SRP object with the R flag set (LSP-REMOVE as per section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of processing and error codes remains unchanged. 5.4. P2MP TE LSP Delegation and Cleanup P2MP TE LSP delegation and cleanup operations are same as defined in section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error codes remains unchanged. 6. PCInitiate Message Fragmentation The total PCEP message length, including the common header, is 16 bytes. In certain scenarios the P2MP LSP Initiate may not fit into a single PCEP message (initial PCInitiate message). The F-bit is used in the LSP object to signal that the initial PCInitiate was too large to fit into a single message and will be fragmented into multiple messages. Fragmentation procedure described below for PCInitiate message is similar to [RFC6006] which describes request and response message fragmentation. 6.1. PCInitiate Fragmentation Procedure Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate message is sent to the PCC. If the PCInitiate is too large to fit into a single PCInitiate message, the PCE will split the PCInitiate Palle & Dhody Expires July 30, 2014 [Page 6]
Internet-Draft PCE-INITIATED-P2MP January 2014 over multiple messages. Each PCInitiate message sent by the PCE, except the last one, will have the F-bit set in the LSP object to signify that the PCInitiate has been fragmented into multiple messages. In order to identify that a series of PCInitiate messages represents a single Initiate, each message will use the same PLSP-ID (in this case 0) and SRP-ID-number. [Editor Note: P2MP message fragmentation errors associated with a P2MP path initiation will be defined in future version]. 7. Non-Support of P2MP TE LSP Instantiation for Stateful PCE The PCEP protocol extensions described in this document for PCC or PCE with instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or PCE has not advertised its stateful capability with Instantiation and P2MP capability as per Section 4. If this is not the case and Stateful operations on P2MP TE LSPs are attempted, then a PCErr with error-type 19 (Invalid Operation) and error-value TBD needs to be generated. [Editor Note: more information on exact error value is needed] 8. Security Considerations TBD 9. Manageability Considerations 9.1. Control of Function and Policy TBD. 9.2. Information and Data Models TBD. 9.3. Liveness Detection and Monitoring TBD. 9.4. Verify Correct Operations TBD. Palle & Dhody Expires July 30, 2014 [Page 7]
Internet-Draft PCE-INITIATED-P2MP January 2014 9.5. Requirements On Other Protocols TBD. 9.6. Impact On Network Operations TBD. 10. IANA Considerations TBD 11. Acknowledgments 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, October 2009. [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010. [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. Palle & Dhody Expires July 30, 2014 [Page 8]
Internet-Draft PCE-INITIATED-P2MP January 2014 [I-D.ietf-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-ietf-pce-pce-initiated-lsp-00 (work in progress), December 2013. [I-D.palle-pce-stateful-pce-p2mp] Palle, U. and D. Dhody, "Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to- Multipoint Traffic Engineering Label Switched Paths", draft-palle-pce-stateful-pce-p2mp-00 (work in progress), December 2013. [I-D.ietf-pce-stateful-pce-app] Zhang, X. and I. Minei, "Applicability of Stateful Path Computation Element (PCE)", draft-ietf-pce-stateful-pce- app-01 (work in progress), September 2013. Authors' Addresses Udayasree Palle Huawei Technologies Leela Palace Bangalore, Karnataka 560008 INDIA EMail: udayasree.palle@huawei.com Dhruv Dhody Huawei Technologies Leela Palace Bangalore, Karnataka 560008 INDIA EMail: dhruv.ietf@gmail.com Palle & Dhody Expires July 30, 2014 [Page 9]