draft-ietf-teas-rsvp-rmr-extension-01.txt		draft-ietf-teas-rsvp-rmr-extension-02.txt
	TEAS WG A. Deshmukh		TEAS WG A. Deshmukh
	Internet-Draft K. Kompella		Internet-Draft K. Kompella
	Intended status: Standards Track Juniper Networks, Inc.		Intended status: Standards Track Juniper Networks, Inc.
	Expires: December 30, 2018 June 28, 2018		Expires: January 9, 2020 July 8, 2019
	RSVP Extensions for RMR		RSVP Extensions for RMR
	draft-ietf-teas-rsvp-rmr-extension-01		draft-ietf-teas-rsvp-rmr-extension-02
	Abstract		Abstract
	Ring topology is commonly found in access and aggregation networks.		Ring topology is commonly found in access and aggregation networks.
	However, the use of MPLS as the transport protocol for rings is very		However, the use of MPLS as the transport protocol for rings is very
	limited today. draft-ietf-mpls-rmr-02 describes a mechanism to		limited today. {{!I-D.ietf-mpls-rmr}} describes a mechanism to
	handle rings efficiently using MPLS. This document describes the		handle rings efficiently using MPLS. This document describes the
	extensions to the RSVP-TE protocol for signaling MPLS label switched		extensions to the RSVP-TE protocol for signaling MPLS label switched
	paths in rings.		paths in rings.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 30, 2018.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This document extends RSVP-TE [RFC3209] to establish label-switched		This document extends RSVP-TE [RFC3209] to establish label-switched
	path (LSP) tunnels in the ring topology. Rings are auto-discovered		path (LSP) tunnels in the ring topology. Rings are auto-discovered
	using the mechanisms mentioned in the [draft-ietf-mpls-rmr-02].		using the mechanisms mentioned in the {{!I-D.ietf-mpls-rmr}}. Either
	Either IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for		IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for auto-
	auto-discovering the rings.		discovering the rings.
	After the rings are auto-discovered, each node in the ring knows its		After the rings are auto-discovered, each node in the ring knows its
	clockwise(CW) and anti-clockwise (AC) ring neighbors and its ring		clockwise(CW) and anti-clockwise (AC) ring neighbors and its ring
	links. All of the express links in the ring also get identified as		links. All of the express links in the ring also get identified as
	part of the auto-discovery process. At this point, every node in the		part of the auto-discovery process. At this point, every node in the
	ring informs the RSVP protocol to begin the signaling of the ring		ring informs the RSVP protocol to begin the signaling of the ring
	LSPs.		LSPs.
	Section 2 covers the terminology used in this document. Section 3		Section 2 covers the terminology used in this document. Section 3
	presents the RSVP protocol extensions needed to support MPLS rings.		presents the RSVP protocol extensions needed to support MPLS rings.
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	define the ring direction of the corresponding Path message.		define the ring direction of the corresponding Path message.
	ClockWise(CW) Direction 0x01: This flag indicates that the		ClockWise(CW) Direction 0x01: This flag indicates that the
	corresponding Path message is traveling in the ClockWise(CW)		corresponding Path message is traveling in the ClockWise(CW)
	direction along the ring.		direction along the ring.
	Anti-ClockWise(AC) Direction 0x02: This flag indicates that the		Anti-ClockWise(AC) Direction 0x02: This flag indicates that the
	corresponding Path message is traveling in the Anti-ClockWise(AC)		corresponding Path message is traveling in the Anti-ClockWise(AC)
	direction along the ring.		direction along the ring.
			Express Link 0x04: This flag indicates that the corresponding Path
			message is traveling along the Express link in the ring.
	3.2. SENDER_TEMPLATE,FILTER_SPEC Objects		3.2. SENDER_TEMPLATE,FILTER_SPEC Objects
	There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC		There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC
	objects. The format of the above 2 objects will be similar to the		objects. The format of the above 2 objects will be similar to the
	definitions in RFC 3209. [RFC3209] Only the semantics of these		definitions in RFC 3209. [RFC3209] Only the semantics of these
	objects will slightly change. This will be explained in section		objects will slightly change. This will be explained in section
	Section 4.6 below.		Section 4.6 below.
	4. Ring Signaling Procedures		4. Ring Signaling Procedures
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	4.2.2. Resv Processing for RMR		4.2.2. Resv Processing for RMR
	When Egress node R0 receives the modified Path message, it replies		When Egress node R0 receives the modified Path message, it replies
	with the a Resv message containing multiple FLOW_DESCRIPTOR objects.		with the a Resv message containing multiple FLOW_DESCRIPTOR objects.
	There should be 1 FLOW_DESCRIPTOR object corresponding to each of the		There should be 1 FLOW_DESCRIPTOR object corresponding to each of the
	SENDER_TEMPLATE object in the incoming Path message. The SESSION		SENDER_TEMPLATE object in the incoming Path message. The SESSION
	object of the Resv message will exactly match with the received Path		object of the Resv message will exactly match with the received Path
	message.		message.
	[RFC 3209] already supports receiving a Resv message with multiple		RFC 3209[RFC3209] already supports receiving a Resv message with
	flow-descriptors in it, as described in section 3.2 in that document.		multiple flow-descriptors in it, as described in section 3.2 in that
	In each flow-descriptor there is a separate:		document. In each flow-descriptor there is a separate:
	a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent		a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent
	in the Path message which could be admitted after admission-control		in the Path message which could be admitted after admission-control
	downstream, and		downstream, and
	b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent		b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent
	in the Path message that could be admitted after admission-control		in the Path message that could be admitted after admission-control
	downstream.		downstream.
	Each transit node removes the FLOW-DESCRIPTOR corresponding to itself		Each transit node removes the FLOW-DESCRIPTOR corresponding to itself
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 29 ¶
	For the ring links which are common between the old and new LSPs, the		For the ring links which are common between the old and new LSPs, the
	LSPs will share resources(SE style reservation) on those ring links.		LSPs will share resources(SE style reservation) on those ring links.
	Note that here we are using Ring Instance ID in the SESSION object to		Note that here we are using Ring Instance ID in the SESSION object to
	share resources instead of the LSP_ID in the SENDER_TEMPLATE		share resources instead of the LSP_ID in the SENDER_TEMPLATE
	Object(which is used in RSVP-TE for sharing resources as described in		Object(which is used in RSVP-TE for sharing resources as described in
	RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different		RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different
	functionality as described in section Section 4.6.		functionality as described in section Section 4.6.
	4.5. Express Links		4.5. Express Links
	The details for signaling over express links will be given in a		Express links are discovered once ring nodes, ring links and
	future version.		directions have been established. As defined earlier, express links
			are links joining non-neighboring ring nodes. Express links are both
			clockwise and anti-clockwise.
			A ring node with an Express link replicates the incoming Path message
			over the Express link. The "Express Link" flag is set in the SESSION
			object of the replicated Path message. Also, the ring node Ri
			includes an additional SENDER_DESCRIPTOR with a new LSP_ID in the
			outgoing PATH message.
			When this Path message with Express link flag is received at the
			other end of Express link, the other ring node replies with the Resv
			message. It does not forward this Path message to any of it's ring
			neighbors. Thus, the "Express" LSPs are effectively 1 hop LSPs
			formed over the "Express Links".
	4.6. Bandwidth management		4.6. Bandwidth management
	For RSVP-TE LSPs, bandwidths may be signaled in both directions.		For RSVP-TE LSPs, bandwidths may be signaled in both directions.
	However, these are not provisioned either; rather, one does "reverse		However, these are not provisioned either; rather, one does "reverse
	call admission control". When a service needs to use an LSP, the		call admission control". When a service needs to use an LSP, the
	ring node where the traffic enters the ring attempts to increase the		ring node where the traffic enters the ring attempts to increase the
	bandwidth on the LSP to the egress. If successful, the service is		bandwidth on the LSP to the egress. If successful, the service is
	admitted to the ring.		admitted to the ring.
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 30 ¶
	7. IANA Considerations		7. IANA Considerations
	Requests to IANA will be made in a future version of this document.		Requests to IANA will be made in a future version of this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-mpls-rmr]		[I-D.ietf-mpls-rmr]
	Kompella, K. and L. Contreras, "Resilient MPLS Rings",		Kompella, K. and L. Contreras, "Resilient MPLS Rings",
	draft-ietf-mpls-rmr-07 (work in progress), March 2018.		draft-ietf-mpls-rmr-11 (work in progress), June 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
End of changes. 10 change blocks.
	14 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/