draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06.txt   draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.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 28, 2015 China Telecom Expires: September 4, 2015 China Telecom
Rakesh Gandhi, Ed. Rakesh Gandhi, Ed.
Cisco Systems Cisco Systems
February 24, 2015 March 3, 2015
RSVP-TE Extensions for Associated Bidirectional LSPs RSVP-TE Extensions for Associated Bidirectional LSPs
draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07
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 9, line 43 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 in the forward LSP Path message is used to The REVERSE_LSP Object is carried in the Path message of a forward
carry information to be used by the reverse LSP. The object also LSP to provide information to be used by the reverse LSP. The object
indicates that the LSP is the forward LSP of a single sided also indicates that the LSP is the forward LSP of a single sided
provisioned associated bidirectional LSP. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 10, line 25 skipping to change at page 10, line 25
4.4.2. REVERSE_LSP Subobjects 4.4.2. REVERSE_LSP Subobjects
Subobjects are used to override the default contents of Path message Subobjects are used to override the default contents of Path message
of a Reverse LSP, see Section 5.2. The contents of a REVERSE_LSP of a Reverse LSP, see Section 5.2. The contents of a REVERSE_LSP
Object is zero or more variable length subobjects that have the same Object is zero or more variable length subobjects that have the same
format as RSVP Objects, see Section 3.1.2 of [RFC2205]. Any Object format as RSVP Objects, see Section 3.1.2 of [RFC2205]. Any Object
that may be carried in a Path message MAY be carried in the that may be carried in a Path message MAY be carried in the
REVERSE_LSP Object. Subobject ordering MUST follow any Path message REVERSE_LSP Object. Subobject ordering MUST follow any Path message
Object ordering requirements. Object ordering requirements.
Examples of the Path message objects that can be carried in the Examples of the Path message Objects that can be carried in the
REVERSE_LSP Object are (but not limited to): REVERSE_LSP Object are (but not limited to):
- SENDER_TSPEC [RFC2205] - SENDER_TSPEC [RFC2205]
- EXPLICIT_ROUTE Object (ERO) [RFC3209] - EXPLICIT_ROUTE Object (ERO) [RFC3209]
- 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
skipping to change at page 16, line 25 skipping to change at page 16, line 25
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 for the (Extended) This document introduces two new Association Types for the (Extended)
ASSOCIATION Object, double sided associated bidirectional LSP and ASSOCIATION Object, double sided associated bidirectional LSP and
single sided associated bidirectional LSP. For the double sided single sided associated bidirectional LSP. The introduction of these
associated bidirectional LSP, no new security issues relating to the types, by themselves, introduce no additional information to
(Extended) ASSOCIATION Object are introduced. For the single sided signaling. Related security considerations are already covered for
associated bidirectional LSP, the initiating node triggers an LSP this in RFC6780.
creation on the remote node by signaling a REVERSE_LSP Object. This
introduces a security issue on the remote node. An administrative
policy may be provisioned on the remote node to deny the triggering
of a reverse LSP by an initiating node.
The REVERSE_LSP Object in the forward LSP Path message of the single
sided associated bidirectional LSP may carry parameters for the
reverse LSP. This does allow for additional information to be
conveyed, but this information is not fundamentally different from
the information that is already carried in RSVP. Therefore, there
are no new risks or security considerations introduced by this
object.
Otherwise, this document introduces no additional security The REVERSE_LSP Object is carried in the Path message of a forward
considerations. For a general discussion on MPLS and GMPLS related LSP of the single sided associated bidirectional LSP. It can carry
parameters for the reverse LSP. This does allow for additional
information to be conveyed, but this information is not fundamentally
different from the information that is already carried in a
bidirectional LSP message. The processing of such messages are
already subject to local policy, as well as security considerations
discussions. 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
of asymmetric bandwidths, Attila Takacs for the discussion of the of asymmetric bandwidths, Attila Takacs for the discussion of the
provisioning model and Lou Berger, Daniel King and Deborah Brungard provisioning model and Lou Berger, Daniel King and Deborah Brungard
for the review of the document. At the same time, the authors would for the review of the document. At the same time, the authors would
 End of changes. 7 change blocks. 
25 lines changed or deleted 19 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/