MPLS Working Group F. Zhang, Ed. Internet-Draft F. Yang Intended status: Standards Track L. Jin Expires: April 28, 2011 W. Jiang ZTE Corporation October 25, 2010 RSVP-TE Extensions to Establish Associated Bidirectional LSP draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-01 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.berger-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 April 28, 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 described in the Simplified BSD License. Zhang, et al. Expires April 28, 2011 [Page 1] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 4 3. Extensions to the Extended ASSOCIATION object. . . . . . . . . 4 4. Association of Two Reverse Unidirectional LSPs . . . . . . . . 6 4.1. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative references . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Zhang, et al. Expires April 28, 2011 [Page 2] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 1. Introduction The associated bidirectional path, defined in[RFC5654], is constructed from a pair of unidirectional paths that are associated with one another at the path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. [RFC5654] specifies the requirements about associated bidirectional paths in requirement 7, 11, 12, 50: 7 MPLS-TP MUST support associated bidirectional point-to-point transport paths. 11 The end points of an associated bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service. 12 Nodes on the path of an associated bidirectional transport path where both the forward and backward directions transit the same node in the same (sub)layer as the path SHOULD be aware of the pairing relationship of the forward and the backward directions of the transport path. 50 The MPLS-TP control plane MUST support stabling associated bidirectional P2P path 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 are defined in [RFC4872] and [RFC4873]. In this context, 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.berger-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 Zhang, et al. Expires April 28, 2011 [Page 3] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 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. Extensions to the Extended ASSOCIATION object. The Extended ASSOCIATION object is defined in [I-D.berger-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 1: 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 April 28, 2011 [Page 4] Internet-Draft RSVP-TE Extensions of Associated LSP October 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 2: 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 LSP (A) If the midpoints do not know this Association Type, just ignore it and forward it to the next node, but the egress nodes 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 April 28, 2011 [Page 5] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 address sapce) to identified association,see [RFC4872] and [I-D.berger-ccamp-assoc-info]. This document adds specific rules: the Association source MUST 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. This document adds specific rules: the first 16 bits MUST set to the tunnel ID of the initiating node and the following 16 bits MUST 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.berger-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.berger-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 be operation based on the same Extended ASSOCIATION objects. 4. Association of Two Reverse Unidirectional LSPs Consider the following example: A-------D-------B \ / \ / \ / C Figure 3: An example of associated bidirectional LSP Zhang, et al. Expires April 28, 2011 [Page 6] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 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]. Just like the end-to-end recovery LSP association [I-D.berger-ccamp-assoc-info], the following combination may occur when binding LSP1 and LSP2 together to be an associated bidirectional LSP Case 1. 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. Case 2. 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. Case 3. The Extended ASSOCIATION object of both the LSPs 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.berger-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. 4.1. Asymmetric Bandwidth LSPs There are some kind of services which have different bandwidth requirements for each direction, and associated bidirectional LSPs SHOULD support them. [RFC5467] defined three new objects named UPSTREAM_FLOWSPEC object, UPSTREAM_TSPEC object and UPSTREAM_ADSPEC object, which refer to the upstream traffic flow. In this document, UPSTREAM_TSPEC MUST be carried in the initializing LSP's Path message to trigger the egress node to setup the reverse LSP with corresponding asymmetric bandwidth. 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 Zhang, et al. Expires April 28, 2011 [Page 7] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 object. 5. IANA Considerations Within the current document, a new Association Type is defined in Extended ASSOCIATION object. Value Type ----- ---- 4 Association of two reverse unidirectional LSPs (A) There are no other IANA considerations introduced by this document. 6. Security Considerations No new security considerations are introduced in this document. 7. Acknowledgement The author would like to thank Xihua Fu and Bo Wu for their useful discussion; thank Lou Berger for his suggestion on the organization of this document; thank Lamberto Sterling for his valuable comments on the section of asymmetric bandwidths. 8. Normative references [I-D.berger-ccamp-assoc-info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of The RSVP Association Object", draft-berger-ccamp-assoc-info-01 (work in progress), March 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-03 (work in progress), October 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 Zhang, et al. Expires April 28, 2011 [Page 8] Internet-Draft RSVP-TE Extensions of Associated LSP October 2010 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. Authors' Addresses Fei Zhang (editor) ZTE Corporation Email: zhang.fei3@zte.com.cn Fan Yang ZTE Corporation Email: yang.fan5@zte.com.cn LZ Jin ZTE Corporation Email: lizhong.jin@zte.com.cn WL jiang ZTE Corporation Email: jiang.weilian@zte.com.cn Zhang, et al. Expires April 28, 2011 [Page 9]