draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-04.txt   draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05.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 23, 2015 China Telecom Expires: August 25, 2015 China Telecom
Rakesh Gandhi, Ed. Rakesh Gandhi, Ed.
Cisco Systems Cisco Systems
February 19, 2015 February 21, 2015
RSVP-TE Extensions for Associated Bidirectional LSPs 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 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 25 skipping to change at page 2, line 25
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
2.2. Reverse Unidirectional LSPs . . . . . . . . . . . . . . . 4 2.2. Reverse Unidirectional LSPs . . . . . . . . . . . . . . . 4
2.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 4 2.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Provisioning Model Overview . . . . . . . . . . . . . . . 4 3.1. Provisioning Model Overview . . . . . . . . . . . . . . . 4
3.1.1. Single Sided Provisioning . . . . . . . . . . . . . . 5 3.1.1. Single Sided Provisioning . . . . . . . . . . . . . . 5
3.1.2. Double Sided Provisioning . . . . . . . . . . . . . . 5 3.1.2. Double Sided Provisioning . . . . . . . . . . . . . . 5
3.2. Association Signaling Overview . . . . . . . . . . . . . . 5 3.2. Association Signaling Overview . . . . . . . . . . . . . . 5
3.2.1. Single Sided Provisioning . . . . . . . . . . . . . . 6 3.2.1. Single Sided Provisioning . . . . . . . . . . . . . . 6
3.2.2. Double 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.1. Single Sided Provisioning . . . . . . . . . . . . . . 7
3.3.2. Double Sided Provisioning . . . . . . . . . . . . . . 7 3.3.2. Double Sided Provisioning . . . . . . . . . . . . . . 7
3.4. Recovery LSP Overview . . . . . . . . . . . . . . . . . . 7 3.4. Recovery LSP Overview . . . . . . . . . . . . . . . . . . 7
4. Message and Object Definitions . . . . . . . . . . . . . . . . 8 4. Message and Object Definitions . . . . . . . . . . . . . . . . 7
4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 8 4.1. RSVP Message Formats . . . . . . . . . . . . . . . . . . . 7
4.2. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . 8 4.2. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 14 5.2.1. Compatibility For REVERSE_LSP Object . . . . . . . . . 14
skipping to change at page 5, line 41 skipping to change at page 5, line 41
3.2. Association Signaling Overview 3.2. Association Signaling Overview
This section provides an overview of the association signaling This section provides an overview of the association signaling
methods for the associated bidirectional LSPs. methods for the associated bidirectional LSPs.
Three scenarios exist for binding two unidirectional LSPs together to Three scenarios exist for binding two unidirectional LSPs together to
form an associated bidirectional LSP. These are: 1) Neither form an associated bidirectional LSP. These are: 1) Neither
unidirectional LSP exists, and both must be established. 2) Both unidirectional LSP exists, and both must be established. 2) Both
unidirectional LSPs exist, but the association must be established. unidirectional LSPs exist, but the association must be established.
3) One LSP exists, but the reverse associated LSP must be 3) One LSP exists, but the reverse associated LSP must be
established. established. Following sections describe the applicable provisioning
models for each of these scenarios.
In each of the situations described above, both provisioning models
are applicable.
Path Computation Element (PCE)-based approaches [RFC4655], may be Path Computation Element (PCE)-based approaches [RFC4655], may be
used for path computation of an associated bidirectional LSP. used for path computation of an associated bidirectional LSP.
However, these approaches are outside the scope of this document. However, these approaches are outside the scope of this document.
Consider the topology described in Figure 1 (an example of associated 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 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 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 associated, form an associated bidirectional LSP between node A
and node B. and node B.
skipping to change at page 6, line 18 skipping to change at page 6, line 16
A-------D-------B A-------D-------B
\ / <-- LSP2 \ / <-- LSP2
\ / \ /
\ / \ /
C C
Figure 1: An example of associated bidirectional LSP Figure 1: An example of associated bidirectional LSP
3.2.1. Single Sided Provisioning 3.2.1. Single Sided Provisioning
For the single sided provisioning model, creation of reverse LSP1 is For the single sided provisioning model, creation of reverse LSP1
triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. shown in Figure 1 is triggered by LSP2 or creation of reverse LSP2 is
When creation of reverse LSP2 is triggered by LSP1, LSP1 is triggered by LSP1. When creation of reverse LSP2 is triggered by
provisioned first (or refreshed if LSP1 already exists) at node A. LSP1, LSP1 is provisioned first (or refreshed if LSP1 already exists)
LSP1 is then signaled with an (Extended) ASSOCIATION and REVERSE_LSP at node A. LSP1 is then signaled with an (Extended) ASSOCIATION and
Objects inserted in the Path message. The Association Type indicates REVERSE_LSP Objects inserted in the Path message. The Association
single sided provisioning. Upon receiving this Path message for Type indicates single sided provisioning. Upon receiving this Path
LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION message for LSP1, node B establishes reverse LSP2. The (Extended)
Object inserted in LSP2's Path message is the same as that received ASSOCIATION Object inserted in LSP2's Path message is the same as
in LSP1's Path message. that received 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 at node A is either triggered by and the creation of reverse LSP1 at node A is triggered by LSP2. In
LSP2 or the reverse LSP1 existed. In all three scenarios, the two both scenarios, the two unidirectional LSPs are bound together to
unidirectional LSPs are bound together to form an associated form an associated bidirectional LSP based on identical (Extended)
bidirectional LSP based on identical (Extended) ASSOCIATION Objects ASSOCIATION Objects in the two LSPs' Path messages.
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 shown in
signaled independently with (Extended) ASSOCIATION Object inserted in Figure 1 are signaled independently with (Extended) ASSOCIATION
the Path message, in which the Association Type indicating double Object inserted in the Path message, in which the Association Type
sided provisioning is included. In this case, the two unidirectional indicating double sided provisioning is included. In this case, the
LSPs are bound together to form an associated bidirectional LSP based two unidirectional LSPs are bound together to form an associated
on identical (Extended) ASSOCIATION Objects in the two LSPs' Path bidirectional LSP based on identical (Extended) ASSOCIATION Objects
messages. The LSPs to be selected for the association are in the two LSPs' Path messages. The LSPs to be selected for the
provisioned by the management action applied at both endpoints in all association are provisioned by the management action applied at both
three scenarios described above. 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 13, line 9 skipping to change at page 13, line 7
LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by
this document. The recovery mechanisms defined in [RFC4872] and this document. The recovery mechanisms defined in [RFC4872] and
[RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but
use a different value for Association Type; multiple ASSOCIATION use a different value for Association Type; multiple ASSOCIATION
Objects can be present in the LSP Path message and can coexist with Objects can be present in the LSP Path message and can coexist with
the procedures defined in this document. the procedures defined in this document.
5.2. Rules For REVERSE_LSP Object 5.2. Rules For REVERSE_LSP Object
A node initiating a Path message containing an ASSOCIATION or When a node initiates setup of an LSP using a PATH message containing
Extended ASSOCIATION Object with the Association Type set to "Single an ASSOCIATION or Extended ASSOCIATION Object, and the Association
Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object Type set to "Single Sided Associated Bidirectional LSP", the PATH
in the Path message of the LSP. 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 The REVERSE_LSP subobject MAY contain any of object that the
initiating node desires to have included in the Path message for the initiating node desires to have included in the Path message for the
associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be
included in a REVERSE_LSP Object. included in a REVERSE_LSP Object.
A transit node receiving a valid Path message containing a A transit node receiving a valid Path message containing a
REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in
the outgoing Path message. the outgoing Path message.
skipping to change at page 14, line 35 skipping to change at page 14, line 32
changes MUST result in corresponding changes in the reverse LSP. In changes MUST result in corresponding changes in the reverse LSP. In
particular, any object or subobject that was copied during the particular, any object or subobject that was copied during the
creation of the initial reverse LSP's Path message MUST be copied 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 when modified in the forward LSP, and a trigger Path message MUST be
processed. processed.
The removal of the REVERSE_LSP Object in the received Path message The removal of the REVERSE_LSP Object in the received Path message
SHOULD cause the egress node to teardown any previously established SHOULD cause the egress node to teardown any previously established
reverse LSP. reverse LSP.
When the egress node receives a PathTear message for the forward LSP, When the egress node receives a PathTear message for the forward LSP
the node MUST remove the associated reverse LSP using Standard or whenever the forward LSP is torn down, the node MUST remove the
PathTear message processing. Tear down of the reverse LSP for other associated reverse LSP using Standard PathTear message processing.
reasons SHOULD NOT trigger removal of the initiating LSP, but SHOULD Tear down of the reverse LSP for other reasons SHOULD NOT trigger
result in the egress node sending a PathErr with Error code removal of the initiating LSP, but SHOULD result in the egress node
"Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP sending a PathErr with Error code "Admission Control Failure (01)
Failure" defined in this document. [RFC2205]" and Sub-code "Reverse LSP Failure" defined in this
document.
5.2.1. Compatibility For REVERSE_LSP Object 5.2.1. Compatibility For REVERSE_LSP Object
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.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 16, line 23 skipping to change at page 16, line 23
in this document as follows: in this document as follows:
Error Code = 01: "Admission Control Failure" (see [RFC2205]) Error Code = 01: "Admission Control Failure" (see [RFC2205])
o "Admission Control Failure/Reverse LSP Failure" (TBA) o "Admission Control Failure/Reverse LSP Failure" (TBA)
There are no other IANA considerations introduced by this document. There are no other IANA considerations introduced by this document.
7. Security Considerations 7. Security Considerations
This document introduces two new Association Types, however, no new This document introduces two new Association Types, double sided
security issues relating to the (Extended) ASSOCIATION Object are associated bidirectional LSP and single sided associated
introduced. 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 The procedures defined in this document result in an increased state
information carried in signaling messages. The presence of the information carried in signaling messages. The presence of the
REVERSE_LSP Object necessarily provides more information about the REVERSE_LSP Object necessarily provides more information about the
LSPs. Thus, in the event of the interception of a signaling message, LSPs. Thus, in the event of the interception of a signaling message,
slightly more information about the state of the network could be slightly more information about the state of the network could be
deduced than was previously the case. This is judged to be a very deduced than was previously the case. This is judged to be a very
minor security risk as this information is already available via minor security risk as this information is already available via
routing. routing.
 End of changes. 12 change blocks. 
48 lines changed or deleted 53 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/