draft-ietf-ccamp-assoc-ext-03.txt		draft-ietf-ccamp-assoc-ext-04.txt
	Internet Draft Lou Berger (LabN)		Internet Draft Lou Berger (LabN)
	Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco)		Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco)
	Category: Standards Track Ashok Narayanan (Cisco)		Category: Standards Track Ashok Narayanan (Cisco)
	Expiration Date: September 9, 2012		Expiration Date: February 14, 2013
	March 9, 2012		August 14, 2012
	RSVP Association Object Extensions		RSVP Association Object Extensions
	draft-ietf-ccamp-assoc-ext-03.txt		draft-ietf-ccamp-assoc-ext-04.txt
	Abstract		Abstract
	The RSVP ASSOCIATION object was defined in the context of GMPLS		The RSVP ASSOCIATION object was defined in the context of GMPLS
	(Generalized Multi-Protocol Label Switching) controlled label		(Generalized Multi-Protocol Label Switching) controlled label
	switched paths (LSPs). In this context, the object is used to		switched paths (LSPs). In this context, the object is used to
	associate recovery LSPs with the LSP they are protecting. This		associate recovery LSPs with the LSP they are protecting. This
	object also has broader applicability as a mechanism to associate		object also has broader applicability as a mechanism to associate
	RSVP state, and this document defines how the ASSOCIATION object		RSVP state, and this document defines how the ASSOCIATION object
	can be more generally applied. This document also defines		can be more generally applied. This document also defines
	extended ASSOCIATION objects which, in particular, can be used in		Extended ASSOCIATION objects which, in particular, can be used in
	the context of Transport Profile of Multiprotocol Label Switching		the context of the Transport Profile of Multiprotocol Label
	(MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC		Switching (MPLS-TP). This document updates RFC 2205, RFC 3209,
	3473. It also modifies the definition of the Association ID field		and RFC 3473. It also modifies the definition of the Association
	defined in RFC 4872.		ID field defined in RFC 4872.
	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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 9, 2012		This Internet-Draft will expire on February 14, 2013
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	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 Conventions Used In This Document ...................... 4		1.1 Conventions Used In This Document ...................... 4
	2 Modified Association ID Field Definition ............... 4		2 Modified Association ID Field Definition ............... 4
	3 Non-GMPLS Recovery Usage ............................... 5		3 Non-GMPLS and Non-Recovery Usage ....................... 5
	3.1 Upstream Initiated Association ......................... 5		3.1 Upstream Initiated Association ......................... 5
	3.1.1 Path Message Format .................................... 5		3.1.1 Path Message Format .................................... 5
	3.1.2 Path Message Processing ................................ 6		3.1.2 Path Message Processing ................................ 6
	3.2 Downstream Initiated Association ....................... 7		3.2 Downstream Initiated Association ....................... 7
	3.2.1 Resv Message Format .................................... 7		3.2.1 Resv Message Format .................................... 7
	3.2.2 Resv Message Processing ................................ 8		3.2.2 Resv Message Processing ................................ 8
	3.3 Association Types ...................................... 9		3.3 Association Types ...................................... 9
	3.3.1 Resource Sharing Association Type ...................... 9		3.3.1 Resource Sharing Association Type ...................... 9
	4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10		4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10
	4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10		4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10
	skipping to change at page 3, line 12		skipping to change at page 3, line 12
	8.2 Informative References ................................. 15		8.2 Informative References ................................. 15
	9 Authors' Addresses ..................................... 16		9 Authors' Addresses ..................................... 16
	1. Introduction		1. Introduction
	End-to-end and segment recovery are defined for GMPLS (Generalized		End-to-end and segment recovery are defined for GMPLS (Generalized
	Multi-Protocol Label Switching) controlled label switched paths		Multi-Protocol Label Switching) controlled label switched paths
	(LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use		(LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use
	the ASSOCIATION object to associate recovery LSPs with the LSP they		the ASSOCIATION object to associate recovery LSPs with the LSP they
	are protecting. Additional narrative on how such associations are to		are protecting. Additional narrative on how such associations are to
	be identified is also provided in [ASSOC-INFO].		be identified is also provided in [RFC6689].
	This document expands the possible usage of the ASSOCIATION object to		This document expands the possible usage of the ASSOCIATION object to
	non-GMPLS recovery contexts. This document reviews how association		non-GMPLS and non-recovery contexts. This document reviews how
	should be made in the case where the object is carried in a Path		association should be made in the case where the object is carried in
	message and defines usage with Resv messages. This section also		a Path message and defines usage with Resv messages. This section
	discusses usage of the ASSOCIATION object outside the context of		also discusses usage of the ASSOCIATION object outside the context of
	GMPLS LSPs.		GMPLS LSPs.
	Some examples of non-LSP association in order to enable resource		Some examples of non-LSP association in order to enable resource
	sharing are:		sharing are:
	o Voice Call-Waiting:		o Voice Call-Waiting:
	A bidirectional voice call between two endpoints A and B is		A bidirectional voice call between two endpoints A and B is
	signaled using two separate unidirectional RSVP reservations for		signaled using two separate unidirectional RSVP reservations for
	the flows A->B and B->A. If endpoint A wishes to put the A-B call		the flows A->B and B->A. If endpoint A wishes to put the A-B call
	on hold and join a separate A-C call, it is desirable that		on hold and join a separate A-C call, it is desirable that
	network resources on common links be shared between the A-B and		network resources on common links be shared between the A-B and
	A-C calls. The B->A and C->A subflows of the call can share		A-C calls. The B->A and C->A subflows of the call can share
	resources using existing RSVP sharing mechanisms, but only if		resources using existing RSVP sharing mechanisms, but only if
	they use the same destination IP addresses and ports. However,		they use the same destination IP addresses and ports. Since, by
	there is no way in RSVP today to share the resources between the		definition, the RSVP reservations for the subflows A->B and A->C
	A->B and A->C subflows of the call since by definition the RSVP		of the call must have different IP addresses in the SESSION
	reservations for these subflows must have different IP addresses		objects, this document defines a new mechanism to associate the
	in the SESSION objects.		subflows and allow them to share resources.
	o Voice Shared Line:		o Voice Shared Line:
	A single number that rings multiple endpoints (which may be		A voice shared line is a single number that rings multiple
	geographically diverse), such as phone lines on a manager's desk		endpoints (which may be geographically diverse), such as phone
	and their assistant. A VoIP system that models these calls as		lines to a manager's desk and to their assistant. A VoIP system
	multiple P2P unicast pre-ring reservations would result in		that models these calls as multiple P2P unicast pre-ring
	significantly over-counting bandwidth on shared links, since		reservations would result in significantly over-counting
	today unicast reservations to different endpoints cannot share		bandwidth on shared links, since RSVP unicast reservations to
	bandwidth.		different endpoints cannot share bandwidth. So a new mechanism
			is defined in this document allowing separate unicast
			reservations to be associated and share resources.
	o Symmetric NAT:		o Symmetric NAT:
	RSVP permits sharing of resources between multiple flows		RSVP permits sharing of resources between multiple flows
	addressed to the same destination D, even from different senders		addressed to the same destination D, even from different senders
	S1 and S2. However, if D is behind a NAT operating in symmetric		S1 and S2. However, if D is behind a NAT operating in symmetric
	mode [RFC5389], it is possible that the destination port of the		mode [RFC5389], it is possible that the destination port of the
	flows S1->D and S2->D may be different outside the NAT. In this		flows S1->D and S2->D may be different outside the NAT. In this
	case, these flows cannot share resources using RSVP today, since		case, these flows cannot share resources using RSVP, since the
	the SESSION objects for these two flows outside the NAT would		SESSION objects for these two flows outside the NAT have
	have different ports.		different ports. This document defines a new mechanisms to
			associate these flows and allow them to share resources.
	In order to support the more general usage of the ASSOCIATION object,		In order to support the more general usage of the ASSOCIATION object,
	this document modifies the definition of the Association ID field		this document modifies the definition of the Association ID field
	defined in RFC 4872. This modification has no impact on existing		defined in RFC 4872. This modification has no impact on existing
	implementations.		implementations.
	This document also defines the extended ASSOCIATION objects which can		This document also defines the Extended ASSOCIATION objects which can
	be used in the context of Transport Profile of Multiprotocol Label		be used in the context of the Transport Profile of Multiprotocol
	Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION		Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION
	objects is not limited to MPLS-TP.		objects is not limited to MPLS-TP.
	1.1. Conventions Used In This Document		1.1. Conventions Used In This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Modified Association ID Field Definition		2. Modified Association ID Field Definition
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	ASSOCIATION objects as:		ASSOCIATION objects as:
	A value assigned by the the node that originated the association.		A value assigned by the the node that originated the association.
	When combined with the other fields carried in the object, this		When combined with the other fields carried in the object, this
	value uniquely identifies an association.		value uniquely identifies an association.
	This change in definition does not impact [RFC4872] or [RFC4873]		This change in definition does not impact [RFC4872] or [RFC4873]
	defined procedures or mechanisms, nor does it impact existing		defined procedures or mechanisms, nor does it impact existing
	implementations of [RFC4872] or [RFC4873].		implementations of [RFC4872] or [RFC4873].
	3. Non-GMPLS Recovery Usage		3. Non-GMPLS and Non-Recovery Usage
	While the ASSOCIATION object, [RFC4872], is defined in the context of		While the ASSOCIATION object, [RFC4872], is defined in the context of
	GMPLS Recovery, the object can have wider application. [RFC4872]		GMPLS Recovery, the object can have wider application. [RFC4872]
	defines the object to be used to "associate LSPs with each other",		defines the object to be used to "associate LSPs with each other",
	and then defines an Association Type field to identify the type of		and then defines an Association Type field to identify the type of
	association being identified. It also defines that the Association		association being identified. It also specifies that the Association
	Type field is to be considered when determining association, i.e.,		Type field is to be considered when determining association, i.e.,
	there may be type-specific association rules. As defined by		there may be type-specific association rules. As defined by
	[RFC4872] and reviewed in [ASSOC-INFO], this is the case for Recovery		[RFC4872] and reviewed in [RFC6689], this is the case for Recovery
	type association objects. [ASSOC-INFO], notably the text related to		type association objects. [RFC6689], notably the text related to
	resource sharing types, can also be used as the foundation for a		resource sharing types, can also be used as the foundation for a
	generic method for associating LSPs when there is no type-specific		generic method for associating LSPs when there is no type-specific
	association defined.		association defined.
	The remainder of this section defines the general rules to be		The remainder of this section defines the general rules to be
	followed when processing ASSOCIATION objects. Object usage in both		followed when processing ASSOCIATION objects. Object usage in both
	Path and Resv messages is discussed. The usage applies equally to		Path and Resv messages is discussed. The usage applies equally to
	GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions		GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions
	[RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below,		[RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below,
	association is always done based on matching either Path state to		association is always done based on matching either Path state to
	Path state, or Resv state to Resv state, but not Path state to Resv		Path state, or Resv state to Resv state, but not Path state to Resv
	State. Note that there are times when no matching state is found,		State. This section applies to the ASSOCIATION objects defined in
	e.g., when processing an initial LSP or when the ASSOCIATION object		[RFC4872].
	contains otherwise useful information, and such cases do not alter
	the processing defined below. This section applies to the
	ASSOCIATION objects defined in [RFC4872].
	3.1. Upstream Initiated Association		3.1. Upstream Initiated Association
	Upstream initiated association is represented in ASSOCIATION objects		Upstream initiated association is represented in ASSOCIATION objects
	carried in Path messages and can be used to associate RSVP Path state		carried in Path messages and can be used to associate RSVP Path state
	across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS		across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS
	tunnel is represented by a RSVP SESSION object, and multiple LSPs may		tunnel is represented by a RSVP SESSION object, and multiple LSPs may
	be represented within a single tunnel.) Cross-session association		be represented within a single tunnel.) Cross-session association
	based on Path state is defined in [RFC4872]. This definition is		based on Path state is defined in [RFC4872]. This section extends
	extended by this section, which defined generic association rules and		that definition by specifying generic association rules and usage for
	usage for non-LSP uses. This section does not modify processing		non-LSP uses. This section does not modify processing required to
	required to support [RFC4872] and [RFC4873], and which is reviewed in		support [RFC4872] and [RFC4873], and which is reviewed in Section 3
	Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a		of [RFC6689]. The use of an ASSOCIATION object in a single session
	single session is not precluded.		is not precluded.
	3.1.1. Path Message Format		3.1.1. Path Message Format
	This section provides the Backus-Naur Form (BNF), see [RFC5511], for		This section provides the Backus-Naur Form (BNF), see [RFC5511], for
	Path messages containing ASSOCIATION objects. BNF is provided for		Path messages containing ASSOCIATION objects. BNF is provided for
	both MPLS and for non-LSP session usage. Unmodified RSVP message		both MPLS and for non-LSP session usage. Unmodified RSVP message
	formats and some optional objects are not listed.		formats and some optional objects are not listed.
	The format for MPLS and GMPLS sessions is unmodified from [RFC4872],		The format for MPLS and GMPLS sessions is unmodified from [RFC4872],
	and can be represented based on the BNF in [RFC3209] as:		and can be represented based on the BNF in [RFC3209] as:
	skipping to change at page 6, line 35		skipping to change at page 6, line 32
	[ <sender descriptor> ]		[ <sender descriptor> ]
	In general, relative ordering of ASSOCIATION objects with respect to		In general, relative ordering of ASSOCIATION objects with respect to
	each other as well as with respect to other objects is not		each other as well as with respect to other objects is not
	significant. Relative ordering of ASSOCIATION objects of the same		significant. Relative ordering of ASSOCIATION objects of the same
	type SHOULD be preserved by transit nodes.		type SHOULD be preserved by transit nodes.
	3.1.2. Path Message Processing		3.1.2. Path Message Processing
	This section is based on the processing rules described in [RFC4872]		This section is based on the processing rules described in [RFC4872]
	and [RFC4873], and which is reviewed in [ASSOC-INFO]. These		and [RFC4873], and which is reviewed in [RFC6689]. These procedures
	procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session		apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state.
	state.
	A node sending a Path message chooses when an ASSOCIATION object is		A node sending a Path message chooses when an ASSOCIATION object is
	to be included in the outgoing Path message. A node that wishes to		to be included in the outgoing Path message. To indicate association
	allow downstream nodes to associate Path state across RSVP sessions		between multiple sessions, an appropriate ASSOCIATION object MUST be
	MUST include an ASSOCIATION object in the outgoing Path messages		included in the outgoing Path messages corresponding to each of the
	corresponding to the RSVP sessions to be associated. In the absence		associated sessions. In the absence of Association Type-specific
	of Association Type-specific rules for identifying association, the		rules for identifying association, the included ASSOCIATION object
	included ASSOCIATION objects MUST be identical across all associated		MUST be identical. When there is an Association Type-specific
	sessions. When there is an Association Type-specific definition of		definition of association rules, the definition SHOULD allow for
	association rules, the definition SHOULD allow for association based		association based on identical ASSOCIATION objects. This document
	on identical ASSOCIATION objects. This document does not define any		does not define any Association Type-specific rules. (See Section 3
	Association Type-specific rules. (See Section 3 of [ASSOC-INFO] for		of [RFC6689] for a review of Association Type-specific rules derived
	a review of Association Type-specific rules derived from [RFC4872].)		from [RFC4872].)
	When creating an ASSOCIATION object, the originator MUST format the		When creating an ASSOCIATION object, the originator MUST format the
	object as defined in Section 16.1 of [RFC4872]. The originator MUST		object as defined in Section 16.1 of [RFC4872]. The originator MUST
	set the Association Type field based on the type of association being		set the Association Type field based on the type of association being
	identified. The Association ID field MUST be set to a value that		identified. The Association ID field MUST be set to a value that
	uniquely identifies the sessions to be associated within the context		uniquely identifies the sessions to be associated within the context
	of the Association Source field. The Association Source field MUST		of the Association Source field. The Association Source field MUST
	be set to a unique address assigned to the node originating the		be set to a unique address assigned to the node originating the
	association.		association.
	skipping to change at page 8, line 17		skipping to change at page 8, line 16
	<SESSION> <RSVP_HOP>		<SESSION> <RSVP_HOP>
	<TIME_VALUES>		<TIME_VALUES>
	[ <RESV_CONFIRM> ] [ <SCOPE> ]		[ <RESV_CONFIRM> ] [ <SCOPE> ]
	[ <ASSOCIATION> ... ]		[ <ASSOCIATION> ... ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	<STYLE> <flow descriptor list>		<STYLE> <flow descriptor list>
	Relative ordering of ASSOCIATION objects with respect to each other		Relative ordering of ASSOCIATION objects with respect to each other
	as well as with respect to other objects is not currently		as well as with respect to other objects is not currently
	significant. Relative ordering of ASSOCIATION objects of the same		significant. Relative ordering of ASSOCIATION objects of the same
	type MUST be preserved by transit nodes. Association type specific		type SHOULD be preserved by transit nodes.
	ordering requirements MAY be defined in the future.
	3.2.2. Resv Message Processing		3.2.2. Resv Message Processing
	This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP		This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
	session state.		session state.
	A node sending a Resv message chooses when an ASSOCIATION object is		A node sending a Resv message chooses when an ASSOCIATION object is
	to be included in the outgoing Resv message. A node that wishes to		to be included in the outgoing Resv message. A node that wishes to
	allow upstream nodes to associate Resv state across RSVP sessions		allow upstream nodes to associate Resv state across RSVP sessions
	MUST include an ASSOCIATION object in the outgoing Resv messages		MUST include an ASSOCIATION object in the outgoing Resv messages
	skipping to change at page 9, line 25		skipping to change at page 9, line 22
	Unless there are type-specific processing rules, upstream nodes MUST		Unless there are type-specific processing rules, upstream nodes MUST
	forward all ASSOCIATION objects received in a Resv message in any		forward all ASSOCIATION objects received in a Resv message in any
	corresponding outgoing Resv messages.		corresponding outgoing Resv messages.
	3.3. Association Types		3.3. Association Types
	Two association types are currently defined: recovery and resource		Two association types are currently defined: recovery and resource
	sharing. Recovery type association is only applicable within the		sharing. Recovery type association is only applicable within the
	context of recovery, [RFC4872] and [RFC4873]. Resource sharing is		context of recovery, [RFC4872] and [RFC4873]. Resource sharing is
	generally useful and its general use is defined in this section.		applicable to any context and its general use is defined in this
			section.
	3.3.1. Resource Sharing Association Type		3.3.1. Resource Sharing Association Type
	The resource sharing association type was defined in [RFC4873] and		The resource sharing association type was defined in [RFC4873] and
	was defined within the context of GMPLS and upstream initiated		was defined within the context of GMPLS and upstream initiated
	association. This section presents a definition of the resource		association. This section presents a definition of the resource
	sharing association that allows for its use with any RSVP session		sharing association that allows for its use with any RSVP session
	type and in both Path and Resv messages. This definition is		type and in both Path and Resv messages. This definition is
	consistent with the definition of the resource sharing association		consistent with the definition of the resource sharing association
	type in [RFC4873] and no changes are required by this section in		type in [RFC4873] and no changes are required by this section in
	skipping to change at page 9, line 51		skipping to change at page 9, line 49
	the Association Type field value of 2. ASSOCIATION objects with an		the Association Type field value of 2. ASSOCIATION objects with an
	Association Type with the value Resource Sharing MAY be carried in		Association Type with the value Resource Sharing MAY be carried in
	Path and Resv messages. Association for the Resource Sharing type		Path and Resv messages. Association for the Resource Sharing type
	MUST follow the procedures defined in Section 4.1.2 for upstream		MUST follow the procedures defined in Section 4.1.2 for upstream
	(Path message) initiated association and Section 4.2.1 for downstream		(Path message) initiated association and Section 4.2.1 for downstream
	(Resv message) initiated association. There are no type-specific		(Resv message) initiated association. There are no type-specific
	association rules, processing rules, or ordering requirements. Note		association rules, processing rules, or ordering requirements. Note
	that as is always the case with association as enabled by this		that as is always the case with association as enabled by this
	document, no associations are made across Path and Resv state.		document, no associations are made across Path and Resv state.
	Once an association is identified, resources SHOULD be shared across		Once an association is identified, resources MUST be considered as
	the identified sessions. Resource sharing is discussed in general in		shared across the identified sessions by the admission control
			function. Since the admission control function is outside the scope
	[RFC2205] and within the context of LSPs in [RFC3209].		of RSVP, we observe that how resource sharing is actually reflected
			may vary according to specific implementations (e.g. depending on the
			specific admission control and resource management algorithm, or on
			how local policy is taken into account).
	4. IPv4 and IPv6 Extended ASSOCIATION Objects		4. IPv4 and IPv6 Extended ASSOCIATION Objects
	[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6		[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
	ASSOCIATION object. As defined, these objects each contain an		ASSOCIATION object. As defined, these objects each contain an
	Association Source field and a 16-bit Association ID field. The		Association Source field and a 16-bit Association ID field. The
	combination of the Association Source and the Association ID uniquely		combination of the Association Source and the Association ID uniquely
	identifies the association. Because the association-ID field is a		identifies the association. Because the Association ID field is a
	16-bit field, an association source can allocate up to 65536		16-bit field, an association source can allocate up to 65536
	different associations and no more. There are scenarios where this		different associations and no more. There are scenarios where this
	number is insufficient. (For example where the association		number is insufficient. (For example where the association
	identification is best known and identified by a fairly centralized		identification is best known and identified by a fairly centralized
	entity, which therefore may be involved in a large number of		entity, which therefore may be involved in a large number of
	associations.)		associations.)
	An additional case that cannot be supported using the existing		An additional case that cannot be supported using the existing
	ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370],		ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370],
	MPLS-TP LSPs can be identified based on an operator unique global		MPLS-TP LSPs can be identified based on an operator unique global
	skipping to change at page 12, line 7		skipping to change at page 12, line 7
	Association ID: 16 bits		Association ID: 16 bits
	Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2.		Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2.
	Association Source: 4 or 16 bytes		Association Source: 4 or 16 bytes
	Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].		Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
	Global Association Source: 4 bytes		Global Association Source: 4 bytes
	This field contains a value that is a unique global identifier.		This field contains a value that is a unique global identifier or
	This field MAY contain the 2-octet or 4-octet value of the		the special value zero (0). When non-zero and not overridden by
	provider's Autonomous System Number (ASN). It is expected that		local policy, the Global_ID as defined in [RFC6370] SHALL be used.
	the global identifier will be derived from the globally unique ASN		The special value of zero indicates that no global identifier is
	of the autonomous system hosting the Association Source. The		present. Use of the special value of zero SHOULD be limited to
	special value of zero (0) indicates that no global identifier is		entities contained within a single operator.
	present. Note that a Global Association Source of zero SHOULD be
	limited to entities contained within a single operator.
	If the Global Association Source field value is derived from a		If the Global Association Source field value is derived from a
	2-octet AS number, then the two high-order octets of this 4-octet		2-octet AS number, then the two high-order octets of this 4-octet
	field MUST be set to zero.		field MUST be set to zero.
	Note, as stated in [RFC6370], "the use of the Global_ID is not		Note, as stated in [RFC6370], "the use of the Global_ID is not
	related to the use of the ASN in protocols such as BGP."		related to the use of the ASN in protocols such as BGP."
	This field is based on the definition of Global_ID defined in		This field is based on the definition of Global_ID defined in
	[RFC5003] and used by [RFC6370].		[RFC5003] and used by [RFC6370].
	Extended Association ID: variable, 4-byte aligned		Extended Association ID: variable, 4-byte aligned
	This field contains data that is additional information to support		This field contains data that is additional information to support
	unique identification. The length and contents of this field is		unique identification. The length and contents of this field is
	determined by the Association Source. This field MAY be omitted,		scoped by the Association Source. The length of this field is
	i.e., have a zero length. This field MUST be padded with zeros		derived from the object Length field and as such MUST have a zero
	(0s) to ensure 32-bit alignment.		length or be 4-byte aligned. A zero length indicates that this
			field is omitted.
	4.2. Processing		4.2. Processing
	The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST be		The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST be
	identical to the processing of a IPv4 or IPv6 ASSOCIATION object as		identical to the processing of a IPv4 or IPv6 ASSOCIATION object as
	described above except as extended by this section. This section		described above except as extended by this section. This section
	applies to ASSOCIATION objects included in both Path and Resv		applies to ASSOCIATION objects included in both Path and Resv
	messages.		messages.
	The following are the modified procedures for Extended ASSOCIATION		The following are the modified procedures for Extended ASSOCIATION
	skipping to change at page 14, line 46		skipping to change at page 14, line 46
	OLD:		OLD:
	2 Resource Sharing (R) [RFC4873]		2 Resource Sharing (R) [RFC4873]
	NEW		NEW
	2 Resource Sharing (S) [RFC4873][this-document]		2 Resource Sharing (S) [RFC4873][this-document]
	There are no other IANA considerations introduced by this document.		There are no other IANA considerations introduced by this document.
	7. Acknowledgments		7. Acknowledgments
	Valuable comments and input was received from Dimitri Papadimitriou		Valuable comments and input was received from Dimitri Papadimitriou,
	and Fei Zhang. We thank Subha Dhesikan for her contribution to the		Fei Zhang and Adrian Farrel. We thank Subha Dhesikan for her
	early work on sharing of resources across RSVP reservations.		contribution to the early work on sharing of resources across RSVP
			reservations.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and		[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
	S. Jamin, "Resource ReSerVation Protocol (RSVP) --		S. Jamin, "Resource ReSerVation Protocol (RSVP) --
	Version 1, Functional Specification", RFC 2205,		Version 1, Functional Specification", RFC 2205,
	September 1997.		September 1997.
	skipping to change at page 15, line 40		skipping to change at page 15, line 40
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,		[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
	"GMPLS Segment Recovery", RFC 4873, May 2007.		"GMPLS Segment Recovery", RFC 4873, May 2007.
	[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax		[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
	Used to Form Encoding Rules in Various Routing Protocol		Used to Form Encoding Rules in Various Routing Protocol
	Specifications", RFC 5511, April 2009		Specifications", RFC 5511, April 2009
	8.2. Informative References		8.2. Informative References
	[ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object",
	work in progress, draft-ietf-ccamp-assoc-info.
	[RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC		[RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC
	RSVP Extensions for IPSEC Data Flows", RFC 2207, September		RSVP Extensions for IPSEC Data Flows", RFC 2207, September
	1997.		1997.
	[RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation		[RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation
	of RSVP for IPv4 and IPv6 Reservations", RFC 3175,		of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
	September 2001.		September 2001.
	[RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M.,		[RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M.,
	"Generic Aggregate Resource ReSerVation Protocol (RSVP)		"Generic Aggregate Resource ReSerVation Protocol (RSVP)
	skipping to change at page 16, line 19		skipping to change at page 16, line 19
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session
	Traversal Utilities for NAT (STUN)", RFC 5389, October		Traversal Utilities for NAT (STUN)", RFC 5389, October
	2008.		2008.
	[RFC5920] Fang, L., et al, "Security Framework for MPLS and		[RFC5920] Fang, L., et al, "Security Framework for MPLS and
	GMPLS Networks", RFC 5920, July 2010.		GMPLS Networks", RFC 5920, July 2010.
	[RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",		[RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",
	RFC 6370, June 2011.		RFC 6370, June 2011.
			[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
			6689, July 2012.
	9. Authors' Addresses		9. Authors' Addresses
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Phone: +1-301-468-9228		Phone: +1-301-468-9228
	Email: lberger@labn.net		Email: lberger@labn.net
	Francois Le Faucheur		Francois Le Faucheur
	Cisco Systems		Cisco Systems
	Greenside, 400 Avenue de Roumanille		Greenside, 400 Avenue de Roumanille
	skipping to change at line 753		skipping to change at line 755
	France		France
	Email: flefauch@cisco.com		Email: flefauch@cisco.com
	Ashok Narayanan		Ashok Narayanan
	Cisco Systems		Cisco Systems
	300 Beaver Brook Road		300 Beaver Brook Road
	Boxborough, MA 01719		Boxborough, MA 01719
	United States		United States
	Email: ashokn@cisco.com		Email: ashokn@cisco.com
	Generated on: Mon, Feb 27, 2012 10:30:59 AM		Generated on: Tue, Aug 14, 2012 9:39:19 AM
End of changes. 29 change blocks.
	87 lines changed or deleted		89 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/