CCAMP Working Group F. Zhang, Ed. Internet-Draft ZTE Intended status: Standards Track R. Jing Expires: February 16, 2013 China Telecom R. Gandhi Cisco Systems August 15, 2012 RSVP-TE Extensions for Associated Bidirectional LSPs draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 Abstract The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. This document provides a method to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining the new Association Type in the Extended ASSOCIATION object. 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 September 7, 2012. Copyright Notice Copyright (c) 2012 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 Zhang & Jing Expires February 16, 2013 [Page 1] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 4 3.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 4 3.2.1. Single Sided Provisioning Model . . . . . . . . . . . 5 3.2.2. Double Sided Provisioning Model . . . . . . . . . . . 5 3.2.3. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . 5 3.2.4. Recovery Considerations . . . . . . . . . . . . . . . 6 3.2.5. Signaling of Co-routed LSPs . . . . . . . . . . . . . 6 3.2.6. Signaling of Associated Bidirectional Protection LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.7. Signaling of Auto-tunnel Mesh-group LSPs . . . . . . . 7 3.2.8. Signaling of Inter-domain Associated Bidirectional LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.9. Teardown of Associated Bidirectional LSPs . . . . . . 8 4. Association of LSPs . . . . . . . . . . . . . . . . . . . . . 8 4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format . . . . . 8 4.1.1 Signaling of the Extended Association Object . . . . . 11 4.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1.1. Subobjects . . . . . . . . . . . . . . . . . . . . 12 4.2.2. LSP Control . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. Updated RSVP Message Formats . . . . . . . . . . . . . 12 4.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. Association Type . . . . . . . . . . . . . . . . . . . . . 13 5.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative references . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Zhang & Jing Expires February 16, 2013 [Page 2] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 1. Introduction The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. Furthermore, an associated bidirectional LSP is useful for protection switching, for Operations, Administrations and Maintenance (OAM) messages that require a reply path. The requirements described in [RFC5654] are specifically mentioned in Section 2.1. (General Requirements), and are repeated below: 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. 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. 50. The MPLS-TP control plane MUST support establishing associated bidirectional P2P LSP including configuration of protection functions and any associated maintenance functions. The above requirements are also repeated in [RFC6373]. The notion of association, as well as the corresponding Resource reSerVation Protocol (RSVP) ASSOCIATION object, is defined in [RFC4872], [RFC4873] and [RFC6689]. In that 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.ietf-ccamp-assoc-ext] defines the Extended ASSOCIATION object that can be more generally applied. This document provides a method to bind two reverse unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining the new Association Type in the Extended ASSOCIATION object and corresponding Extended ASSOCIATION object format. Zhang & Jing Expires February 16, 2013 [Page 3] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 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. Overview 3.1. Provisioning Model The associated bidirectional LSP's forward and backward directions are set up, monitored, and protected independently as required by [RFC5654]. Configuration information regarding the LSPs can be sent to one end or both ends of the LSP. Depending on the method chosen, there are two models of signaling associated bidirectional LSP. The first model is the single sided provisioning, the second model is the double sided provisioning. For the single sided provisioning, the configurations are sent to one end. Firstly, a unidirectional 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 reverse TE tunnel and LSP. For the double sided provisioning, the two unidirectional TE tunnels are configured independently, then the LSPs under the tunnels are signaled with 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. A number of scenarios exist for binding LSPs together to be an associated bidirectional LSP. These include: (1) both of them do not exist; (2) both of them exist; (3) one LSP exists, but the other one need to be established. In all scenarios described, the provisioning models discussed above are applicable. 3.2. Signaling Procedure This section describes the signaling procedures for associating bidirectional LSPs. 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) are being established or have been established, which can form an associated bidirectional LSP between node A and node B. Zhang & Jing Expires February 16, 2013 [Page 4] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 LSP1 and LSP2 are referenced at the data plane level by the identifiers: A-Node_ID::A-Tunnel_Num::A-LSP_Num::B-Node_ID and B-Node_ID::B-Tunnel_Num::B-LSP_Num::A-Node_ID, respectively [RFC6370]. A-------D-------B \ / \ / \ / C Figure 1: An example of associated bidirectional LSP 3.2.1. Single Sided Provisioning Model For the single sided provisioning model, LSP1 is triggered by LSP2 or LSP2 is triggered by LSP1. When LSP2 is triggered by LSP1, LSP1 is initialized or refreshed (if LSP1 already exists) at node A with the Extended ASSOCIATION object inserted in the Path message, the Association Type must be set to "Associated Bidirectional LSPs" and Association Flag set to "Single sided". Terminating node B is triggered to set up LSP2 by the received Extended ASSOCIATION object with the Association Type set to the value "Associated Bidirectional LSPs" and Association Flag set to "Single sided", the Extended ASSOCIATION object inserted in LSP2's Path message is the same as in LSP1's Path message. When LSP1 is triggered by LSP2, the same rules are applicable. Based on the same values of the Extended ASSOCIATION objects in the two LSPs' Path messages, the two LSPs can be bound together to be an associated bidirectional LSP. 3.2.2. Double Sided Provisioning Model For the double sided provisioning model, the Association Type must be set to "Associated Bidirectional LSPs" and Association Flag set to "Double sided". Identification of the LSPs as being Associated Bidirectional LSPs occurs based on the identical contents in the LSPs' Extended ASSOCIATION objects. 3.2.3. Asymmetric Bandwidth LSPs Zhang & Jing Expires February 16, 2013 [Page 5] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 A variety of applications, such as Internet services and the return paths of OAM messages, exist and which MAY have different bandwidth requirements for each direction. Additional [RFC5654] also specifies an asymmetric bandwidth requirement. This requirement is specifically mentioned in Section 2.1. (General Requirements), and is repeated below: 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 [RFC6387]. As to the asymmetric bandwidth associated bidirectional LSPs, the existing SENDER_TSPEC object must be carried in the REVERSE_LSP object as a sub-object in the initialized LSP's Path message to specify the reverse LSP's traffic parameters in case that single sided provisioning model is adopted. Consider the topology described in Figure 1 in the context of asymmetric associated bidirectional LSP, and take LSP2 triggered by LSP1 as an example. Node B is triggered to set up the reverse LSP2 with the corresponding asymmetric bandwidth by the Extended ASSOCIATION object with Association Type "Associated Bidirectional LSPs" and Association Flag "Single sided" and the SENDER_TSPEC sub- object in LSP1's Path message, and the SENDER_TSPEC object in the LSP2' Path message is the same as the the SENDER_TSPEC sub-object in LSP1's Path message. When double sided provisioning model is used, the two opposite LSPs with asymmetric bandwidths are concurrently initialized, and this requirement will be satisfied simultaneously. 3.2.4. Recovery Considerations Consider the topology described in Figure 1, LSP1 and LSP2 form the associated bidirectional LSP. Under the scenario of recovery, a third LSP (LSP3) may be used to protect LSP1. LSP3 can be established before or after the failure occurs, it can share the same TE tunnel with LSP1. When node A detects that LSP1 is broken or needs to be reoptimized, LSP3 will be initialized or refreshed with the Extended ASSOCIATION object inherited from LSP1's Path message. Furthermore, if LSP3 is the protecting LSP [RFC4872], the ASSOCIATION object and PROTECTION object [RFC4872] need to be inherited from the LSP1 also. In this way, based on the same Extended ASSOCIATION object, LSP2 and LSP3 will compose the new associated bidirectional LSPs. 3.2.5. Signaling of Co-routed LSPs Associated bidirectional LSPs can be non co-routed or co-routed. The Zhang & Jing Expires February 16, 2013 [Page 6] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 co-routed bidirectional LSPs traverse the same physical path in both directions. An application may request for co-routed bidirectional LSP. In this case, bidirectional LSP can only be operational when LSPs established are co-routed. When provisioned to be co-routed, LSPs are signaled with association flag set to "co-routed LSPs" in the Extended ASSOCIATION object. This flag MAY be used by a node for example to assign appropriate fast reroute bypass LSPs or by a border node for loose hop ERO expansion in case of inter-domain LSPs. If co-routed LSPs can not be established when it was requested, an RSVP Path Error message (Code = 1, Admission control failure [RFC2205], sub-code = 5, bad association type [RFC4872]) is sent back to the peer node. When associated bidirectional LSPs are not provisioned to be co- routed, which is the default mode, the LSPs may take the same or different physical path(s). 3.2.6. Signaling of Associated Bidirectional Protection LSPs In order to provide path protection, a node signals a second LSP ahead of time to switchover traffic when there is a failure on the first LSP. To identify the LSP role for path protection such as primary or secondary, PROTECTION object, ASSOCIATION object and procedures defined in [RFC4872] are used. A node uses Extended ASSOCIATION object, ASSOCIATION object and PROTECTION object to form associated bidirectional LSPs pairs for the matching path protection LSP roles. As such there will be an associated bidirectional primary LSP and an associated bidirectional secondary LSP. 3.2.7. Signaling of Auto-tunnel Mesh-group LSPs A node may build LSPs automatically to remote peers in a mesh using the mesh-group membership defined in [RFC4972]. A node provisioned to build a mesh of associated bidirectional LSPs may use identical association ID for the given mesh-group member peers. The extended association address defined in this document allows Extended ASSOCIATION objects in the LSPs to different remote peers to be unique. 3.2.8. Signaling of Inter-domain Associated Bidirectional LSPs Global association source or Global_ID [RFC6370] will be derived from Autonomous System Number (ASN) as defined in [I-D.ietf-ccamp-assoc- ext]. Autonomous System Number associated with the association source is used as global association source in both forward and reverse direction LSPs' Extended ASSOCIATION object. For inter-domain associated bidirectional LSP with single sided provisioning, Zhang & Jing Expires February 16, 2013 [Page 7] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 initiating node ASN is used as the global association source for both forward and reverse direction LSPs. For inter-domain LSPs from one AS to another AS with double sided provisioning, tie breaker rule is to use the ASN of the association source node as global association source in both forward and reverse direction LSPs. In some scenarios, a node that is the association source MAY need to learn about the Global_ID [RFC6370] of the peer node, which can be done by inserting the ASSOCIATION object with Association Type "LSP identifiers" in the outgoing Path message and being carried back in the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp- rsvpte-ext-tunnel-num]. 3.2.9. Teardown of Associated Bidirectional LSPs Associated bidirectional LSPs teardown also follows standard procedures defined in [RFC3209] and [RFC3473] either without or with the administrative status. Note that teardown procedures of the associated bidirectional LSPs are independent of each other, so it is possible that while one LSP1 follows graceful teardown with administrative status, the other LSP2 is torn down without administrative status (using PathTear/ResvTear/PathErr with state removal). However, for the double sided associated bidirectional LSPs, the teardown of LSP1 does not mean that LSP2 must be deleted, which depends on the local policy. While for the single sided associated bidirectional LSPs, the teardown of the initialized LSP should induce the teardown of the trigger-established LSP, but the teardown of the trigger-established LSP (using PathErr with state removal) should not induce the teardown of the initialized LSP (which depends on the local policy). 4. Association of LSPs 4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format The Extended ASSOCIATION object is defined in [I-D.ietf-ccamp-assoc-ext], which enables MPLS-TP required LSP identification. The extended ASSOCIATION object with fixed length is defined as follows for associated bidirectional LSPs. In this document, Extended Association ID is represented by Association Flags and Extended Association Address. Zhang & Jing Expires February 16, 2013 [Page 8] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the following 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended IPv4 Association Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the following 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Extended IPv6 Association Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Association Type: 16 bits In order to bind two reverse unidirectional LSPs to Zhang & Jing Expires February 16, 2013 [Page 9] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 be an associated bidirectional LSP, the new Association Type is defined in this document: Value Type ----- ----- 4 (TBD) Associated Bidirectional LSPs (A) Association ID: 16 bits For single sided provisioning, association ID provisioned on the initiating source is used to signal both direction LSPs. For double sided provisioning, identical association ID is provisioned on both sides to bind the two unidirectional LSPs together. Association Source: 4 or 16 bytes Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. For single sided provisioning, initiating LSP source address is used as association source for both forward and reverse LSPs. For double sided provisioning, as a tie breaker rule, lower numeric value of the IP address of the LSP source and destination node addresses is used as association source for both forward and reverse LSPs. Global Association Source: 4 bytes Same as for IPv4 and IPv6 Extended ASSOCIATION objects defined in [I-D.ietf-ccamp-assoc-ext]. When non-zero and not overridden by local policy, the Global_ID [RFC6370] that derived from the Autonomous System Number (ASN) of the association source node is used as global association source for both forward and reverse LSPs. Association Flags: 16 bits Association flags are defined to further identify the associated bidirectional LSP properties as follows. Bit 0: Single sided (value 0) | Double sided (value 1) provisioned LSPs. Bit 1: Non co-routed (value 0) | Co-routed (value 1) provisioned LSPs. Zhang & Jing Expires February 16, 2013 [Page 10] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 Extended Association Address: 4 or 16 bytes This field contains data that is additional information to support unique identification. For single sided provisioning, initiating LSP destination address is used as extended association address for both forward and reverse LSPs. For double sided provisioning, as a tie breaker rule, higher numeric value of the IP address of the LSP source and destination node addresses is used as extended association address for both forward and reverse LSPs. As described earlier, extended association address allows the unique Extended ASSOCIATION object for auto-tunnel mesh bidirectional LSP. 4.1.1 Signaling of the Extended Association Object As described in [I-D.ietf-ccamp-assoc-ext], association is always done based on matching Path state or Resv state. Upstream initialized association is represented in Extended ASSOCIATION objects carried in Path message and downstream initialized association is represented in Extended ASSOCIATION objects carried in Resv messages. The new Association Type defined in this document is only used in upstream initialized 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-ext]. 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. 4.2. REVERSE_LSP Object Path Computation Element (PCE)-based approaches, see [RFC4655], may be used for path computation of a GMPLS LSP, and consequently an associated bidirectional LSP, across domains and in a single domain. The ingress Label Switching Router (LSR), maybe serve as a PCE or Path Computation Client (PCC), has more information about the reverse LSP. When the forward LSP is signaled, the reverse LSP's traffic parameters, explicit route, LSP attributes, etc, can be carried in the REVERSE_LSP object of the forward LSP's Path message. The egress Zhang & Jing Expires February 16, 2013 [Page 11] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 LSR can be triggered to establish the reverse LSP according to the control information. 4.2.1. Format The information of the reverse LSP is specified via the REVERSE_LSP object, which is optional with class numbers in the form 11bbbbbb has the following format: Class = TBD (of the form 11bbbbbb), C_Type = 1 (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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object MUST NOT be used when the Extended ASSOCIATION object do not exist or exist but the Association Type is not "Associated Bidirectional LSPs". 4.2.1.1. Subobjects The contents of a REVERSE_LSP object are a series of variable-length data items called subobjects, which can be SENDER_TSPCE, EXPLICIT_ROUTE object (ERO), Session Attribute Object, Admin Status Object, LSP_ATTRIBUTES Object, LSP_REQUIRED_ATTRIBUTES Object, PROTECTION Object, ASSOCIATION Object, Extended ASSOCIATION Objects, etc. 4.2.2. LSP Control The signaling procedure without the REVERSE_LSP object carried in the LSP1's Path message is described in section 3.2.1, which is the default option. A node includes a REVERSE_LSP object and Extended ASSOCIATION object with an "Associated Bidirectional LSPs" Association Type in an outgoing Path message when it wishes to control the reverse LSP, and the receiver node B MUST convert the subobjects of the REVERSE_LSP object into the corresponding objects that carried in LSP2's Path message. The case of a non-supporting egress node is outside of this document. If node A want to tear down the associated bidirectional LSP, a PathTear message will be sent out and Node B is triggered to tear down LSP2. 4.2.3. Updated RSVP Message Formats Zhang & Jing Expires February 16, 2013 [Page 12] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 This section presents the RSVP message-related formats as modified by this document. Unmodified RSVP message formats are not listed. The format of a Path message is as follows: ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ... ] [ ] [ ... ] [ ] [ ... ] [ ... ] The format of the is not modified by the present document. 4.2.4. Compatibility The REVERSE_LSP object is defined with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], nodes not supporting this extension will ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message. Especially, this object received in PathTear, or PathErr messages should be forwarded immediately in the same message, but should be saved with the corresponding state and forwarded in any refresh message resulting from that state when received in Path message. 5. IANA Considerations IANA is requested to administer assignment of new values for namespace defined in this document and summarized in this section. 5.1. Association Type Within the current document, one new Association Type is defined in the Extended ASSOCIATION object. Zhang & Jing Expires February 16, 2013 [Page 13] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 Value Type ----- ----- 4 (TBD) Associated Bidirectional LSPs (A) 5.2. REVERSE_LSP Object A new class named REVERSE_LSP has been created in the 11bbbbbb range (TBD) with the following definition: Class Types or C-types (1, TBD): There are no other IANA considerations introduced by this document. 6. Security Considerations This document introduces one new Association Type, and except this, there are no security issues about the Extended ASSOCIATION object are introduced here. The procedures defined in this document result in an increase in the amount of topology information carried in signaling messages since the presence of the REVERSE_LSP object necessarily means that there is more information about associated bidirectional LSPs. Thus, in the event of the interception of a signaling message, slightly more could be deduced about the state of the network than was previously the case, but this is judged to be a very minor security risk as this information is already available via routing. 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]. 7. Acknowledgement The authors would like to thank Lou Berger for his great guidance in this work, George Swallow and Jie Dong for the discussion of recovery, Lamberto Sterling for his valuable comments on the section of asymmetric bandwidths, Daniel King for the review of the document, Attila Takacs for the discussion of the provisioning model. At the same time, the authors would also like to acknowledge the contributions of Bo Wu, Xihua Fu, Lizhong Jin for the initial discussions, and Wenjuan He for the prototype implementation. The authors would also like to thank Siva Sivabalan, Eric Osborne and Robert Sawaya for the discussion on the association object. Zhang & Jing Expires February 16, 2013 [Page 14] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 8. References 8.1. Normative references [I-D.ietf-ccamp-assoc-ext] Berger, L., Faucheur, F., and A. Narayanan, "RSVP Association Object Extensions", draft-ietf-ccamp-assoc-ext-02 (work in progress), February 2012. [I-D.draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num] Zhang, F., Venkatesan, M., Xu, Y., Gandhi, R., "RSVP-TE Extensions to Exchange MPLS-TP LSP Tunnel Numbers", draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04 (work in progress), August 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [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. [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., Psenak, P., Mabbey, P., "Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007. 8.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Zhang & Jing Expires February 16, 2013 [Page 15] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 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. [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, September 2011. [RFC6689] Berger, L., "Usage of The RSVP Association Object", RFC 6689, July 2012. Zhang & Jing Expires February 16, 2013 [Page 16] Internet-Draft RSVP-TE Extensions for Associated LSP August 15, 2012 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 Rakesh Gandhi Cisco Systems Email: rgandhi@cisco.com Zhang & Jing Expires February 16, 2013 [Page 17]