--- 1/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01.txt 2015-02-13 08:14:57.451141755 -0800 +++ 2/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02.txt 2015-02-13 08:14:57.495142826 -0800 @@ -1,21 +1,21 @@ TEAS Working Group Fei Zhang, Ed. Internet-Draft Huawei Intended status: Standards Track Ruiquan Jing -Expires: August 12, 2015 China Telecom +Expires: August 17, 2015 China Telecom Rakesh Gandhi, Ed. Cisco Systems - February 8, 2015 + February 13, 2015 RSVP-TE Extensions for Associated Bidirectional LSPs - draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01 + draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02 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 @@ -78,31 +78,32 @@ 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 . . . . . . . . . 13 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 15 6.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 15 - 6.3. Reverse LSP Failure PathErr Sub-code . . . . . . . . . . . 15 + 6.3. Reverse LSP Failure PathErr Sub-code . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 16 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 17 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . 18 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that MPLS-TP MUST support associated bidirectional point- to-point Label Switched Paths (LSPs). These requirements are given in Section 2.1 (General Requirements), and are repeated below: 7. MPLS-TP MUST support associated bidirectional point-to-point LSPs. @@ -257,35 +257,37 @@ 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 Object inserted in the Path message, in which the Association Type indicating single sided provisioning is included. 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 is triggered by LSP2. In both - cases, 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 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. 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. + 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 @@ -607,39 +609,59 @@ modification. 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown An egress node, upon receiving a Path message containing an ASSOCIATION or Extended ASSOCIATION Object with Association Type set to "Single Sided Associated Bidirectional LSP" MUST create an LSP in the reverse direction or reject the Path message. If the creation of a reverse LSP fails, the egress node MUST return a PathErr with Error code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse - LSP Failure" defined in this document. + LSP Failure" defined in this document. Note that normal Resv + processing SHOULD NOT be impacted by the presence of an ASSOCIATION + Object with an Association Type set to "Single Sided Associated + Bidirectional LSP". - If REVERSE_LSP Object is not present in the received Path message of - the LSP, the egress node SHOULD use the LSP properties from the - received LSP Path message to signal the LSP in the reverse direction - (which may depend on the local policy). The teardown of the - initiating LSP SHOULD trigger the teardown of the reverse associated - LSP, however, teardown of the reverse LSP SHOULD NOT trigger the - teardown of the initiating LSP (which may depend on the local - policy). + When the REVERSE_LSP Object is not present, the egress node SHOULD + initiate a reverse LSP based on the information contained in the + received Path message of the forward LSP. The egress node SHOULD + copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE, + LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS and PROTECTION Objects to + form the Path message of the reverse LSP. The IP address in the + reverse LSP's SESSION Object SHOULD be set to the IP address carried + in the received SENDER_TEMPLATE Object, and conversely the IP address + in the SENDER_TEMPLATE object SHOULD be set to the IP address carried + in the received SESSION Object. There are no additional requirements + related to the IDs carried in the SESSION and SENDER_TEMPLATE + Objects. When the forward LSP Path contains a RECORD_ROUTE Object, + the egress node SHOULD include the received RECORD_ROUTE Object in + the reverse LSP Path message. Local node information SHOULD also be + recorded per Standard Path message processing. There are no specific + requirements related to other objects. The resulting Path message is + used to create the reverse LSP. From this point on, Standard Path + message processing is used in processing the resulting Path message. + In this case, changes to the received Path messages can result in + changes to the reverse LSP. In particular, any object that was + copied as part of initial Path message creation MUST be copied when + modified. - If REVERSE_LSP Object is present in the received Path message of the - LSP, the egress node follows the procedure defined in Section 5.2 to - setup the reverse LSP. If initiating node controlling the reverse - LSP, wishes to teardown the associated bidirectional LSP, the - initiating node sends a PathTear message to the egress node, the - egress node MUST trigger to teardown the reverse associated LSP, - however, teardown of the reverse LSP SHOULD NOT trigger the teardown - of the initiating LSP (which may depend on the local policy). + When REVERSE_LSP Object is present in the received Path message of + the LSP, the egress node follows the procedure defined in Section 5.2 + to setup the reverse LSP. + + In both cases, when the egress node receives a PathTear message 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. 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 Types IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry (see