draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt		draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt
	Internet Draft Lou Berger (LabN)		Internet Draft Lou Berger (LabN)
	Category: Experimental Attila Takacs (Ericsson)		Category: Experimental Attila Takacs (Ericsson)
	Expiration Date: September 12, 2008 Diego Caviglia (Ericsson)		Expiration Date: October 29, 2008 Diego Caviglia (Ericsson)
	Don Fedyk (Nortel)		Don Fedyk (Nortel)
	Julien Meuric (France Telecom)		Julien Meuric (France Telecom)
	March 12, 2008		April 29, 2008
	GMPLS Asymmetric Bandwidth Bidirectional LSPs		GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
	draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt		draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on September 12, 2008.		This Internet-Draft will expire on October 29, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	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 LSPs. The presented approach is applicable		Bandwidth Bidirectional Label Switched Paths (LSPs). The presented
	to any switching technology and builds on the original RSVP model for		approach is applicable to any switching technology and builds on the
	the transport of traffic related parameters.		original RSVP model for the transport of traffic related parameters.
			The procedures described in this document are experimental.
	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 ....... 5
	2.1 UPSTREAM_FLOWSPEC Object .................................. 5		2.1 UPSTREAM_FLOWSPEC Object .................................. 5
	2.1.1 Procedures ................................................ 5		2.1.1 Procedures ................................................ 5
	2.2 UPSTREAM_TSPEC Object ..................................... 6		2.2 UPSTREAM_TSPEC Object ..................................... 6
	2.2.1 Procedures ................................................ 6		2.2.1 Procedures ................................................ 6
	2.3 UPSTREAM_ADSPEC Object .................................... 6		2.3 UPSTREAM_ADSPEC Object .................................... 6
	2.3.1 Procedures ................................................ 6		2.3.1 Procedures ................................................ 6
	3 Packet Formats ............................................ 7		3 Packet Formats ............................................ 7
	4 Compatibility ............................................. 8		4 Compatibility ............................................. 8
	5 IANA Considerations ....................................... 8		5 IANA Considerations ....................................... 8
	5.1 UPSTREAM_FLOWSPEC Object .................................. 8		5.1 UPSTREAM_FLOWSPEC Object .................................. 8
	5.2 UPSTREAM_TSPEC Object ..................................... 8		5.2 UPSTREAM_TSPEC Object ..................................... 9
	5.3 UPSTREAM_ADSPEC Object .................................... 9		5.3 UPSTREAM_ADSPEC Object .................................... 9
	6 Security Considerations ................................... 9		6 Security Considerations ................................... 9
	7 References ................................................ 9		7 References ................................................ 9
	7.1 Normative References ...................................... 9		7.1 Normative References ...................................... 9
	7.2 Informative References .................................... 10		7.2 Informative References .................................... 10
	8 Author's Addresses ........................................ 10		8 Authors' Addresses ........................................ 10
	A. Appendix A: Alternate Approach Using ADSPEC Object ........ 11		A. Appendix A: Alternate Approach Using ADSPEC Object ........ 11
	A.1. Applicability ............................................. 11		A.1. Applicability ............................................. 11
	A.2. Overview .................................................. 12		A.2. Overview .................................................. 12
	A.3. Procedures ................................................ 13		A.3. Procedures ................................................ 13
	A.4. Compatibility ............................................. 13		A.4. Compatibility ............................................. 13
	9 Full Copyright Statement .................................. 13		Full Copyright Statement .................................. 14
	10 Intellectual Property ..................................... 14		Intellectual Property ..................................... 14
	1. Introduction		1. Introduction
	GMPLS, see [RFC3473], introduced explicit support for bidirectional		GMPLS, see [RFC3473], introduced explicit support for bidirectional
	LSPs. The defined support matched the switching technologies covered		Label Switched Paths (LSPs). The defined support matched the
	by GMPLS, notably TDM and lambdas, and specifically only supported		switching technologies covered by GMPLS, notably Time Division
			Multiplexing (TDM) and lambdas, and specifically only supported
	bidirectional LSPs with symmetric bandwidth allocation. Symmetric		bidirectional LSPs with symmetric bandwidth allocation. Symmetric
	bandwidth requirements are conveyed using the semantics objects		bandwidth requirements are conveyed using the semantics objects
	defined in [RFC2205] and [RFC2210].		defined in [RFC2205] and [RFC2210].
	Recent work, see [GMPLS-PBBTE] and [MEF-TRAFFIC], has looked at		Recent work, see [GMPLS-PBBTE] and [MEF-TRAFFIC], has looked at
	extending GMPLS to control Ethernet switching. In this context there		extending GMPLS to control Ethernet switching. In this context there
	has been discussion on the support of bidirectional LSPs with		has been discussion of the support of bidirectional LSPs with
	asymmetric bandwidth. This discussion motivated the extensions		asymmetric bandwidth. (That is, bidirectional LSPs that have
	defined in this document, which may be used with any switching		different bandwidth reservations in each direction.) This discussion
	technology to signal asymmetric bandwidth bidirectional LSPs.		motivated the extensions defined in this document, which may be used
			with any switching technology to signal asymmetric bandwidth
			bidirectional LSPs. The procedures described in this document are
			experimental.
	1.1. Background		1.1. Background
	Bandwidth parameters are transported within RSVP (see [RFC2210],		Bandwidth parameters are transported within RSVP (see [RFC2210],
	[RFC3209] and [RFC3473]) via several objects that are opaque to RSVP.		[RFC3209] and [RFC3473]) via several objects that are opaque to RSVP.
	While opaque to RSVP, these objects support a particular model for		While opaque to RSVP, these objects support a particular model for
	the communication of bandwidth information between an RSVP session		the communication of bandwidth information between an RSVP session
	sender (ingress) and receiver (egress). The original model of		sender (ingress) and receiver (egress). The original model of
	communication defined in [RFC2205] and maintained in [RFC3209] used		communication defined in [RFC2205] and maintained in [RFC3209] used
	the SENDER_TSPEC and ADSPEC objects in Path messages and the FLOWSPEC		the SENDER_TSPEC and ADSPEC objects in Path messages and the FLOWSPEC
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	unmodified, and only has meaning for downstream traffic, or is		unmodified, and only has meaning for downstream traffic, or is
	implicitly or explicitly (see [RFC4606] and [MEF-TRAFFIC])		implicitly or explicitly (see [RFC4606] and [MEF-TRAFFIC])
	irrelevant.		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' support for		transport of traffic related parameters and GMPLS' support for
	bidirectional LSPs. An alternative approach was considered and		bidirectional LSPs. An alternative approach was considered and
	rejected. For reference purposes only, the rejected approach is		rejected in favor of the more generic approach presented below. For
	summarized in Appendix A.		reference purposes only, the rejected approach is summarized in
			Appendix A.
	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
	SENDER_TSPEC, ADSPEC and FLOWSPEC objects are complemented with the		SENDER_TSPEC, ADSPEC and FLOWSPEC objects are complemented with the
	addition of new UPSTREAM_TSPEC, UPSTREAM_ADSPEC and UPSTREAM_FLOWSPEC		addition of new UPSTREAM_TSPEC, UPSTREAM_ADSPEC and UPSTREAM_FLOWSPEC
	objects. The existing objects are used in the original fashion		objects. The existing objects are used in the original fashion
	defined in [RFC2205] and [RFC2210], and refer only to traffic		defined in [RFC2205] and [RFC2210], and refer only to traffic
	associated with the LSP flowing in the downstream direction. The new		associated with the LSP flowing in the downstream direction. The new
	objects are used in exactly the same fashion as the old objects, but		objects are used in exactly the same fashion as the old objects, but
	refer to the upstream traffic flow. Figure 1 shows the bandwidth		refer to the upstream traffic flow. Figure 1 shows the bandwidth
	skipping to change at page 5, line 13		skipping to change at page 5, line 19
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Generalized Asymmetric Bandwidth Bidirectional LSPs		2. Generalized Asymmetric Bandwidth Bidirectional LSPs
	The setup of an asymmetric bandwidth bidirectional LSP is signaled		The setup of an asymmetric bandwidth bidirectional LSP is signaled
	using the bidirectional procedures defined in [RFC3473] together with		using the bidirectional procedures defined in [RFC3473] together with
	the inclusion of the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC and		the inclusion of the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC and
	UPSTREAM_ADSPEC objects.		UPSTREAM_ADSPEC objects.
	The new upstream objects carry the same information and are used in		The new upstream objects carry the same information and are used in
	the same fashion as the existing downstream objects; they only differ		the same fashion as the existing downstream objects; they differ in
	in that they relate to traffic flowing in the upstream direction		that they relate to traffic flowing in the upstream direction while
	while the existing objects relate to traffic flowing in the		the existing objects relate to traffic flowing in the downstream
	downstream direction.		direction. The new objects also differ in that they are used on
			messages in the opposite directions.
	2.1. UPSTREAM_FLOWSPEC Object		2.1. UPSTREAM_FLOWSPEC Object
	The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC		The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC
	object. This includes the definition of class types and their		object. This includes the definition of class types and their
	formats. The class number of the UPSTREAM_FLOWSPEC object object is		formats. The class number of the UPSTREAM_FLOWSPEC object object is
	TBA by IANA (of the form 0bbbbbbb).		TBA by IANA (of the form 0bbbbbbb).
	2.1.1. Procedures		2.1.1. Procedures
	skipping to change at page 6, line 14		skipping to change at page 6, line 14
	2.2. UPSTREAM_TSPEC Object		2.2. UPSTREAM_TSPEC Object
	The format of an UPSTREAM_TSPEC object is the same as a SENDER_TSPEC		The format of an UPSTREAM_TSPEC object is the same as a SENDER_TSPEC
	object. This includes the definition of class types and their		object. This includes the definition of class types and their
	formats. The class number of the UPSTREAM_TSPEC Object object is TBA		formats. The class number of the UPSTREAM_TSPEC Object object is TBA
	by IANA (of the form 0bbbbbbb).		by IANA (of the form 0bbbbbbb).
	2.2.1. Procedures		2.2.1. Procedures
	The UPSTREAM_TSPEC object MUST be included in any Resv message that		The UPSTREAM_TSPEC object describes the traffic flow that originates
	corresponds to a Path message containing an UPSTREAM_FLOWSPEC object.		at the egress. The UPSTREAM_TSPEC object MUST be included in any
	The C-Type of the UPSTREAM_TSPEC object MUST match the C-Type of the		Resv message that corresponds to a Path message containing an
	corresponding UPSTREAM_FLOWSPEC object. The contents of the		UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object
	UPSTREAM_TSPEC Object MUST be constructed using a consistent format		MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object.
	and procedures used to construct the FLOWSPEC object that will be		The contents of the UPSTREAM_TSPEC Object MUST be constructed using a
	used for the LSP, e.g., [RFC2210] or [RFC4328]. The contents of the		consistent format and procedures used to construct the FLOWSPEC
	UPSTREAM_TSPEC Object MAY differ from contents of the		object that will be used for the LSP, e.g., [RFC2210] or [RFC4328].
	UPSTREAM_FLOWSPEC object based on application data transmission		The contents of the UPSTREAM_TSPEC Object MAY differ from contents of
			the UPSTREAM_FLOWSPEC object based on application data transmission
	requirements.		requirements.
			When an UPSTREAM_TSPEC object is received by an ingress, the ingress
			MAY determine that the original reservation is insufficient to
			satisfy the traffic flow. In this case, the ingress MAY issue a Path
			message with an updated UPSTREAM_FLOWSPEC object to modify the
			resources requested for the upstream traffic flow. This modification
			might require the LSP to be re-routed, and in extreme cases might
			result in the LSP being torn down when sufficient resources are not
			available.
	2.3. UPSTREAM_ADSPEC Object		2.3. UPSTREAM_ADSPEC Object
	The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC		The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC
	object. This includes the definition of class types and their		object. This includes the definition of class types and their
	formats. The class number of the UPSTREAM_ADSPEC object is TBA by		formats. The class number of the UPSTREAM_ADSPEC object is TBA by
	IANA (of the form 0bbbbbbb).		IANA (of 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
	skipping to change at page 7, line 13		skipping to change at page 7, line 16
	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. Unmodified formats are not listed. Three new objects		this section. Unmodified formats are not listed. Three new objects
	are defined in this section:		are defined in this section:
	Object name Applicable RSVP messages		Object name Applicable RSVP messages
	--------------- ------------------------		--------------- ------------------------
	UPSTREAM_FLOWSPEC Path and PathErr (via sender descriptor)		UPSTREAM_FLOWSPEC Path, PathTear, PathErr and Notify
	UPSTREAM_TSPEC Resv and Notify (via flow descriptor list)		(via sender descriptor)
	UPSTREAM_ADSPEC Resv and Notify (via flow descriptor list)		UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr and
			Notify (via flow descriptor list)
			UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr and
			Notify (via flow descriptor list)
	The format of the sender description for bidirectional asymmetric		The format of the sender description for bidirectional asymmetric
	LSPs is:		LSPs is:
	<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>		<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
	[ <ADSPEC> ]		[ <ADSPEC> ]
	[ <RECORD_ROUTE> ]		[ <RECORD_ROUTE> ]
	[ <SUGGESTED_LABEL> ]		[ <SUGGESTED_LABEL> ]
	[ <RECOVERY_LABEL> ]		[ <RECOVERY_LABEL> ]
	<UPSTREAM_LABEL>		<UPSTREAM_LABEL>
	skipping to change at page 8, line 12		skipping to change at page 8, line 17
	<SE filter spec list> is unmodified by this document.		<SE filter spec list> is unmodified by this document.
	4. Compatibility		4. Compatibility
	This extension reuses and extends semantics and procedures defined in		This extension reuses and extends semantics and procedures defined in
	[RFC2205], [RFC3209] and [RFC3473] to support bidirectional LSPs with		[RFC2205], [RFC3209] and [RFC3473] to support bidirectional LSPs with
	asymmetric bandwidth. To indicate the use of asymmetric bandwidth		asymmetric bandwidth. To indicate the use of asymmetric bandwidth
	three new objects are defined. Each of these objects is defined with		three new objects are defined. Each of these objects is defined with
	class numbers in the form 0bbbbbbb. Per [RFC2205], nodes not		class numbers in the form 0bbbbbbb. Per [RFC2205], nodes not
	supporting this extension should not recognize the new class numbers		supporting this extension will not recognize the new class numbers
	and respond with an "Unknown Object Class" error. The error message		and should respond with an "Unknown Object Class" error. The error
	will propagate to the ingress which can then take action to avoid the		message will propagate to the ingress which can then take action to
	path with the incompatible node, or may simply terminate the session.		avoid the path with the incompatible node, or may simply terminate
			the session.
	5. IANA Considerations		5. IANA Considerations
	IANA is requested to administer assignment of new values for		IANA is requested to administer assignment of new values for
	namespaces defined in this section and reviewed in this subsection.		namespaces defined in this section and reviewed in this subsection.
	Upon approval of this document, the IANA will make the assignments		Upon approval of this document, the IANA will make the assignments
	described below in the "Class Names, Class Numbers, and Class Types"		described below in the "Class Names, Class Numbers, and Class Types"
	section of the "RSVP PARAMETERS" registry located at		section of the "RSVP PARAMETERS" registry located at
	http://www.iana.org/assignments/rsvp-parameters		http://www.iana.org/assignments/rsvp-parameters
	skipping to change at page 9, line 17		skipping to change at page 9, line 26
	A new class named UPSTREAM_ADSPEC will be created in the 0bbbbbbb		A new class named UPSTREAM_ADSPEC will be created in the 0bbbbbbb
	range (TBD suggested) with the following definition:		range (TBD suggested) with the following definition:
	Class Types or C-types:		Class Types or C-types:
	Same values as ADSPEC object (C-Num 13)		Same values as ADSPEC object (C-Num 13)
	6. Security Considerations		6. Security Considerations
	This document introduces new message objects for use in GMPLS		This document introduces new message objects for use in GMPLS
	signaling [RFC3473]. It does not introduce any new signaling		signaling [RFC3473]. Specifically the UPSTREAM_TSPEC,
	messages, nor change the relationship between LSRs that are adjacent		UPSTREAM_ADSPEC and UPSTREAM_FLOWSPEC objects. These object parallel
	in the control plane. As such, this document introduces no additional		the exiting SENDER_TSPEC, ADSPEC and FLOWSPEC objects but are used in
	security considerations. See [RFC3473] for relevant security		the opposite direction. As such, any vulnerabilities that are due to
	considerations.		the use of the old objects now apply to messages flowing in the
			reverse direction.
			From a message standpoint, this document does not introduce any new
			signaling messages, nor change the relationship between LSRs that are
			adjacent in the control plane. As such, this document introduces no
			additional message or neighbor related security considerations.
			See [RFC3473] for relevant security considerations, and [SEC-
			FRAMEWORK] for a more general discussion on RSVP-TE security
			discussions.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic
	Parameters,"
	draft-ietf-ccamp-ethernet-traffic-parameters-03.txt,
	Work in progress, November 2007.
	[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol		[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
	-- 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," RFC 2119.		Requirement Levels," RFC 2119.
	skipping to change at page 10, line 8		skipping to change at page 10, line 22
	LSP Tunnels", RFC 3209, December 2001.		LSP Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Editor, "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" ,		[GMPLS-PBBTE] Fedyk, D., et al "GMPLS control of Ethernet" ,
	draft-fedyk-gmpls-ethernet-pbb-te-02.txt, Work in		draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt, Work in
	progress, November 2007.		progress, April 2008.
			[MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic
			Parameters,"
			draft-ietf-ccamp-ethernet-traffic-parameters-04.txt,
			Work in progress, April 2008.
	[RFC4606] Mannie, E., Papadimitriou, D., "Generalized		[RFC4606] Mannie, E., Papadimitriou, D., "Generalized
	Multi-Protocol Label Switching (GMPLS) Extensions for		Multi-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 2006.		Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
	[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol		[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
	Label Switching (GMPLS) Signaling Extensions for G.709		Label Switching (GMPLS) Signaling Extensions for G.709
	Optical Transport Networks Control", RFC 4328, January		Optical Transport Networks Control", RFC 4328, January
	2006.		2006.
	8. Author's Addresses		[SEC-FRAMEWORK] Fang, L., Ed., "Security Framework for MPLS and
			GMPLS Networks",
			draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt,
			Work in progress, February 2008.
			8. Authors' Addresses
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: lberger@labn.net		Email: lberger@labn.net
	Attila Takacs		Attila Takacs
	Ericsson		Ericsson
	1. Laborc u.		1. Laborc u.
	1037 Budapest, Hungary		1037 Budapest, Hungary
	Phone: +36-1-4377044		Phone: +36-1-4377044
	Email: attila.takacs@ericsson.com		Email: attila.takacs@ericsson.com
	Diego Caviglia		Diego Caviglia
	Ericsson		Ericsson
	Via A. Negrone 1/A		Via A. Negrone 1/A
	skipping to change at page 11, line 14		skipping to change at page 11, line 35
	Julien Meuric		Julien Meuric
	France Telecom		France Telecom
	Research & Development		Research & Development
	2, avenue Pierre Marzin		2, avenue Pierre Marzin
	22307 Lannion Cedex - France		22307 Lannion Cedex - France
	Phone: +33 2 96 05 28 28		Phone: +33 2 96 05 28 28
	Email: julien.meuric@orange-ftgroup.com		Email: julien.meuric@orange-ftgroup.com
	A. Appendix A: Alternate Approach Using ADSPEC Object		A. Appendix A: Alternate Approach Using ADSPEC Object
	This section is included for historic purposes and SHOULD NOT be		This section is included for historic purposes and its implementation
	implemented.		is NOT RECOMMENDED.
	A.1. Applicability		A.1. Applicability
	This section presents an alternate method for the support of		This section presents an alternate method for the support of
	asymmetric bandwidth bidirectional LSP establishment with a single		asymmetric bandwidth bidirectional LSP establishment with a single
	RSVP-TE signaling session. This approach differs in applicability and		RSVP-TE signaling session. This approach differs in applicability and
	generality from the approach presented in the main body of this		generality from the approach presented in the main body of this
	document.		document. In particular this approach is technology specific; it
			uses the ADSPEC object to carry traffic parameters for upstream data
			and requires MEF Ethernet Traffic Parameter while the approach
			presented above is suitable for use with any technology.
	The generalized asymmetric bandwidth bidirectional LSP presented in		The generalized asymmetric bandwidth bidirectional LSP presented in
	the main body of this document has the benefit of being applicable to		the main body of this document has the benefit of being applicable to
	any switching technology, but requires support for three new types of		any switching technology, but requires support for three new types of
	object classes, i.e., the UPSTREAM_TSPEC, UPSTREAM_ADSPEC and		object classes, i.e., the UPSTREAM_TSPEC, UPSTREAM_ADSPEC and
	UPSTREAM_FLOWSPEC objects.		UPSTREAM_FLOWSPEC objects.
	The solution presented in this section is based on the Ethernet		The solution presented in this section is based on the Ethernet
	specific ADSPEC Object, and is referred to as the "ADSPEC Object"		specific ADSPEC Object, and is referred to as the "ADSPEC Object"
	approach. This approach limits applicability to cases where the		approach. This approach limits applicability to cases where the
	skipping to change at page 13, line 35		skipping to change at page 14, line 5
	modified by transit nodes.		modified by transit nodes.
	A.4. Compatibility		A.4. Compatibility
	The approach presented in this section reuses semantics and		The approach presented in this section reuses semantics and
	procedures defined in [RFC3473]. To indicate the use of asymmetric		procedures defined in [RFC3473]. To indicate the use of asymmetric
	bandwidth a new ADSPEC object c-type would be defined. Per		bandwidth a new ADSPEC object c-type would be defined. Per
	[RFC2205], nodes not supporting the approach should not recognize		[RFC2205], nodes not supporting the approach should not recognize
	this new C-type and respond with an "Unknown object C-Type" error.		this new C-type and respond with an "Unknown object C-Type" error.
	9. Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	10. Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology		to pertain to the implementation or use of the technology
	described in this document or the extent to which any license		described in this document or the extent to which any license
	under such rights might or might not be available; nor does it		under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any		represent that it has made any independent effort to identify any
	such rights. Information on the procedures with respect to rights		such rights. Information on the procedures with respect to rights
	in RFC documents can be found in BCP 78 and BCP 79.		in RFC documents can be found in BCP 78 and BCP 79.
	skipping to change at line 580		skipping to change at line 618
	any copyrights, patents or patent applications, or other		any copyrights, patents or patent applications, or other
	proprietary rights that may cover technology that may be required		proprietary rights that may cover technology that may be required
	to implement this standard. Please address the information to the		to implement this standard. Please address the information to the
	IETF at ietf-ipr@ietf.org.		IETF at ietf-ipr@ietf.org.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is provided by the IETF		Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).		Administrative Support Activity (IASA).
	Generated on: Wed Mar 12 11:01:44 EDT 2008		Generated on: Tue Apr 29 11:46:28 EDT 2008
End of changes. 28 change blocks.
	60 lines changed or deleted		98 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/