draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01.txt   draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02.txt 
TEAS Working Group Fei Zhang, Ed. TEAS Working Group Fei Zhang, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track Ruiquan Jing Intended status: Standards Track Ruiquan Jing
Expires: August 12, 2015 China Telecom Expires: August 17, 2015 China Telecom
Rakesh Gandhi, Ed. Rakesh Gandhi, Ed.
Cisco Systems Cisco Systems
February 8, 2015 February 13, 2015
RSVP-TE Extensions for Associated Bidirectional LSPs 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 Abstract
This document describes Resource reSerVation Protocol (RSVP) This document describes Resource reSerVation Protocol (RSVP)
extensions to bind two point-to-point unidirectional Label Switched extensions to bind two point-to-point unidirectional Label Switched
Paths (LSPs) into an associated bidirectional LSP. The association Paths (LSPs) into an associated bidirectional LSP. The association
is achieved by defining new Association Types for use in ASSOCIATION is achieved by defining new Association Types for use in ASSOCIATION
and in Extended ASSOCIATION Objects. One of these types enables and in Extended ASSOCIATION Objects. One of these types enables
independent provisioning of the associated bidirectional LSPs on both independent provisioning of the associated bidirectional LSPs on both
sides, while the other enables single sided provisioning. The sides, while the other enables single sided provisioning. The
skipping to change at page 2, line 43 skipping to change at page 2, line 42
4.4. REVERSE_LSP Object Definition . . . . . . . . . . . . . . 9 4.4. REVERSE_LSP Object Definition . . . . . . . . . . . . . . 9
4.4.1. REVERSE_LSP Object Format . . . . . . . . . . . . . . 9 4.4.1. REVERSE_LSP Object Format . . . . . . . . . . . . . . 9
4.4.2. REVERSE_LSP Subobjects . . . . . . . . . . . . . . . . 10 4.4.2. REVERSE_LSP Subobjects . . . . . . . . . . . . . . . . 10
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 10 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Rules For ASSOCIATION Object . . . . . . . . . . . . . . . 10 5.1. Rules For ASSOCIATION Object . . . . . . . . . . . . . . . 10
5.1.1. Compatibility For ASSOCIATION Object . . . . . . . . . 12 5.1.1. Compatibility For ASSOCIATION Object . . . . . . . . . 12
5.2. Rules For REVERSE_LSP Object . . . . . . . . . . . . . . . 13 5.2. Rules For REVERSE_LSP Object . . . . . . . . . . . . . . . 13
5.2.1. Compatibility For REVERSE_LSP Object . . . . . . . . . 13 5.2.1. Compatibility For REVERSE_LSP Object . . . . . . . . . 13
5.3. Single Sided Associated Bidirectional LSP Setup and 5.3. Single Sided Associated Bidirectional LSP Setup and
Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 14 Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Association Types . . . . . . . . . . . . . . . . . . . . 14 6.1. Association Types . . . . . . . . . . . . . . . . . . . . 15
6.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 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 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 16 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
specifies that MPLS-TP MUST support associated bidirectional point- specifies that MPLS-TP MUST support associated bidirectional point-
to-point Label Switched Paths (LSPs). These requirements are given to-point Label Switched Paths (LSPs). These requirements are given
in Section 2.1 (General Requirements), and are repeated below: in Section 2.1 (General Requirements), and are repeated below:
7. MPLS-TP MUST support associated bidirectional point-to-point 7. MPLS-TP MUST support associated bidirectional point-to-point
LSPs. LSPs.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
When creation of reverse LSP2 is triggered by LSP1, LSP1 is When creation of reverse LSP2 is triggered by LSP1, LSP1 is
provisioned first (or refreshed if LSP1 already exists) at node A. provisioned first (or refreshed if LSP1 already exists) at node A.
LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted
in the Path message, in which the Association Type indicating single in the Path message, in which the Association Type indicating single
sided provisioning is included. Upon receiving this Path message for sided provisioning is included. Upon receiving this Path message for
LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION
Object inserted in LSP2's Path message is the same as that received Object inserted in LSP2's Path message is the same as that received
in LSP1's Path message. in LSP1's Path message.
A similar procedure is used if LSP2 is provisioned first at node B 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 and the creation of reverse LSP1 at node A is either triggered by
cases, the two unidirectional LSPs are bound together to form an LSP2 or the reverse LSP1 existed. In all three scenarios, the two
associated bidirectional LSP based on identical (Extended) unidirectional LSPs are bound together to form an associated
ASSOCIATION Objects in the two LSPs' Path messages. bidirectional LSP based on identical (Extended) ASSOCIATION Objects
in the two LSPs' Path messages.
3.2.2. Double Sided Provisioning 3.2.2. Double Sided Provisioning
For the double sided provisioning model, both LSP1 and LSP2 are For the double sided provisioning model, both LSP1 and LSP2 are
signaled independently with (Extended) ASSOCIATION Object inserted in signaled independently with (Extended) ASSOCIATION Object inserted in
the Path message, in which the Association Type indicating double the Path message, in which the Association Type indicating double
sided provisioning is included. In this case, the two unidirectional sided provisioning is included. In this case, the two unidirectional
LSPs are bound together to form an associated bidirectional LSP based LSPs are bound together to form an associated bidirectional LSP based
on identical (Extended) ASSOCIATION Objects in the two LSPs' Path on identical (Extended) ASSOCIATION Objects in the two LSPs' Path
messages. The LSPs to be selected for the association are 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 3.3. Asymmetric Bandwidth Signaling Overview
This section provides an overview of the methods for signaling This section provides an overview of the methods for signaling
asymmetric upstream and downstream bandwidths for the associated asymmetric upstream and downstream bandwidths for the associated
bidirectional LSPs. bidirectional LSPs.
3.3.1. Single Sided Provisioning 3.3.1. Single Sided Provisioning
A new REVERSE_LSP Object for use in the single sided provisioning A new REVERSE_LSP Object for use in the single sided provisioning
skipping to change at page 14, line 13 skipping to change at page 14, line 13
modification. modification.
5.3. Single Sided Associated Bidirectional LSP Setup and Teardown 5.3. Single Sided Associated Bidirectional LSP Setup and Teardown
An egress node, upon receiving a Path message containing an An egress node, upon receiving a Path message containing an
ASSOCIATION or Extended ASSOCIATION Object with Association Type set ASSOCIATION or Extended ASSOCIATION Object with Association Type set
to "Single Sided Associated Bidirectional LSP" MUST create an LSP in to "Single Sided Associated Bidirectional LSP" MUST create an LSP in
the reverse direction or reject the Path message. If the creation of 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 a reverse LSP fails, the egress node MUST return a PathErr with Error
code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse 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 When the REVERSE_LSP Object is not present, the egress node SHOULD
the LSP, the egress node SHOULD use the LSP properties from the initiate a reverse LSP based on the information contained in the
received LSP Path message to signal the LSP in the reverse direction received Path message of the forward LSP. The egress node SHOULD
(which may depend on the local policy). The teardown of the copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE,
initiating LSP SHOULD trigger the teardown of the reverse associated LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS and PROTECTION Objects to
LSP, however, teardown of the reverse LSP SHOULD NOT trigger the form the Path message of the reverse LSP. The IP address in the
teardown of the initiating LSP (which may depend on the local reverse LSP's SESSION Object SHOULD be set to the IP address carried
policy). 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 When REVERSE_LSP Object is present in the received Path message of
LSP, the egress node follows the procedure defined in Section 5.2 to the LSP, the egress node follows the procedure defined in Section 5.2
setup the reverse LSP. If initiating node controlling the reverse to setup the reverse LSP.
LSP, wishes to teardown the associated bidirectional LSP, the
initiating node sends a PathTear message to the egress node, the In both cases, when the egress node receives a PathTear message the
egress node MUST trigger to teardown the reverse associated LSP, node MUST remove the associated reverse LSP using Standard PathTear
however, teardown of the reverse LSP SHOULD NOT trigger the teardown message processing. Tear down of the reverse LSP for other reasons
of the initiating LSP (which may depend on the local policy). 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 6. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespace defined in this document and summarized in this section. namespace defined in this document and summarized in this section.
6.1. Association Types 6.1. Association Types
IANA maintains the "Generalized Multi-Protocol Label Switching IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry (see (GMPLS) Signaling Parameters" registry (see
 End of changes. 11 change blocks. 
33 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/