--- 1/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-04.txt 2015-02-21 07:14:59.184057189 -0800 +++ 2/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05.txt 2015-02-21 07:14:59.224058151 -0800 @@ -1,21 +1,21 @@ TEAS Working Group Fei Zhang, Ed. Internet-Draft Huawei Intended status: Standards Track Ruiquan Jing -Expires: August 23, 2015 China Telecom +Expires: August 25, 2015 China Telecom Rakesh Gandhi, Ed. Cisco Systems - February 19, 2015 + February 21, 2015 RSVP-TE Extensions for Associated Bidirectional LSPs - draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-04 + draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05 Abstract This document describes Resource reSerVation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single sided provisioning. The @@ -60,26 +60,26 @@ 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.2. Reverse Unidirectional LSPs . . . . . . . . . . . . . . . 4 2.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Provisioning Model Overview . . . . . . . . . . . . . . . 4 3.1.1. Single Sided Provisioning . . . . . . . . . . . . . . 5 3.1.2. Double Sided Provisioning . . . . . . . . . . . . . . 5 3.2. Association Signaling Overview . . . . . . . . . . . . . . 5 3.2.1. Single Sided Provisioning . . . . . . . . . . . . . . 6 3.2.2. Double Sided Provisioning . . . . . . . . . . . . . . 6 - 3.3. Asymmetric Bandwidth Signaling Overview . . . . . . . . . 7 + 3.3. Asymmetric Bandwidth Signaling Overview . . . . . . . . . 6 3.3.1. Single Sided Provisioning . . . . . . . . . . . . . . 7 3.3.2. Double Sided Provisioning . . . . . . . . . . . . . . 7 3.4. Recovery LSP Overview . . . . . . . . . . . . . . . . . . 7 - 4. Message and Object Definitions . . . . . . . . . . . . . . . . 8 - 4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 8 + 4. Message and Object Definitions . . . . . . . . . . . . . . . . 7 + 4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 7 4.2. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . 8 4.3. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 9 4.4. REVERSE_LSP Object Definition . . . . . . . . . . . . . . 9 4.4.1. REVERSE_LSP Object Format . . . . . . . . . . . . . . 9 4.4.2. REVERSE_LSP Subobjects . . . . . . . . . . . . . . . . 10 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Rules For ASSOCIATION Object . . . . . . . . . . . . . . . 10 5.1.1. Compatibility For ASSOCIATION Object . . . . . . . . . 12 5.2. Rules For REVERSE_LSP Object . . . . . . . . . . . . . . . 13 5.2.1. Compatibility For REVERSE_LSP Object . . . . . . . . . 14 @@ -217,24 +217,22 @@ 3.2. Association Signaling Overview This section provides an overview of the association signaling methods for the associated bidirectional LSPs. Three scenarios exist for binding two unidirectional LSPs together to form an associated bidirectional LSP. These are: 1) Neither unidirectional LSP exists, and both must be established. 2) Both unidirectional LSPs exist, but the association must be established. 3) One LSP exists, but the reverse associated LSP must be - established. - - In each of the situations described above, both provisioning models - are applicable. + established. Following sections describe the applicable provisioning + models for each of these scenarios. Path Computation Element (PCE)-based approaches [RFC4655], may be used for path computation of an associated bidirectional LSP. However, these approaches are outside the scope of this document. Consider the topology described in Figure 1 (an example of associated bidirectional LSP). LSP1 from A to B, takes the path A,D,B and LSP2 from B to A takes the path B,D,C,A. These two LSPs, once established and associated, form an associated bidirectional LSP between node A and node B. @@ -243,49 +241,48 @@ A-------D-------B \ / <-- LSP2 \ / \ / C Figure 1: An example of associated bidirectional LSP 3.2.1. Single Sided Provisioning - For the single sided provisioning model, creation of reverse LSP1 is - triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. - When creation of reverse LSP2 is triggered by LSP1, LSP1 is - provisioned first (or refreshed if LSP1 already exists) at node A. - LSP1 is then signaled with an (Extended) ASSOCIATION and REVERSE_LSP - Objects inserted in the Path message. The Association Type indicates - single sided provisioning. Upon receiving this Path message for - LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION - Object inserted in LSP2's Path message is the same as that received - in LSP1's Path message. + For the single sided provisioning model, creation of reverse LSP1 + shown in Figure 1 is triggered by LSP2 or creation of reverse LSP2 is + triggered by LSP1. When creation of reverse LSP2 is triggered by + LSP1, LSP1 is provisioned first (or refreshed if LSP1 already exists) + at node A. LSP1 is then signaled with an (Extended) ASSOCIATION and + REVERSE_LSP Objects inserted in the Path message. The Association + Type indicates single sided provisioning. Upon receiving this Path + message for LSP1, node B establishes reverse LSP2. The (Extended) + ASSOCIATION Object inserted in LSP2's Path message is the same as + that received in LSP1's Path message. A similar procedure is used if LSP2 is provisioned first at node B - and the creation of reverse LSP1 at node A is either triggered by - LSP2 or the reverse LSP1 existed. In all three scenarios, the two - unidirectional LSPs are bound together to form an associated - bidirectional LSP based on identical (Extended) ASSOCIATION Objects - in the two LSPs' Path messages. + and the creation of reverse LSP1 at node A is triggered by LSP2. In + both scenarios, the two unidirectional LSPs are bound together to + form an associated bidirectional LSP based on identical (Extended) + ASSOCIATION Objects in the two LSPs' Path messages. 3.2.2. Double Sided Provisioning - For the double sided provisioning model, both LSP1 and LSP2 are - signaled independently with (Extended) ASSOCIATION Object inserted in - the Path message, in which the Association Type indicating double - sided provisioning is included. In this case, the two unidirectional - LSPs are bound together to form an associated bidirectional LSP based - on identical (Extended) ASSOCIATION Objects in the two LSPs' Path - messages. The LSPs to be selected for the association are - provisioned by the management action applied at both endpoints in all - three scenarios described above. + For the double sided provisioning model, both LSP1 and LSP2 shown in + Figure 1 are signaled independently with (Extended) ASSOCIATION + Object inserted in the Path message, in which the Association Type + indicating double sided provisioning is included. In this case, the + two unidirectional LSPs are bound together to form an associated + bidirectional LSP based on identical (Extended) ASSOCIATION Objects + in the two LSPs' Path messages. The LSPs to be selected for the + association are provisioned by the management action applied at both + endpoints in all three scenarios described above. 3.3. Asymmetric Bandwidth Signaling Overview This section provides an overview of the methods for signaling asymmetric upstream and downstream bandwidths for the associated bidirectional LSPs. 3.3.1. Single Sided Provisioning A new REVERSE_LSP Object for use in the single sided provisioning @@ -560,24 +557,25 @@ LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by this document. The recovery mechanisms defined in [RFC4872] and [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but use a different value for Association Type; multiple ASSOCIATION Objects can be present in the LSP Path message and can coexist with the procedures defined in this document. 5.2. Rules For REVERSE_LSP Object - A node initiating a Path message containing an ASSOCIATION or - Extended ASSOCIATION Object with the Association Type set to "Single - Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object - in the Path message of the LSP. + When a node initiates setup of an LSP using a PATH message containing + an ASSOCIATION or Extended ASSOCIATION Object, and the Association + Type set to "Single Sided Associated Bidirectional LSP", the PATH + message MUST carry the REVERSE_LSP Object to trigger creation of a + reverse LSP on the egress node. The REVERSE_LSP subobject MAY contain any of object that the initiating node desires to have included in the Path message for the associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be included in a REVERSE_LSP Object. A transit node receiving a valid Path message containing a REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in the outgoing Path message. @@ -633,27 +631,28 @@ changes MUST result in corresponding changes in the reverse LSP. In particular, any object or subobject that was copied during the creation of the initial reverse LSP's Path message MUST be copied when modified in the forward LSP, and a trigger Path message MUST be processed. The removal of the REVERSE_LSP Object in the received Path message SHOULD cause the egress node to teardown any previously established reverse LSP. - When the egress node receives a PathTear message for the forward LSP, - the node MUST remove the associated reverse LSP using Standard - PathTear message processing. Tear down of the reverse LSP for other - reasons SHOULD NOT trigger removal of the initiating LSP, but SHOULD - result in the egress node sending a PathErr with Error code - "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP - Failure" defined in this document. + When the egress node receives a PathTear message for the forward LSP + or whenever the forward LSP is torn down, the node MUST remove the + associated reverse LSP using Standard PathTear message processing. + Tear down of the reverse LSP for other reasons SHOULD NOT trigger + removal of the initiating LSP, but SHOULD result in the egress node + sending a PathErr with Error code "Admission Control Failure (01) + [RFC2205]" and Sub-code "Reverse LSP Failure" defined in this + document. 5.2.1. Compatibility For REVERSE_LSP Object The REVERSE_LSP Object is defined with class numbers in the form 11bbbbbb, which ensures compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification. 6. IANA Considerations @@ -708,23 +707,29 @@ in this document as follows: Error Code = 01: "Admission Control Failure" (see [RFC2205]) o "Admission Control Failure/Reverse LSP Failure" (TBA) There are no other IANA considerations introduced by this document. 7. Security Considerations - This document introduces two new Association Types, however, no new - security issues relating to the (Extended) ASSOCIATION Object are - introduced. + This document introduces two new Association Types, double sided + associated bidirectional LSP and single sided associated + bidirectional LSP. For the double sided associated bidirectional + LSP, no new security issues relating to the (Extended) ASSOCIATION + Object are introduced. For the single sided associated bidirectional + LSP, the initiating node triggers an LSP creation on the remote node. + This introduces a security issue on the remote node. An + administrative policy may be provisioned on the remote node to deny + the triggering of an LSP by an initiating node. The procedures defined in this document result in an increased state information carried in signaling messages. The presence of the REVERSE_LSP Object necessarily provides more information about the LSPs. Thus, in the event of the interception of a signaling message, slightly more information about the state of the network could be deduced than was previously the case. This is judged to be a very minor security risk as this information is already available via routing.