draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02.txt   draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03.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 17, 2015 China Telecom Expires: August 18, 2015 China Telecom
Rakesh Gandhi, Ed. Rakesh Gandhi, Ed.
Cisco Systems Cisco Systems
February 13, 2015 February 14, 2015
RSVP-TE Extensions for Associated Bidirectional LSPs RSVP-TE Extensions for Associated Bidirectional LSPs
draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03
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 41 skipping to change at page 2, line 41
4.3. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 9 4.3. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Association Types . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 17 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
skipping to change at page 13, line 17 skipping to change at page 13, line 17
5.2. Rules For REVERSE_LSP Object 5.2. Rules For REVERSE_LSP Object
A node initiating a Path message containing an ASSOCIATION or A node initiating a Path message containing an ASSOCIATION or
Extended ASSOCIATION Object with the Association Type set to "Single Extended ASSOCIATION Object with the Association Type set to "Single
Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object
in the Path message of the LSP when it wishes to control the reverse in the Path message of the LSP when it wishes to control the reverse
LSP originating on the other endpoint node. LSP originating on the other endpoint node.
The REVERSE_LSP subobject MAY contain any of the specified objects The REVERSE_LSP subobject MAY contain any of the specified objects
which the initiating node desires to have included in the Path which the initiating node desires to have included in the Path
message for the associated reverse LSP. A REVERSE_LSP Object MUST message for the associated reverse LSP. The REVERSE_LSP Object MUST
contain at least one subobject. If there is no subobject to be added NOT be included in a REVERSE_LSP Object.
in the REVERSE_LSP Object, then the REVERSE_LSP Object MUST NOT be
added in the Path message. The REVERSE_LSP Object MUST NOT be
included in a REVERSE_LSP Object.
A node receiving a valid Path message containing a REVERSE_LSP Object A node receiving a valid Path message containing a REVERSE_LSP Object
that is not the egress node for the LSP being signaled MUST forward that is not the egress node for the LSP being signaled MUST forward
the REVERSE_LSP Object unchanged in the outgoing Path message. the REVERSE_LSP Object unchanged in the outgoing Path message.
An egress node, upon receiving a Path message containing an An egress node, upon receiving a Path message containing an
REVERSE_LSP Object MUST verify that the Path message contains an REVERSE_LSP Object MUST verify that the Path message contains an
ASSOCIATION or Extended ASSOCIATION object with the Association Type ASSOCIATION or Extended ASSOCIATION object with the Association Type
set to "Single Sided Associated Bidirectional LSP". If it does not, set to "Single Sided Associated Bidirectional LSP". If it does not,
the Path message MUST NOT trigger a reverse LSP. This verification the Path message MUST NOT trigger a reverse LSP. This verification
failure SHOULD NOT trigger any RSVP message but can be logged failure SHOULD NOT trigger any RSVP message but can be logged
locally, and perhaps reported through network management mechanisms. locally, and perhaps reported through network management mechanisms.
Once validated, the egress node MUST use the subobjects contained in Once validated, the egress node MUST use the subobjects contained in
any present REVERSE_LSP Objects in the management of the reverse LSP any present REVERSE_LSP Objects in the management of the reverse LSP
described in the previous section. Note that the contents of a described in the previous section. Note that the contents of a
REVERSE_LSP Object may change over the life of an LSP and such REVERSE_LSP Object may change over the life of an LSP and such
changes MUST result in corresponding changes in the reverse LSP. An changes MUST result in corresponding changes in the reverse LSP. An
addition or removal of the REVERSE_LSP Object in the received Path addition or removal of the REVERSE_LSP Object in the received Path
message may cause an egress node to teardown and reestablish a new message may cause an egress node to teardown and reestablish a new
skipping to change at page 14, line 9 skipping to change at page 14, line 5
The REVERSE_LSP Object is defined with class numbers in the form The REVERSE_LSP Object is defined with class numbers in the form
11bbbbbb, which ensures compatibility with non-supporting nodes. Per 11bbbbbb, which ensures compatibility with non-supporting nodes. Per
[RFC2205], such nodes will ignore the object but forward it without [RFC2205], such nodes will ignore the object but forward it without
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" and containing a
the reverse direction or reject the Path message. If the creation of REVERSE_LSP Object MUST create an LSP in the reverse direction or
a reverse LSP fails, the egress node MUST return a PathErr with Error reject the Path message. If the creation of a reverse LSP fails, the
code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse egress node MUST return a PathErr with Error code "Admission Control
LSP Failure" defined in this document. Note that normal Resv Failure (01) [RFC2205]" and Sub-code "Reverse LSP Failure" defined in
processing SHOULD NOT be impacted by the presence of an ASSOCIATION this document. Note that normal Resv processing SHOULD NOT be
Object with an Association Type set to "Single Sided Associated impacted by the presence of an ASSOCIATION Object with an Association
Bidirectional LSP". Type set to "Single Sided Associated Bidirectional LSP".
When the REVERSE_LSP Object is not present, the egress node SHOULD The egress node MUST use the subobjects contained in the REVERSE_LSP
initiate a reverse LSP based on the information contained in the Object for initiating the reverse LSP as described in Section 5.2.
received Path message of the forward LSP. The egress node SHOULD When a subobject is not present in the received REVERSE_LSP Object,
copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE, the egress node SHOULD initiate a reverse LSP based on the
LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS and PROTECTION Objects to information contained in the received Path message of the forward LSP
form the Path message of the reverse LSP. The IP address in the as following:
reverse LSP's SESSION Object SHOULD be set to the IP address carried
in the received SENDER_TEMPLATE Object, and conversely the IP address o The egress node SHOULD copy the information from the received
in the SENDER_TEMPLATE object SHOULD be set to the IP address carried SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION,
in the received SESSION Object. There are no additional requirements ADMIN_STATUS and PROTECTION Objects in the forward LSP Path message
related to the IDs carried in the SESSION and SENDER_TEMPLATE to form the Path message of the reverse LSP when the object is not
Objects. When the forward LSP Path contains a RECORD_ROUTE Object, present in the received REVERSE_LSP Object.
o 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.
o When the forward LSP Path message contains a RECORD_ROUTE Object,
the egress node SHOULD include the received RECORD_ROUTE Object in the egress node SHOULD include the received RECORD_ROUTE Object in
the reverse LSP Path message. Local node information SHOULD also be the reverse LSP Path message. Local node information SHOULD also be
recorded per Standard Path message processing. There are no specific recorded per Standard Path message processing.
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.
When REVERSE_LSP Object is present in the received Path message of o There are no specific requirements related to other objects.
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 The resulting Path message is used to create the reverse LSP. From
node MUST remove the associated reverse LSP using Standard PathTear this point on, Standard Path message processing is used in processing
message processing. Tear down of the reverse LSP for other reasons the resulting Path message. In this case, changes to the received
SHOULD NOT trigger removal of the initiating LSP, but SHOULD result Path messages can result in changes to the reverse LSP. In
in the egress node sending a PathErr with Error code "Admission particular, any object that was copied as part of initial Path
Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP Failure" message creation MUST be copied when modified.
defined in this document.
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 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. 
48 lines changed or deleted 52 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/