MPLS Working Group F. Zhang, Ed. Internet-Draft ZTE Intended status: Standards Track G. Swallow, Ed. Expires: June 11, 2011 Cisco R. Jing China Telecom December 08, 2010 RSVP-TE Extensions to Establish Associated Bidirectional LSP draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-02 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 June 11, 2011. Copyright Notice Copyright (c) 2010 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 Zhang, et al. Expires June 11, 2011 [Page 1] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 described in the Simplified BSD License. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative references . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Zhang, et al. Expires June 11, 2011 [Page 2] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 1. Introduction The associated bidirectional LSP, defined in [RFC5654], is constructed from a pair of unidirectional LSPs that are associated with one another at the LSP's ingress/egress points. The forward and backward directions are set up, monitored, and protected independently. [RFC5654] specifies the requirements about associated bidirectional LSPs in requirement 7, 11, 12, 50: 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 associated bidirectional LSP is useful for protection switching, for OAM that requires a reply (from MIP or MEP), and for defect correlation. The binding can happen when the two unidirectional LSPs are being established or have been established. 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, et al. Expires June 11, 2011 [Page 3] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 3. Association of Two Reverse Unidirectional LSPs 3.1. Provisioning Model The configurations about associated bidirectional LSPs can be sent to one LSR or two LSRs, and depends on this, the provisioning model can be divided into two categories, 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 LSR. Firstly, the associated bidirectional TE tunnel is configured on this LSR, then a LSP under this tunnel is initiated with the Extended ASSOCIATION object carried in the Path message to trigger the other end point 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. Binding two reverse unidirectional LSPs to be an associated bidirectional LSP happens not only when they are being created, but also when they have existed; or when only one LSP exists, another one needs to be established. To all these scenarios, both of the two provisioning models discussed are applicable. As to select which one for a specific network, it mainly depends on the operators' preference. 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, et al. Expires June 11, 2011 [Page 4] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 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, and associated bidirectional LSPs MUST support them. [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. [RFC5467] defined three new objects named UPSTREAM_FLOWSPEC object, UPSTREAM_TSPEC object and UPSTREAM_ADSPEC object, which refer to the upstream traffic flow. The UPSTREAM_TSPEC object can be reused to establish asymmetric associated bidirectional LSP, but the syntax is different. In the context of associated bidirectional LSP, UPSTREAM_TSPEC MUST be carried in the initializing LSP's Path message together with the Extended ASSOCIATION object whose Association Type is "Association of two reverse unidirectional LSPs" to trigger the egress node to set up the reverse LSP with corresponding asymmetric bandwidth indicated in the UPSTREAM_TSPEC object when the bandwidth of the backward direction is different. Zhang, et al. Expires June 11, 2011 [Page 5] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 If the midpoints do not know this object, just ignore it and forward it to the next node, but the egress nodes MUST return a PathErr message with error code/sub-code "Admission Control failure/Unknown object" if they do not know this object. 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. The traffic is switched from LSP1 to LSP3 after the failure (the migration happens before failure if MBB is used), at the same time, LSP3 SHOULD inherits the associated bidirectional attributes between LSP1 and LSP2. It is easy to achieve this 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Extended IPv4 ASSOCIATION object The Extended IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the format: Zhang, et al. Expires June 11, 2011 [Page 6] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 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 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: 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" if they do not know this Association Type. 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 Zhang, et al. Expires June 11, 2011 [Page 7] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 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. [I-D.ietf-ccamp-assoc-info] discussed the rules associated with the processing of the Extended ASSOCIATION objects in RSVP message. 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. IANA Considerations Within the current document, a new Association Type is defined in the Extended ASSOCIATION object. Value Type ----- ---- 4 Association of two reverse unidirectional LSPs (A) There are no other IANA considerations introduced by this document. Zhang, et al. Expires June 11, 2011 [Page 8] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 6. Security Considerations This document is in accordance with [I-D.ietf-ccamp-assoc-info], and no new security considerations are introduced. 7. Acknowledgement The authors would like to thank Lou Berger for his great guidance in this work, 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. 8. 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-04 (work in progress), November 2010. [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. [RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. Zhang, et al. Expires June 11, 2011 [Page 9] Internet-Draft RSVP-TE Extensions of Associated LSP December 2010 Authors' Addresses Fei Zhang (editor) ZTE Email: zhang.fei3@zte.com.cn George Swallow (editor) Cisco Email: swallow@cisco.com 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, et al. Expires June 11, 2011 [Page 10]