draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01.txt		draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02.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 12, 2015 China Telecom		Expires: August 17, 2015 China Telecom
	Rakesh Gandhi, Ed.		Rakesh Gandhi, Ed.
	Cisco Systems		Cisco Systems
	February 8, 2015		February 13, 2015
	RSVP-TE Extensions for Associated Bidirectional LSPs		RSVP-TE Extensions for Associated Bidirectional LSPs
	draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-01		draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02
	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 43		skipping to change at page 2, line 42
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.1. Association Types . . . . . . . . . . . . . . . . . . . . 14		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 . . . . . . . . . . . 15		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 . . . . . . . . . . . . . . . . . . . . . 16		9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 18
	10.2. Informative References . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]		The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
	specifies that MPLS-TP MUST support associated bidirectional point-		specifies that MPLS-TP MUST support associated bidirectional point-
	to-point Label Switched Paths (LSPs). These requirements are given		to-point Label Switched Paths (LSPs). These requirements are given
	in Section 2.1 (General Requirements), and are repeated below:		in Section 2.1 (General Requirements), and are repeated below:
	7. MPLS-TP MUST support associated bidirectional point-to-point		7. MPLS-TP MUST support associated bidirectional point-to-point
	LSPs.		LSPs.
	skipping to change at page 6, line 36		skipping to change at page 6, line 36
	When creation of reverse LSP2 is triggered by LSP1, LSP1 is		When creation of reverse LSP2 is triggered by LSP1, LSP1 is
	provisioned first (or refreshed if LSP1 already exists) at node A.		provisioned first (or refreshed if LSP1 already exists) at node A.
	LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted		LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted
	in the Path message, in which the Association Type indicating single		in the Path message, in which the Association Type indicating single
	sided provisioning is included. Upon receiving this Path message for		sided provisioning is included. Upon receiving this Path message for
	LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION		LSP1, node B establishes reverse LSP2. The (Extended) ASSOCIATION
	Object inserted in LSP2's Path message is the same as that received		Object inserted in LSP2's Path message is the same as that received
	in LSP1's Path message.		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 is triggered by LSP2. In both		and the creation of reverse LSP1 at node A is either triggered by
	cases, the two unidirectional LSPs are bound together to form an		LSP2 or the reverse LSP1 existed. In all three scenarios, the two
	associated bidirectional LSP based on identical (Extended)		unidirectional LSPs are bound together to form an associated
	ASSOCIATION Objects in the two LSPs' Path messages.		bidirectional LSP based on identical (Extended) 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 are		For the double sided provisioning model, both LSP1 and LSP2 are
	signaled independently with (Extended) ASSOCIATION Object inserted in		signaled independently with (Extended) ASSOCIATION Object inserted in
	the Path message, in which the Association Type indicating double		the Path message, in which the Association Type indicating double
	sided provisioning is included. In this case, the two unidirectional		sided provisioning is included. In this case, the two unidirectional
	LSPs are bound together to form an associated bidirectional LSP based		LSPs are bound together to form an associated bidirectional LSP based
	on identical (Extended) ASSOCIATION Objects in the two LSPs' Path		on identical (Extended) ASSOCIATION Objects in the two LSPs' Path
	messages. The LSPs to be selected for the association are		messages. The LSPs to be selected for the association are
	provisioned by the management action applied at both endpoints.		provisioned by the management action applied at both 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 14, line 13		skipping to change at page 14, line 13
	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" MUST create an LSP in
	the reverse direction or reject the Path message. If the creation of		the reverse direction or reject the Path message. If the creation of
	a reverse LSP fails, the egress node MUST return a PathErr with Error		a reverse LSP fails, the egress node MUST return a PathErr with Error
	code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse		code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse
	LSP Failure" defined in this document.		LSP Failure" defined in this document. Note that normal Resv
			processing SHOULD NOT be impacted by the presence of an ASSOCIATION
			Object with an Association Type set to "Single Sided Associated
			Bidirectional LSP".
	If REVERSE_LSP Object is not present in the received Path message of		When the REVERSE_LSP Object is not present, the egress node SHOULD
	the LSP, the egress node SHOULD use the LSP properties from the		initiate a reverse LSP based on the information contained in the
	received LSP Path message to signal the LSP in the reverse direction		received Path message of the forward LSP. The egress node SHOULD
	(which may depend on the local policy). The teardown of the		copy the information from the received SESSION_ATTRIBUTE, CLASS_TYPE,
	initiating LSP SHOULD trigger the teardown of the reverse associated		LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS and PROTECTION Objects to
	LSP, however, teardown of the reverse LSP SHOULD NOT trigger the		form the Path message of the reverse LSP. The IP address in the
	teardown of the initiating LSP (which may depend on the local		reverse LSP's SESSION Object SHOULD be set to the IP address carried
	policy).		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. When the forward LSP Path contains a RECORD_ROUTE Object,
			the egress node SHOULD include the received RECORD_ROUTE Object in
			the reverse LSP Path message. Local node information SHOULD also be
			recorded per Standard Path message processing. There are no specific
			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.
	If REVERSE_LSP Object is present in the received Path message of the		When REVERSE_LSP Object is present in the received Path message of
	LSP, the egress node follows the procedure defined in Section 5.2 to		the LSP, the egress node follows the procedure defined in Section 5.2
	setup the reverse LSP. If initiating node controlling the reverse		to setup the reverse LSP.
	LSP, wishes to teardown the associated bidirectional LSP, the
	initiating node sends a PathTear message to the egress node, the		In both cases, when the egress node receives a PathTear message the
	egress node MUST trigger to teardown the reverse associated LSP,		node MUST remove the associated reverse LSP using Standard PathTear
	however, teardown of the reverse LSP SHOULD NOT trigger the teardown		message processing. Tear down of the reverse LSP for other reasons
	of the initiating LSP (which may depend on the local policy).		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.
	33 lines changed or deleted		56 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/