PCE Working Group WJ. He, Ed. Internet-Draft ZTE Intended status: Standards Track October 21, 2011 Expires: April 23, 2012 Extensions to the Path Computation Element Communication Protocol (PCEP) for Associated Bidirectional LSP draft-he-pce-pcep-associated-lsp-extensions-00 Abstract The MPLS Transport Profile (MPLS-TP) requirements document[RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. Path Computation Element (PCE), see [RFC4655], may be used for path computation of an associated bidirectional LSP. This document defines the Path Computation Element Protocol (PCEP)-based [RFC5440] extensions for associated bidirectional LSP. 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 23, 2012. Copyright Notice Copyright (c) 2011 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 He Expires April 23, 2012 [Page 1] Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The Single Sided Provisioning . . . . . . . . . . . . . . . 4 3.1.1. Concurrent Computation . . . . . . . . . . . . . . . . 4 3.1.2. Successive Computation . . . . . . . . . . . . . . . . 4 3.2. The Double Sided Provisioning . . . . . . . . . . . . . . . 5 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. The Extension of the RP Object . . . . . . . . . . . . . . 5 4.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 He Expires April 23, 2012 [Page 2] Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011 1. Introduction The MPLS Transport Profile (MPLS-TP) requirements [RFC5654] and control plane framework documents[RFC6373]describe that MPLS-TP MUST support associated bidirectional point-to-point LSPs. Path Computation Element (PCE), see [RFC4655], may be used for path computation of a GMPLS LSP, see [I-D.ietf-pce-gmpls-pcep-extensions],and consequently an associated bidirectional LSP, across domains and in a single domain. Dependent path computations are requests that need to be synchronized in order to meet specific objectives, see [RFC6007]. For associated bidirectional LSP, if the forward LSP and the backward LSP are computed concurrently, the PCE can find the optimum path. This document defines the Path Computation Element Protocol (PCEP)- based [RFC5440] extensions for associated bidirectional LSP. 2. Conventions used in this document 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]. 3. Processing Consider the topology described in Figure 1. (An example of associated bidirectional LSP). The LSP1 [via nodes A,D,B] (from A to B) and LSP2 [via nodes B,D,C,A] (from B to A) need to be established, which can form an associated bidirectional LSP deployed by Single Sided Provisioning model or Double Sided Provisioning model[I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]. Node A, the ingress LSR of LSP1, can play the role of a PCC and request the PCE to compute the LSP1 or the associated bidirectional LSP. A-------D-------B \ / \ / \ / C Figure 1 : An example of associated bidirectional LSP He Expires April 23, 2012 [Page 3] Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011 3.1. The Single Sided Provisioning For the single sided provisioning, the path computation can be realized by the concurrent or successive computation. The concurrent computation means that the head-end submits the computation request for both two directional LSPs concurrently. As to the successive computation, the head-end and the tail-end send the forward LSP and backward LSP computation requests separately. 3.1.1. Concurrent Computation The PCC sends the PCReq message to PCE for computing an associated bidirectional LSP, whose forward and backward paths are computed concurrently. Concurrent computation can ensure that the paths for the associated bidirectional LSP is optimal [RFC5557]. The basic procedure are as follows: 1. The PCC node sends the PCReq message to the PCE with the A flag of the RP object set, indicates the request is for an associated bidirectional LSP. Except the constraint information about the forward LSP, the REVERSE_LSP object may also be included in the PCReq message to specify the TE parameters of the backward LSP. 2. Once receiving the PCReq message, the PCE will compute the two reverse LSP based on the constraints, and choose the optimal LSP for the associated bidirectional LSP. If the A bit of the RP object set to 1, but the REVERSE_LSP object is not present in the PCReq message, the PCE computes the path of the reverse LSP according to the forward LSP information, such as bandwidth, protection and so on. 3. After the successful computation, the PCE will supply the PCC with a fully computed explicit routes of an associated bidirectional LSP. The explicit path for the forward LSP is carried by the ERO object and the backward LSP by the ERO subobject inserted in the REVERSE_LSP object. If the PCE does not support the extensions in this document, responses with notification. 3.1.2. Successive Computation Successive computation means that the forward LSP and the backward LSP are computed separately. The head-end will send request to the PCE for the forward LSP. After receiving the successful computation result, the head-end starts to signal the forward LSP with Extended Association object and Reverse LSP object inserted in the Path message [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]. Once receiving the Path message, the tail-end will be triggered to create He Expires April 23, 2012 [Page 4] Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011 the backward LSP. The REVERSE_LSP object is extracted from the Path message and may be put into the PCReq message for a path computation. There is no need to extend the PCEP to support the successive computation. 3.2. The Double Sided Provisioning For the double sided provisioning, the forward and the backward LSP configuration are send to the head-end and the tail-end separately. The head-end and the tail-end will send the PCReq message for the unidirectional LSP computation. After the successfully computation, the head-end and the tail-end start to create the LSP separately. 4. PCEP Extensions 4.1. The Extension of the RP Object The PCReq and PCRep messages will need the following additional parameters for associated bidirectional LSP. An A-bit is added to the flag bits of the RP object to indicate the request is about an associated bidirectional LSP or not. o A (RP Associated bit - 1 bit): when set, the PCC specifies that the path computation request relates to an associated bidirectional TE LSP that may be has the different traffic engineering requirements including fate sharing, protection and restoration, LSRs, TE links, and resource requirements (e.g., latency and jitter) in each direction. When cleared, the TE LSP is not an associated bidirectional TE LSP . 4.2. REVERSE_LSP Object The REVERSE_LSP object is used in a PCReq message to specify the information of the reverse LSP for which a path computation is requested. This object is optional. The format of the REVERSE_LSP object is as follows: Object-Class is TBD,Object-Type is TBD. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ He Expires April 23, 2012 [Page 5] Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011 Figure 2 : REVERSE_LSP Object Body Format This object MUST NOT be used when the A bit of RP object set to 0. Subojects The contents of a REVERSE_LSP object are a series of variable-length data items called subobjects, which can be BANDWIDTH, IRO and XRO object, LSPA Object, METRIC Object, etc. 5. IANA Considerations TBD 6. Security Considerations TBD 7. Acknowledgement TBD 8. References 8.1. Normative References [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp] Zhang, F. and R. Jing, "RSVP-TE Extensions for Associated Bidirectional LSPs", draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02 (work in progress), October 2011. [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. 8.2. Informative References [I-D.ietf-pce-gmpls-pcep-extensions] Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for GMPLS", draft-ietf-pce-gmpls-pcep-extensions-03 (work in He Expires April 23, 2012 [Page 6] Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011 progress), July 2011. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, September 2010. [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, September 2011. Author's Address Wenjuan He (editor) ZTE Email: he.wenjuan1@zte.com.cn He Expires April 23, 2012 [Page 7]