draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-00.txt		draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01.txt
	Network Working Group A. Takacs		Network Working Group A. Takacs
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track L. Berger		Obsoletes: 5467 (if approved) L. Berger
	Expires: June 4, 2011 LabN Consulting, L.L.C.		Intended status: Standards Track LabN Consulting, L.L.C.
	D. Caviglia		Expires: August 1, 2011 D. Caviglia
	Ericsson		Ericsson
	D. Fedyk		D. Fedyk
	Alcatel-Lucent		Alcatel-Lucent
	J. Meuric		J. Meuric
	France Telecom Orange		France Telecom Orange
	December 1, 2010		January 28, 2011
	GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)		GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
	draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-00.txt		draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01.txt
	Abstract		Abstract
	This document defines a method for the support of GMPLS asymmetric		This document defines a method for the support of GMPLS asymmetric
	bandwidth bidirectional Label Switched Paths (LSPs). The presented		bandwidth bidirectional Label Switched Paths (LSPs). The presented
	approach is applicable to any switching technology and builds on the		approach is applicable to any switching technology and builds on the
	original Resource Reservation Protocol (RSVP) model for the transport		original Resource Reservation Protocol (RSVP) model for the transport
	of traffic-related parameters.		of traffic-related parameters. This document moves the experiment
			documented in RFC 5467 to the standards track and obsoletes RFC 5467.
	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/.
	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 June 4, 2011.		This Internet-Draft will expire on August 1, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Approach Overview . . . . . . . . . . . . . . . . . . . . 4		1.2. Approach Overview . . . . . . . . . . . . . . . . . . . . 4
	1.3. Conventions Used in This Document . . . . . . . . . . . . 4		1.3. Conventions Used in This Document . . . . . . . . . . . . 5
	2. Generalized Asymmetric Bandwidth Bidirectional LSPs . . . . . 5		2. Generalized Asymmetric Bandwidth Bidirectional LSPs . . . . . 6
	2.1. UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . . 5		2.1. UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . . 6
	2.1.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 5		2.1.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. UPSTREAM_TSPEC Object . . . . . . . . . . . . . . . . . . 5		2.2. UPSTREAM_TSPEC Object . . . . . . . . . . . . . . . . . . 6
	2.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 6		2.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . . 6		2.3. UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . . 7
	2.3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 6		2.3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . 7
	3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5.1. UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . . 10		5.1. UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . . 11
	5.2. UPSTREAM_TSPEC Object . . . . . . . . . . . . . . . . . . 10		5.2. UPSTREAM_TSPEC Object . . . . . . . . . . . . . . . . . . 11
	5.3. UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . . 10		5.3. UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	GMPLS [RFC3473] introduced explicit support for bidirectional Label		GMPLS [RFC3473] introduced explicit support for bidirectional Label
	Switched Paths (LSPs). The defined support matched the switching		Switched Paths (LSPs). The defined support matched the switching
	technologies covered by GMPLS, notably Time Division Multiplexing		technologies covered by GMPLS, notably Time Division Multiplexing
	(TDM) and lambdas; specifically, it only supported bidirectional LSPs		(TDM) and lambdas; specifically, it only supported bidirectional LSPs
	with symmetric bandwidth allocation. Symmetric bandwidth		with symmetric bandwidth allocation. Symmetric bandwidth
	requirements are conveyed using the semantics objects defined in		requirements are conveyed using the semantics objects defined in
	[RFC2205] and [RFC2210].		[RFC2205] and [RFC2210].
	GMPLS asymmetric bandwidth bidirectional LSPs are bidirectional LSPs		GMPLS asymmetric bandwidth bidirectional LSPs are bidirectional LSPs
	that have different bandwidth reservations in each direction.		that have different bandwidth reservations in each direction.
	Support for bidirectional LSPs with asymmetric bandwidth, was		Support for bidirectional LSPs with asymmetric bandwidth, was
	previously discussed in the context of Ethernet, notably [GMPLS-		previously discussed in the context of Ethernet, notably [RFC6060]
	PBBTE] and [RFC6003]. In that context, asymmetric bandwidth support		and [RFC6003]. In that context, asymmetric bandwidth support was
	was considered to be a capability that was unlikely to be deployed,		considered to be a capability that was unlikely to be deployed, and
	and hence [RFC5467] was published as Experimental. The MPLS		hence [RFC5467] was published as Experimental. The MPLS Transport
	Transport Profile, MPLS-TP, requires that asymmetric bandwidth		Profile, MPLS-TP, requires that asymmetric bandwidth bidirectional
	bidirectional LSPs be supported, see [RFC5654], and therefore this		LSPs be supported, see [RFC5654], and therefore this document is
	document is being published on the Standards Track. This document		being published on the Standards Track. This document has no
	has no technical changes from the approach defined in [RFC5467].		technical changes from the approach defined in [RFC5467]. This
	This document removes an alternate approach that is not part of the		document moves the experiment documented in [RFC5467] to the
	Standards Track solution.		standards track and obsoletes [RFC5467]. This document also removes
			the Ethernet technology specific alternative approach discussed in
			the appendix of [RFC5467] and maintains only one approach that is
			suitable for use with any technology.
	1.1. Background		1.1. Background
	Bandwidth parameters are transported within RSVP ([RFC2210],		Bandwidth parameters are transported within RSVP ([RFC2210],
	[RFC3209], and [RFC3473]) via several objects that are opaque to		[RFC3209], and [RFC3473]) via several objects that are opaque to
	RSVP. While opaque to RSVP, these objects support a particular model		RSVP. While opaque to RSVP, these objects support a particular model
	for the communication of bandwidth information between an RSVP		for the communication of bandwidth information between an RSVP
	session sender (ingress) and receiver (egress). The original model		session sender (ingress) and receiver (egress). The original model
	of communication, defined in [RFC2205] and maintained in [RFC3209],		of communication, defined in [RFC2205] and maintained in [RFC3209],
	used the SENDER_TSPEC and ADSPEC objects in Path messages and the		used the SENDER_TSPEC and ADSPEC objects in Path messages and the
	FLOWSPEC object in Resv messages. The SENDER_TSPEC object was used		FLOWSPEC object in Resv messages. The SENDER_TSPEC object was used
	to indicate a sender's data generation capabilities. The FLOWSPEC		to indicate a sender's data generation capabilities. The FLOWSPEC
	object was issued by the receiver and indicated the resources that		object was issued by the receiver and indicated the resources that
	should be allocated to the associated data traffic. The ADSPEC		should be allocated to the associated data traffic. The ADSPEC
	object was used to inform the receiver and intermediate hops of the		object was used to inform the receiver and intermediate hops of the
	actual resources allocated for the associated data traffic.		actual resources available for the associated data traffic.
	With the introduction of bidirectional LSPs in [RFC3473], the model		With the introduction of bidirectional LSPs in [RFC3473], the model
	of communication of bandwidth parameters was implicitly changed. In		of communication of bandwidth parameters was implicitly changed. In
	the context of [RFC3473] bidirectional LSPs, the SENDER_TSPEC object		the context of [RFC3473] bidirectional LSPs, the SENDER_TSPEC object
	indicates the desired resources for both upstream and downstream		indicates the desired resources for both upstream and downstream
	directions. The FLOWSPEC object is simply confirmation of the		directions. The FLOWSPEC object is simply confirmation of the
	allocated resources. The definition of the ADSPEC object is either		allocated resources. The definition of the ADSPEC object is either
	unmodified and only has meaning for downstream traffic, or is		unmodified and only has meaning for downstream traffic, or is
	implicitly or explicitly ([RFC4606] and [MEF-TRAFFIC]) irrelevant.		implicitly or explicitly ([RFC4606] and [RFC6003]) irrelevant.
	1.2. Approach Overview		1.2. Approach Overview
	The approach for supporting asymmetric bandwidth bidirectional LSPs		The approach for supporting asymmetric bandwidth bidirectional LSPs
	defined in this document builds on the original RSVP model for the		defined in this document builds on the original RSVP model for the
	transport of traffic-related parameters and GMPLS's support for		transport of traffic-related parameters and GMPLS's support for
	bidirectional LSPs.		bidirectional LSPs.
	The defined approach is generic and can be applied to any switching		The defined approach is generic and can be applied to any switching
	technology supported by GMPLS. With this approach, the existing		technology supported by GMPLS. With this approach, the existing
	skipping to change at page 6, line 43		skipping to change at page 7, line 43
	the form 0bbbbbbb).		the form 0bbbbbbb).
	2.3.1. Procedures		2.3.1. Procedures
	The UPSTREAM_ADSPEC object MAY be included in any Resv message that		The UPSTREAM_ADSPEC object MAY be included in any Resv message that
	corresponds to a Path message containing an UPSTREAM_FLOWSPEC object.		corresponds to a Path message containing an UPSTREAM_FLOWSPEC object.
	The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the		The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the
	C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents		C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents
	of the UPSTREAM_ADSPEC object MUST be constructed using a format and		of the UPSTREAM_ADSPEC object MUST be constructed using a format and
	procedures consistent with those used to construct the ADSPEC object		procedures consistent with those used to construct the ADSPEC object
	that will be used for the LSP, e.g., [RFC2210] or [MEF-TRAFFIC]. The		that will be used for the LSP, e.g., [RFC2210] or [RFC6003]. The
	UPSTREAM_ADSPEC object is processed using the same procedures as the		UPSTREAM_ADSPEC object is processed using the same procedures as the
	ADSPEC object and, as such, MAY be updated or added at transit nodes.		ADSPEC object and, as such, MAY be updated or added at transit nodes.
	3. Packet Formats		3. Packet Formats
	This section presents the RSVP message-related formats as modified by		This section presents the RSVP message-related formats as modified by
	this section. This document modifies formats defined in [RFC2205],		this section. This document modifies formats defined in [RFC2205],
	[RFC3209], and [RFC3473]. See [RFC5511] for the syntax used by RSVP.		[RFC3209], and [RFC3473]. See [RFC5511] for the syntax used by RSVP.
	Unmodified formats are not listed. Three new objects are defined in		Unmodified formats are not listed. Three new objects are defined in
	this section:		this section:
	skipping to change at page 11, line 20		skipping to change at page 12, line 20
	parallel the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but		parallel the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but
	are used in the opposite direction. As such, any vulnerabilities		are used in the opposite direction. As such, any vulnerabilities
	that are due to the use of the old objects now apply to messages		that are due to the use of the old objects now apply to messages
	flowing in the reverse direction.		flowing in the reverse direction.
	From a message standpoint, this document does not introduce any new		From a message standpoint, this document does not introduce any new
	signaling messages or change the relationship between LSRs that are		signaling messages or change the relationship between LSRs that are
	adjacent in the control plane. As such, this document introduces no		adjacent in the control plane. As such, this document introduces no
	additional message- or neighbor-related security considerations.		additional message- or neighbor-related security considerations.
	See [RFC3473] for relevant security considerations, and [SEC-		See [RFC3473] for relevant security considerations, and [RFC5920] for
	FRAMEWORK] for a more general discussion on RSVP-TE security		a more general discussion on RSVP-TE security discussions.
	discussions.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
	and S. Jamin, "Resource ReSerVation Protocol (RSVP)		and S. Jamin, "Resource ReSerVation Protocol (RSVP)
	-- Version 1 Functional Specification", RFC 2205,		-- Version 1 Functional Specification", RFC 2205,
	September 1997.		September 1997.
	[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated		[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
	Services", RFC 2210, September 1997.		Services", RFC 2210, September 1997.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
	V., and G. Swallow, "RSVP-TE: Extensions to RSVP for		V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
	LSP Tunnels", RFC 3209, December 2001.		LSP Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation		Switching (GMPLS) Signaling Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) Extensions",		Protocol-Traffic Engineering (RSVP-TE) Extensions",
	RFC 3473, January 2003.		RFC 3473, January 2003.
	7.2. Informative References		7.2. Informative References
	[GMPLS-PBBTE] Fedyk, D., et al "GMPLS Control of Ethernet", Work in		[RFC6060] Fedyk, D., et al "Generalized Multiprotocol Label
	Progress, July 2008.		Switching (GMPLS) Control of Ethernet Provider
			Backbone Traffic Engineering (PBB-TE)",
			RFC 6060, 2011.
	[RFC6003] Papadimitriou, D., "MEF Ethernet Traffic Parameters,"		[RFC6003] Papadimitriou, D., "MEF Ethernet Traffic Parameters,"
	RFC 6003, October 2008.		RFC 6003, October 2008.
	[RFC5654] B. Niven-Jenkins, Ed., D. Brungard, Ed. and		[RFC5654] B. Niven-Jenkins, Ed., D. Brungard, Ed. and
	M. Betts, Ed., "Requirements of an MPLS Transport		M. Betts, Ed., "Requirements of an MPLS Transport
	Profile," RFC 5654, September 2009.		Profile," RFC 5654, September 2009.
	[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-		[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
	Protocol Label Switching (GMPLS) Extensions for		Protocol Label Switching (GMPLS) Extensions for
	Synchronous Optical Network (SONET) and Synchronous		Synchronous Optical Network (SONET) and Synchronous
	Digital Hierarchy (SDH) Control", RFC 4606, August		Digital Hierarchy (SDH) Control", RFC 4606, August
	2006.		2006.
	[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol		[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
	Label Switching (GMPLS) Signaling Extensions for		Label Switching (GMPLS) Signaling Extensions for
	G.709 Optical Transport Networks Control", RFC 4328,		G.709 Optical Transport Networks Control", RFC 4328,
	January 2006.		January 2006.
	[RFC5511] Farrel, A. "Reduced Backus-Naur Form (RBNF) A Syntax		[RFC5511] Farrel, A. "Reduced Backus-Naur Form (RBNF) A Syntax
	Used in Various Protocol Specifications", RFC 5511,		Used in Various Protocol Specifications", RFC 5511,
	April 2009.		April 2009.
	[RFC5920] Fang, L., Ed., "Security Framework for MPLS and		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and
	GMPLS Networks", RFC 5920, July 2010.		GMPLS Networks", RFC 5920, July 2010.
	[RFC5467] L. Berger, A. Takacs, D. Caviglia, D. Fedyk and		[RFC5467] L. Berger, A. Takacs, D. Caviglia, D. Fedyk and
	J. Meuric, "GMPLS Asymmetric Bandwidth		J. Meuric, "GMPLS Asymmetric Bandwidth
	Bidirectional Label Switched Paths (LSPs),"		Bidirectional Label Switched Paths (LSPs),"
	RFC 5467, March 2009.		RFC 5467, March 2009.
	Authors' Addresses		Authors' Addresses
	Attila Takacs		Attila Takacs
	Ericsson		Ericsson
	Laborc u. 1.		Laborc u. 1.
	Budapest, 1037		Budapest, 1037
	Hungary		Hungary
	Email: attila.takacs@ericsson.com		Email: attila.takacs@ericsson.com
End of changes. 25 change blocks.
	83 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/