draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05.txt   draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06.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 25, 2015 China Telecom Expires: August 28, 2015 China Telecom
Rakesh Gandhi, Ed. Rakesh Gandhi, Ed.
Cisco Systems Cisco Systems
February 21, 2015 February 24, 2015
RSVP-TE Extensions for Associated Bidirectional LSPs RSVP-TE Extensions for Associated Bidirectional LSPs
draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-05 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06
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
REVERSE_LSP Object is also defined to enable a single endpoint to REVERSE_LSP Object is also defined to enable a single endpoint to
specify all the parameters of an associated LSP in the single sided trigger creation of the reverse LSP and to specify parameters of the
provisioning case. reverse LSP in the single sided provisioning case.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
to the [RFC4872] defined ASSOCIATION Objects and the [RFC6780] to the [RFC4872] defined ASSOCIATION Objects and the [RFC6780]
defined the Extended ASSOCIATION Objects collectively as the defined the Extended ASSOCIATION Objects collectively as the
(Extended) ASSOCIATION Objects. (Extended) ASSOCIATION Objects.
This document specifies mechanisms for binding two reverse This document specifies mechanisms for binding two reverse
unidirectional LSPs into an associated bidirectional LSP. The unidirectional 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
(Extended) ASSOCIATION Objects. One of these types enables (Extended) ASSOCIATION Objects. One of these types enables
independent provisioning of the associated bidirectional LSPs, while independent provisioning of the associated bidirectional LSPs, while
the other enables single sided provisioning. The REVERSE_LSP Object the other enables single sided provisioning. The REVERSE_LSP Object
is also defined to enable a single endpoint to specify any parameter is also defined to enable a single endpoint to trigger creation of
of an associated LSP in the single sided provisioning case. For the reverse LSP and to specify parameters of the reverse LSP in the
example, the REVERSE_LSP Object allow asymmetric upstream and single sided provisioning case. For example, the REVERSE_LSP Object
downstream bandwidths for the associated bidirectional LSP. allow asymmetric upstream and downstream bandwidths for the
associated bidirectional LSP.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Reverse Unidirectional LSPs 2.2. Reverse Unidirectional LSPs
skipping to change at page 5, line 49 skipping to change at page 5, line 49
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. Following sections describe the applicable provisioning established. Following sections describe the applicable provisioning
models for each of these scenarios. models for each of these scenarios.
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 node A to B, takes the path A,D,B and
from B to A takes the path B,D,C,A. These two LSPs, once established LSP2 from node B to A takes the path B,D,C,A. These two LSPs, once
and associated, form an associated bidirectional LSP between node A established and associated, form an associated bidirectional LSP
and node B. between node A and node B.
LSP1 --> LSP1 -->
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
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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 triggered by LSP2. In and the creation of reverse LSP1 at node A is triggered by LSP2. In
both scenarios, the two unidirectional LSPs are bound together to both scenarios, the two unidirectional LSPs are bound together to
form an associated bidirectional LSP based on identical (Extended) form an associated bidirectional LSP based on identical (Extended)
ASSOCIATION Objects in the two LSPs' Path messages. 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 shown in For the double sided provisioning model, both LSP1 and LSP2 shown in
Figure 1 are signaled independently with (Extended) ASSOCIATION Figure 1 are signaled independently with (Extended) ASSOCIATION
Object inserted in the Path message, in which the Association Type Objects inserted in the Path messages, in which the Association Type
indicating double sided provisioning is included. In this case, the indicating double sided provisioning is included. In this case, the
two unidirectional LSPs are bound together to form an associated two unidirectional LSPs are bound together to form an associated
bidirectional LSP based on identical (Extended) ASSOCIATION Objects bidirectional LSP based on identical (Extended) ASSOCIATION Objects
in the two LSPs' Path messages. The LSPs to be selected for the in the two LSPs' Path messages. The LSPs to be selected for the
association are provisioned by the management action applied at both association are provisioned by the management action applied at both
endpoints in all 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
model is defined in this document, in Section 4.4. When the single model is defined in this document, in Section 4.4. The REVERSE_LSP
sided provisioning model is used, a SENDER_TSPEC Object can be added Object allows the initiating node of the single sided provisioned LSP
in the REVERSE_LSP Object as a subobject in the initiating LSP's Path to trigger creation of the reverse LSP on the remote node. When the
message to specify a different bandwidth for the reverse LSP. As single sided provisioning model is used, a SENDER_TSPEC Object can be
described in Section 4.4, addition of the REVERSE_LSP Object also added in the REVERSE_LSP Object as a subobject in the initiating
allows the initiating node to control other aspects of the reverse LSP's Path message to specify a different bandwidth for the reverse
LSP (such as its path) by including other Objects in a REVERSE_LSP LSP. As described in Section 4.4, addition of the REVERSE_LSP Object
Object. also allows the initiating node to control other aspects of the
reverse LSP (such as its path) by including other Objects in a
REVERSE_LSP Object.
Consider again the topology described in Figure 1, where the creation Consider again the topology described in Figure 1, where the creation
of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the
(Extended) ASSOCIATION Object with Association Type indicating single (Extended) ASSOCIATION Object with Association Type indicating single
sided provisioning and inserts a SENDER_TSPEC subobject for use by sided provisioning and inserts a SENDER_TSPEC subobject for use by
LSP2 in the REVERSE_LSP Object in the Path message. Node B then LSP2 in the REVERSE_LSP Object in the Path message. Node B then
establishes the LSP2 in the reverse direction using the asymmetric establishes the LSP2 in the reverse direction using the asymmetric
bandwidth thus specified by LSP1 and allows node A to control the bandwidth thus specified by LSP1 and allows node A to control the
reverse LSP2. reverse LSP2.
skipping to change at page 7, line 44 skipping to change at page 7, line 46
3.4. Recovery LSP Overview 3.4. Recovery LSP Overview
Recovery of each unidirectional LSP forming the bidirectional LSP is Recovery of each unidirectional LSP forming the bidirectional LSP is
independent [RFC5654] and is based on the parameters signaled in independent [RFC5654] and is based on the parameters signaled in
their respective RSVP Path messages. their respective RSVP Path messages.
Recovery LSP association is based on the identical content of the Recovery LSP association is based on the identical content of the
(Extended) ASSOCIATION Objects signaled in their Path messages during (Extended) ASSOCIATION Objects signaled in their Path messages during
the initial LSP setup for both single sided and double sided the initial LSP setup for both single sided and double sided
provisioning. As defined, see [RFC6780], multiple ASSOCIATION provisioning. As defined, see [RFC6780], multiple ASSOCIATION
objects may be present in the signaling of a single LSP. Objects may be present in the signaling of a single LSP.
4. Message and Object Definitions 4. Message and Object Definitions
4.1. RSVP Message Formats 4.1. RSVP Message Formats
This section presents the RSVP message-related formats as modified by This section presents the RSVP message-related formats as modified by
this document. Unmodified RSVP message formats are not listed. this document. Unmodified RSVP message formats are not listed.
The format of a Path message is as follows: The format of a Path message is as follows:
skipping to change at page 9, line 40 skipping to change at page 9, line 43
Extended Association ID: Extended Association ID:
For both single sided and double sided provisioning, Extended For both single sided and double sided provisioning, Extended
Association ID, when used, MUST be set to a value selected by the Association ID, when used, MUST be set to a value selected by the
node that originates the association for the bidirectional LSP. node that originates the association for the bidirectional LSP.
4.4. REVERSE_LSP Object Definition 4.4. REVERSE_LSP Object Definition
4.4.1. REVERSE_LSP Object Format 4.4.1. REVERSE_LSP Object Format
The REVERSE_LSP Object is used to carry information to be used by the The REVERSE_LSP Object in the forward LSP Path message is used to
reverse LSP. The object also indicates that the LSP is the forward carry information to be used by the reverse LSP. The object also
LSP of a single sided provisioned associated bidirectional LSP. indicates that the LSP is the forward LSP of a single sided
provisioned associated bidirectional LSP.
The Object has the following format: The Object has the following format:
Class_Num = 203, C_Type = 1. Class_Num = 203, C_Type = 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
skipping to change at page 10, line 38 skipping to change at page 10, line 40
- SESSION_ATTRIBUTE Object [RFC3209] - SESSION_ATTRIBUTE Object [RFC3209]
- ADMIN_STATUS Object [RFC3473] - ADMIN_STATUS Object [RFC3473]
- LSP_REQUIRED_ATTRIBUTES Object [RFC5420] - LSP_REQUIRED_ATTRIBUTES Object [RFC5420]
- PROTECTION Object [RFC3473] [RFC4872] - PROTECTION Object [RFC3473] [RFC4872]
5. Processing Rules 5. Processing Rules
In general, the processing rules for the ASSOCIATION Object are as In general, the processing rules for the ASSOCIATION Object are as
specified in [RFC4872] and Extended ASSOCIATION Object are specified specified in [RFC4872] and Extended ASSOCIATION Object are specified
in [RFC6780]. Following sections describe the rules for processing in [RFC6780]. Following sections describe the rules for processing
(Extended) ASSOCIATION and REVERSE_LSP objects for associated (Extended) ASSOCIATION Object for both double sided and single sided
bidirectional LSPs. associated bidirectional LSPs and REVERSE_LSP Object for single sided
associated bidirectional LSPs.
5.1. Rules For ASSOCIATION Object 5.1. Rules For ASSOCIATION Object
This section defines the processing for the association of two This section defines the processing for the association of two
unidirectional LSPs to form an associated bidirectional LSP. Such unidirectional LSPs to form an associated bidirectional LSP. Such
association is based on the use of an (Extended) ASSOCIATION Object. association is based on the use of an (Extended) ASSOCIATION Object.
The procedures related to the actual identification of associations The procedures related to the actual identification of associations
between LSPs based on (Extended) ASSOCIATION Objects are defined in between LSPs based on (Extended) ASSOCIATION Objects are defined in
[RFC6780]. [RFC6780] specifies that in the absence of Association [RFC6780]. [RFC6780] specifies that in the absence of Association
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, double sided This document introduces two new Association Types for the (Extended)
associated bidirectional LSP and single sided associated ASSOCIATION Object, double sided associated bidirectional LSP and
bidirectional LSP. For the double sided associated bidirectional single sided associated bidirectional LSP. For the double sided
LSP, no new security issues relating to the (Extended) ASSOCIATION associated bidirectional LSP, no new security issues relating to the
Object are introduced. For the single sided associated bidirectional (Extended) ASSOCIATION Object are introduced. For the single sided
LSP, the initiating node triggers an LSP creation on the remote node. associated bidirectional LSP, the initiating node triggers an LSP
This introduces a security issue on the remote node. An creation on the remote node by signaling a REVERSE_LSP Object. This
administrative policy may be provisioned on the remote node to deny introduces a security issue on the remote node. An administrative
the triggering of an LSP by an initiating node. policy may be provisioned on the remote node to deny the triggering
of a reverse LSP by an initiating node.
The procedures defined in this document result in an increased state The REVERSE_LSP Object in the forward LSP Path message of the single
information carried in signaling messages. The presence of the sided associated bidirectional LSP may carry parameters for the
REVERSE_LSP Object necessarily provides more information about the reverse LSP. This does allow for additional information to be
LSPs. Thus, in the event of the interception of a signaling message, conveyed, but this information is not fundamentally different from
slightly more information about the state of the network could be the information that is already carried in RSVP. Therefore, there
deduced than was previously the case. This is judged to be a very are no new risks or security considerations introduced by this
minor security risk as this information is already available via object.
routing.
Otherwise, this document introduces no additional security Otherwise, this document introduces no additional security
considerations. For a general discussion on MPLS and GMPLS related considerations. For a general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [RFC5920]. security issues, see the MPLS/GMPLS security framework [RFC5920].
8. Acknowledgement 8. Acknowledgement
The authors would like to thank Lou Berger and George Swallow for The authors would like to thank Lou Berger and George Swallow for
their great guidance in this work, Jie Dong for the discussion of their great guidance in this work, Jie Dong for the discussion of
recovery, Lamberto Sterling for his valuable comments on the section recovery, Lamberto Sterling for his valuable comments on the section
 End of changes. 13 change blocks. 
45 lines changed or deleted 50 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/