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/