MPLS Working Group F. Zhang, Ed. Internet-Draft ZTE Intended status: Standards Track R. Jing Expires: August 29, 2011 China Telecom February 25, 2011 RSVP-TE Extensions to Establish Associated Bidirectional LSP draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03 Abstract This document provides a method to bind two unidirectional LSPs into an associated bidirectional LSP, by extending the Extended ASSOCIATION object defined in [I-D.ietf-ccamp-assoc-info]. 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 29, 2011. 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zhang & Jing Expires August 29, 2011 [Page 1] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Association of Two Reverse Unidirectional LSPs . . . . . . . . 4 3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 4 3.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 4 3.2.1. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . 5 3.3. Recovery Considerations . . . . . . . . . . . . . . . . . 6 4. Extensions to the Extended ASSOCIATION object . . . . . . . . 6 5. REVERSE_TSPEC Object . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Association Type of Two Reverse Unidirectional LSPs Association . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. REVERSE_TSPEC Object . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative references . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhang & Jing Expires August 29, 2011 [Page 2] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 1. Introduction The associated bidirectional LSP, defined in [RFC5654], is constructed from a pair of unidirectional LSPs that are associated with each other at the LSP's ingress/egress points. It is useful for protection switching, for Operations, Administrations and Maintenance (OAM) messages that require a reply path. The corresponding requirements are also specified in as follow: 7 MPLS-TP MUST support associated bidirectional point-to-point LSPs. 11 The end points of an associated bidirectional LSP MUST be aware of the pairing relationship of the forward and reverse LSPs used to support the bidirectional service. 12 Nodes on the LSP of an associated bidirectional LSP where both the forward and backward directions transit the same node in the same (sub)layer as the LSP SHOULD be aware of the pairing relationship of the forward and the backward directions of the LSP. 50 The MPLS-TP control plane MUST support establing associated bidirectional P2P LSP including configuration of protection functions and any associated maintenance functions. Furthermore, these requirements are repeated in [I-D.ietf-ccamp-mpls-tp-cp-framework]. The notion of association as well as the corresponding RSVP ASSOCIATION object is defined in [RFC4872] and [RFC4873]. In thatcontext, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and [I-D.ietf-ccamp-assoc-info] defines the Extended ASSOCIATION object that can be more generally applied. This document extends the Extended ASSOCIATION object to establish associated bidirectional LSPs. 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. Zhang & Jing Expires August 29, 2011 [Page 3] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 3. Association of Two Reverse Unidirectional LSPs 3.1. Provisioning Model The associated bidirectional LSP's forward and backward directions are set up, monitored, and protected independently [RFC5654], so the configurations about it can be sent to one end or two ends. Depending on this, there are two models of signaling associated bidirectional LSP, one is the single sided provisioning and the other is the double sided provisioning. For the single sided provisioning, the configurations are sent to one end. Firstly, the associated bidirectional TE tunnel is configured on this end, then a LSP under this tunnel is initiated with the Extended ASSOCIATION object carried in the Path message to trigger the peer end to set up the corresponding associated TE tunnel and LSP. For the double sided provisioning, the commands are sent to two end points. They establish their associated bidirectional TE tunnels independently, then each one starts to set up the LSP using the Extended ASSOCIATION objects carried in the Path message to indicate each other to associate the two LSPs together to be an associated bidirectional LSP. It can happen to bind two reverse unidirectional LSPs to be an associated bidirectional LSP not only when they are being created, but also when they have existed; or when one LSP exists, but the other end needs to be established. To all these scenarios, the provisioning models discussed above are applicable. 3.2. Signaling Procedure Consider the following example, two reverse unidirectional LSPs are being established or have been established, the forward LSP1 is from A to B over [A,D,B], and the associated backward LSP2 is from B to A over [B,D,C,A]. A-------D-------B \ / \ / \ / C Figure 1: An example of associated bidirectional LSP Zhang & Jing Expires August 29, 2011 [Page 4] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 For single sided provisioning model, LSP1 is triggered by LSP2 or LSP2 is triggered by LSP1. When LSP2 is triggered by LSP1, the Extended ASSOCIATION object of LSP1 is initialized before the Extended ASSOCIATION objects of LSP2, The Extended ASSOCIATION object of LSP1 and LSP2 will carry the same value and this value SHOULD be LSP1'tunnel ID, LSP ID and tunnel sender address. When LSP1 is triggered by LSP2, the Extended ASSOCIATION object of LSP2 is initialized before the Extended ASSOCIATION objects of LSP1, The Extended ASSOCIATION object of LSP1 and LSP2 will carry the same value and this value SHOULD be LSP2'tunnel ID, LSP ID and tunnel sender address. For double sided provisioning model, LSP1 and LSP2 are concurrently initialized, the values of the Extended ASSOCIATION object carried in LSP1's Path message are LSP1's tunnel ID, LSP ID and tunnel sender address; the values of the Extended ASSOCIATION object carried in LSP2's Path message are LSP1's tunnel ID, LSP ID and tunnel sender address. According to the general rules defined in [I-D.ietf-ccamp-assoc-info], the two LSPs cannot be bound together to be an associated bidirectional LSP because of the different values. In this case, the two edge nodes should firstly compare their router ID, then the bigger one sends Path refresh message, carrying the Extended ASSOCIATION object of the reverse LSP. Based on this Path refresh message, the two LSPs can be bounded together to be an associated bidirectional LSP also. 3.2.1. Asymmetric Bandwidth LSPs There are some kind of applications, such as internet services and the return paths of OAM messages, which MAY have different bandwidth requirements for each direction. [RFC5654] specifies the requirements as follow: 14 MPLS-TP MUST support bidirectional LSPs with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions. The approach for supporting asymmetric bandwidth co-routed bidirectional LSPs is defined in [I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis], which introduces three new objects named UPSTREAM_FLOWSPEC object, UPSTREAM_TSPEC object and UPSTREAM_ADSPEC object to represent the asymmetric upstream traffic flow. For the asymmetric bandwidth associated bidirectional LSPs, the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC are complemented with the addition of new REVERSE_TSPEC object, which is used in exactly the same fashion as the old SENDER_TSPEC object, but refers to set up the reverse unidirectional LSP. Zhang & Jing Expires August 29, 2011 [Page 5] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 In the context of asymmetric associated bidirectional LSP, the REVERSE_TSPEC object MUST be carried in the LSP's Path message together with the Extended ASSOCIATION object whose Association Type is "Association of two reverse unidirectional LSPs" to trigger the peer end to set up the reverse LSP with the corresponding asymmetric bandwidth. For the single sided provisioning, the peer end just copies the value of the REVERSE_TSPEC object into the SENDER_TSPEC object in the Path message. For the double sided provisioning, the ends need to compare the values of the SENDER_TSPEC and REVERSE_TSPEC objects in the two Path messages. If match, the end with the bigger router ID sends Path refresh message, carrying the Extended ASSOCIATION object of the reverse LSP. Nodes not supporting this extension will not recognize the new class number and should respond with an "Unknown Object Class". 3.3. Recovery Considerations Assume that LSP3 is used to protect LSP1, which can be established before or after the failure occurs, can share the same TE tunnel with LSP1 or not. LSP3 SHOULD inherits the associated bidirectional attributes between LSP1 and LSP2 when the traffic is switched from LSP1 to LSP3. This can be done by inserting the Extended ASSOCIATION object in LSP3's Path message with the same value as in LSP1's Path message. 4. Extensions to the Extended ASSOCIATION object The Extended ASSOCIATION object is defined in [I-D.ietf-ccamp-assoc-info]. The Extended IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID (Continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhang & Jing Expires August 29, 2011 [Page 6] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 Extended IPv4 ASSOCIATION object The Extended IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID (Continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended IPv6 ASSOCIATION object o Association Type: Now, the following values of the Association Type have been defined. Value Type ----- ---- 0 Reserved 1 Recovery (R) 2 Resource sharing (S) In order to bind two reverse unidirectional LSPs to be an associated bidirectional LSP, this document defined a new value: Value Type ----- ---- 4 Association of two reverse unidirectional LSPs (A) If the downstream nodes do not know this Association Type, MUST return a PathErr message with error code/sub-code "LSP Admission Failure/Bad Association Type". Zhang & Jing Expires August 29, 2011 [Page 7] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 o Association Source: The general rule is that the address is "associated to the node that originate the association" and provide global scope (within the address space) to identified association,see [RFC4872] and [I-D.ietf-ccamp-assoc-info]. This document adds specific rules: the Association source MUST be set to the tunnel sender address of the initiating node. o Association ID: The association ID is set to a value that uniquely identifies the set of LSPs to be associated and the generic definition does not provide any specific rules on how matching is to be done. In order to provide global Association ID based on MPLS-TP identifiers, this document adds specific rules: the first 16 bits MUST be set to the tunnel ID of the initiating node and the following 16 bits MUST be set to the LSP ID of the corresponding tunnel, the rest MUST be set to zero on transmission and MUST be ignored on receipt. As described in [I-D.ietf-ccamp-assoc-info], association is always done based on matching Path state or Resv state. Upstream initializted association is represented in Extended ASSOCIATION objects carried in Path message and downstream initializted association is represented in Extended ASSOCIATION objects carried in Resv messages. The new defined association type in this document is only defined for use in upstream initializted association. Thus it can only appear in Extended ASSOCIATION objects signaled in Path message. The rules associated with the processing of the Extended ASSOCIATION objects in RSVP message are discussed in [I-D.ietf-ccamp-assoc-info]. It said that in the absence of Association Type-specific rules for identifying association, the included Extended ASSOCIATION objects MUST be identical. This document adds no specific rules, the association will always operate based on the same Extended ASSOCIATION objects. 5. REVERSE_TSPEC Object The REVERSE_TSPEC object is used in Path, PathTear, PathErr, and Notify message (via sender descriptor). This includes the definition of class type and format. It's class number is TBD (of the form 0bbbbbbb), and class type and format is the same as the SENDER_TSPEC object. This object modifies the RSVP message-related formats defined in Zhang & Jing Expires August 29, 2011 [Page 8] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 [RFC2205], [RFC3209] and [RFC3473]. See [RFC5511] for the syntax used by RSVP. The format of the sender description for asymmetric associated bidirectional LSPs is: ::= [] [] [] [] 6. IANA Considerations IANA is requested to administer assignment of new values for namespace defined in this document and summarized in this section. 6.1. Association Type of Two Reverse Unidirectional LSPs Association Within the current document, a new Association Type is defined in the Extended ASSOCIATION object. Value Type ----- ---- TBD Association of two reverse unidirectional LSPs (A) 6.2. REVERSE_TSPEC Object A new class named REVERSE_TSPEC has been created in the 0bbbbbbb rang (TBD) with the following definition: Class Types or C-types: Same values as SENDER_TPSCE object (C-Num 12) There are no other IANA considerations introduced by this document. 7. Security Considerations This document introduces a new association type, and except this, there are no security issues about the Extended ASSOCIATION object are introduced here. Zhang & Jing Expires August 29, 2011 [Page 9] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 Furthermore, this document introduces the REVERSE_TSPEC object for use in GMPLS signaling [RFC3473], which is parallel the existing SENDER_TSPEC object. As such, any vulnerabilities that are due to the use of the old SENDER_TSPEC object now apply here also. Otherwise, this document introduces no additional security considerations. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. 8. Acknowledgement The authors would like to thank Lou Berger for his great guidance in this work, George Swallow for the discussion of recovery, Lamberto Sterling for his valuable comments on the section of asymmetric bandwidths. At the same time, the authors would also like to acknowledge the contributions of Bo Wu, Xihua Fu, Lizhong Jin for the initial discussions. 9. References 9.1. Normative references [I-D.ietf-ccamp-assoc-info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of The RSVP Association Object", draft-ietf-ccamp-assoc-info-00 (work in progress), October 2010. [I-D.ietf-ccamp-mpls-tp-cp-framework] Andersson, L., Berger, L., Fang, L., Bitar, N., Gray, E., Takacs, A., Vigoureux, M., and E. Bellagamba, "MPLS-TP Control Plane Framework", draft-ietf-ccamp-mpls-tp-cp-framework-06 (work in progress), February 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Zhang & Jing Expires August 29, 2011 [Page 10] Internet-Draft RSVP-TE Extensions of Associated LSP February 2011 and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. 9.2. Informative References [I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 (work in progress), January 2011. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Authors' Addresses Fei Zhang (editor) ZTE Email: zhang.fei3@zte.com.cn Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn Fan Yang ZTE Email: yang.fan5@zte.com.cn Weilian Jiang ZTE Email: jiang.weilian@zte.com.cn Zhang & Jing Expires August 29, 2011 [Page 11]