PCE Working Group WJ. He, Ed. Internet-Draft ZTE Intended status: Standards Track November 14, 2011 Expires: May 17, 2012 Extensions to the Path Computation Element Communication Protocol (PCEP) for Associated Bidirectional LSP draft-he-pce-pcep-associated-lsp-extensions-01 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 May 17, 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 May 17, 2012 [Page 1] Internet-Draft PCEP Ext for Associated Bidirectional Lsp November 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. Concurrent Computation . . . . . . . . . . . . . . . . . . 4 3.2. Successive Computation . . . . . . . . . . . . . . . . . . 4 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 He Expires May 17, 2012 [Page 2] Internet-Draft PCEP Ext for Associated Bidirectional Lsp November 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 The path computation for associated bidirectional LSP can be realized He Expires May 17, 2012 [Page 3] Internet-Draft PCEP Ext for Associated Bidirectional Lsp November 2011 by the concurrent or successive computation. The concurrent computation means that the head-end submits the computation request for both two directional LSPs concurrently, which is applicable to the Single Sided Provisioning model. As to the successive computation, the head-end and the tail-end send the forward LSP and backward LSP computation requests separately, which is applicable to both the Single Sided Provisioning model and the Double Sided Provisioning model. 3.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 SVEC object described in [RFC6007] can be used to synchronize the requests about the forward and backward LSPs, and get the optimal path for the associated bidirectional LSP. 3.2. Successive Computation For the Successive computation, the PCCs submit the path computation request for the forward LSP and the backward LSP separately, then, the path for the associated bidirectional LSP may be not optimal. So that the two reverse LSPs should be associated, the ASSOCIATION object [I-D.ietf-ccamp-assoc-ext]may be useful. The stateful PCE [RFC4655] can coordinate the two reverse LSPs to get the optimal path for the associated bidirectional LSP through the ASSOCIATION object, if both the head-end and the tail-end PCCs delegate their respective LSPs (forward and backward) to the PCE . When the PCC submits the path computation request for the forward LSP or the backward LSP, the PCReq message may carry Extended ASSOCIATION object to indicate there is a reverse LSP to be associated, see [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]. At the same time, both the head-end and the tail-end PCCs delegate their respective LSPs (forward and backward) to the PCE using PCRpt messages[I-D.crabbe-pce-stateful-pce]. Upon receipt of the PCReq message,the PCE will locate the reverse LSP with the same association information. If there is no matched reverse LSP, the PCE will compute the LSP independently. Otherwise, the PCE will coordinate the two reverse LSPs and compute path for the associated bidirectional LSP. After the successful computation, the PCE will trigger the head-end to setup the forward LSP and the tail- end to setup the backward LSP using PCUpd messages. The PCC will use make-before-break whenever possible in the re-signaling He Expires May 17, 2012 [Page 4] Internet-Draft PCEP Ext for Associated Bidirectional Lsp November 2011 operation,[I-D.crabbe-pce-stateful-pce]. 4. PCEP Extensions 4.1. Extended ASSOCIATION Object The Extended ASSOCIATION Object is used to associate the two reverse LSPs, which form an associated bidirectional LSP. The Extended ASSOCIATION Object is carried within a PCRep message to locate the reverse LSP, and the PCE will coordinate the forward LSP and the backward LSP to get the optimal path for the associated bidirectional LSP. The contents of this object are identical in encoding to the contents of the RSVP-TE Extended ASSOCIATION Object defined in [I-D.ietf-ccamp-assoc-ext] and [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]. PCEP Extended ASSOCIATION object types correspond to RSVP-TE Extended ASSOCIATION object types. Extended ASSOCIATION Object-Class is TBD. Extended ASSOCIATION Object-Type is TBD. 5. IANA Considerations TBD 6. Security Considerations TBD 7. Acknowledgement The author would like to thank Jan Medved for his valuable comments on the double sided provisioning, Cyril for the discussion of the concurrent computation. At the same time, the author would also like to acknowledge the contributions of Fei Zhang for the discussions. 8. References He Expires May 17, 2012 [Page 5] Internet-Draft PCEP Ext for Associated Bidirectional Lsp November 2011 8.1. Normative References [I-D.crabbe-pce-stateful-pce] Crabbe, E., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-crabbe-pce-stateful-pce-01 (work in progress), October 2011. [I-D.ietf-ccamp-assoc-ext] Berger, L., Faucheur, F., and A. Narayanan, "RSVP Association Object Extensions", draft-ietf-ccamp-assoc-ext-01 (work in progress), October 2011. [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-04 (work in progress), October 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. He Expires May 17, 2012 [Page 6] Internet-Draft PCEP Ext for Associated Bidirectional Lsp November 2011 [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 May 17, 2012 [Page 7]