draft-ietf-ccamp-assoc-ext-02.txt		draft-ietf-ccamp-assoc-ext-03.txt
	Internet Draft Lou Berger (LabN)		Internet Draft Lou Berger (LabN)
	Updates: 2205, 3209, 3473 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: August 16, 2012		Expiration Date: September 9, 2012
	February 16, 2012		March 9, 2012
	RSVP Association Object Extensions		RSVP Association Object Extensions
	draft-ietf-ccamp-assoc-ext-02.txt		draft-ietf-ccamp-assoc-ext-03.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 Transport Profile of Multiprotocol Label Switching
	(MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC		(MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC
	3473.		3473. It also modifies the definition of the Association 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 48		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 August 16, 2012		This Internet-Draft will expire on September 9, 2012
	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
	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 Conventions Used In This Document ...................... 4		1.1 Conventions Used In This Document ...................... 4
	2 Non-GMPLS Recovery Usage ............................... 4		2 Modified Association ID Field Definition ............... 4
	2.1 Upstream Initiated Association ......................... 4		3 Non-GMPLS Recovery Usage ............................... 5
	2.1.1 Path Message Format .................................... 5		3.1 Upstream Initiated Association ......................... 5
	2.1.2 Path Message Processing ................................ 5		3.1.1 Path Message Format .................................... 5
	2.2 Downstream Initiated Association ....................... 7		3.1.2 Path Message Processing ................................ 6
	2.2.1 Resv Message Format .................................... 7		3.2 Downstream Initiated Association ....................... 7
	2.2.2 Resv Message Processing ................................ 7		3.2.1 Resv Message Format .................................... 7
	2.3 Association Types ...................................... 8		3.2.2 Resv Message Processing ................................ 8
	2.3.1 Resource Sharing Association Type ...................... 8		3.3 Association Types ...................................... 9
	3 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 9		3.3.1 Resource Sharing Association Type ...................... 9
	3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10		4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10
	3.2 Processing ............................................. 11		4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10
	4 Security Considerations ................................ 13		4.2 Processing ............................................. 12
	5 IANA Considerations .................................... 13		5 Security Considerations ................................ 13
	5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 13		6 IANA Considerations .................................... 14
	5.2 Resource Sharing Association Type ...................... 14		6.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14
	6 Acknowledgments ........................................ 14		6.2 Resource Sharing Association Type ...................... 14
	7 References ............................................. 14		7 Acknowledgments ........................................ 14
	7.1 Normative References ................................... 14		8 References ............................................. 15
	7.2 Informative References ................................. 15		8.1 Normative References ................................... 15
	8 Authors' Addresses ..................................... 15		8.2 Informative References ................................. 15
			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 [ASSOC-INFO].
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	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 today, since
	the SESSION objects for these two flows outside the NAT would		the SESSION objects for these two flows outside the NAT would
	have different ports.		have different ports.
			In order to support the more general usage of the ASSOCIATION object,
			this document modifies the definition of the Association ID field
			defined in RFC 4872. This modification has no impact on existing
			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 Transport Profile of Multiprotocol Label
	Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION		Switching (MPLS-TP). Although, 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. Non-GMPLS Recovery Usage		2. Modified Association ID Field Definition
			The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION
			objects defined in [RFC4872]. The [RFC4872] definition of the field
			reads:
			A value assigned by the LSP head-end. When combined with the
			Association Type and Association Source, this value uniquely
			identifies an association.
			This document allows for the origination of ASSOCIATION objects by
			nodes other than "the LSP head-end". As such, the definition of the
			Association ID field needs to be modified to accommodate such usage.
			This document defines the Association ID field of the IPv4 and IPv6
			ASSOCIATION objects as:
			A value assigned by the the node that originated the association.
			When combined with the other fields carried in the object, this
			value uniquely identifies an association.
			This change in definition does not impact [RFC4872] or [RFC4873]
			defined procedures or mechanisms, nor does it impact existing
			implementations of [RFC4872] or [RFC4873].
			3. Non-GMPLS 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 defines 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 [ASSOC-INFO], this is the case for Recovery
	type association objects. [ASSOC-INFO], notably the text related to		type association objects. [ASSOC-INFO], notably the text related to
	skipping to change at page 4, line 44		skipping to change at page 5, line 33
	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. Note that there are times when no matching state is found,
	e.g., when processing an initial LSP or when the ASSOCIATION object		e.g., when processing an initial LSP or when the ASSOCIATION object
	contains otherwise useful information, and such cases do not alter		contains otherwise useful information, and such cases do not alter
	the processing defined below. This section applies to the		the processing defined below. This section applies to the
	ASSOCIATION objects defined in [RFC4872].		ASSOCIATION objects defined in [RFC4872].
	2.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 definition is
	extended by this section, which defined generic association rules and		extended by this section, which defined generic association rules and
	usage for non-LSP uses. This section does not modify processing		usage for non-LSP uses. This section does not modify processing
	required to support [RFC4872] and [RFC4873], and which is reviewed in		required to support [RFC4872] and [RFC4873], and which is reviewed in
	Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a		Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a
	single session is not precluded.		single session is not precluded.
	2.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:
	<Path Message> ::= <Common Header> [ <INTEGRITY> ]		<Path Message> ::= <Common Header> [ <INTEGRITY> ]
	skipping to change at page 5, line 43		skipping to change at page 6, line 32
	<TIME_VALUES>		<TIME_VALUES>
	[ <ASSOCIATION> ... ]		[ <ASSOCIATION> ... ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	[ <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.
	2.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 [ASSOC-INFO]. These
	procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session		procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session
	state.		state.
	A node initiating a Path message chooses when an ASSOCIATION object		A node sending a Path message chooses when an ASSOCIATION object is
	is to be included in the outgoing Path message. A node that wishes		to be included in the outgoing Path message. A node that wishes to
	to allow downstream nodes to associate Path state across RSVP		allow downstream nodes to associate Path state across RSVP sessions
	sessions MUST include an ASSOCIATION object in the outgoing Path		MUST include an ASSOCIATION object in the outgoing Path messages
	messages corresponding to the RSVP sessions to be associated. In the		corresponding to the RSVP sessions to be associated. In the absence
	absence of Association Type-specific rules for identifying		of Association Type-specific rules for identifying association, the
	association, the included ASSOCIATION objects MUST be identical		included ASSOCIATION objects MUST be identical across all associated
	across all associated sessions. When there is an Association Type-		sessions. When there is an Association Type-specific definition of
	specific definition of association rules, the definition SHOULD allow		association rules, the definition SHOULD allow for association based
	for association based on identical ASSOCIATION objects. This		on identical ASSOCIATION objects. This document does not define any
	document does not define any Association Type-specific rules. (See		Association Type-specific rules. (See Section 3 of [ASSOC-INFO] for
	Section 3 of [ASSOC-INFO] for a review of Association Type-specific		a review of Association Type-specific rules derived from [RFC4872].)
	rules derived 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 7, line 5		skipping to change at page 7, line 34
	Note that as more than one association may exist, the described		Note that as more than one association may exist, the described
	matching MUST continue after a match is identified, and MUST be		matching MUST continue after a match is identified, and MUST be
	performed against all local Path state. It is also possible for		performed against all local Path state. It is also possible for
	there to be no match identified.		there to be no match identified.
	Unless there are type-specific processing rules, downstream nodes		Unless there are type-specific processing rules, downstream nodes
	MUST forward all ASSOCIATION objects received in a Path message in		MUST forward all ASSOCIATION objects received in a Path message in
	any corresponding outgoing Path messages.		any corresponding outgoing Path messages.
	2.2. Downstream Initiated Association		3.2. Downstream Initiated Association
	Downstream initiated association is represented in ASSOCIATION		Downstream initiated association is represented in ASSOCIATION
	objects carried in Resv messages and can be used to associate RSVP		objects carried in Resv messages and can be used to associate RSVP
	Resv state across MPLS Tunnels / RSVP sessions. Cross-session		Resv state across MPLS Tunnels / RSVP sessions. Cross-session
	association based on Path state is defined in [RFC4872]. This section		association based on Path state is defined in [RFC4872]. This section
	defines cross-session association based on Resv state. This section		defines cross-session association based on Resv state. This section
	places no additional requirements on implementations supporting		places no additional requirements on implementations supporting
	[RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a		[RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a
	single session is not precluded.		single session is not precluded.
	2.2.1. Resv Message Format		3.2.1. Resv Message Format
	This section provides the Backus-Naur Form (BNF), see [RFC5511], for		This section provides the Backus-Naur Form (BNF), see [RFC5511], for
	Resv messages containing ASSOCIATION objects. BNF is provided for		Resv 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, GMPLS and non-LSP sessions are identical, and is		The format for MPLS, GMPLS and non-LSP sessions are identical, and is
	represented based on the BNF in [RFC2205] and [RFC3209]:		represented based on the BNF in [RFC2205] and [RFC3209]:
	<Resv Message> ::= <Common Header> [ <INTEGRITY> ]		<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
	skipping to change at page 7, line 40		skipping to change at page 8, line 20
	[ <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 MUST be preserved by transit nodes. Association type specific
	ordering requirements MAY be defined in the future.		ordering requirements MAY be defined in the future.
	2.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 initiating a Resv message chooses when an ASSOCIATION object		A node sending a Resv message chooses when an ASSOCIATION object is
	is to be included in the outgoing Resv message. A node that wishes		to be included in the outgoing Resv message. A node that wishes to
	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
	corresponding to the RSVP sessions to be associated. In the absence		corresponding to the RSVP sessions to be associated. In the absence
	of Association Type-specific rules for identifying association, the		of Association Type-specific rules for identifying association, the
	included ASSOCIATION objects MUST be identical. When there is an		included ASSOCIATION objects MUST be identical. When there is an
	Association Type-specific definition of association rules, the		Association Type-specific definition of association rules, the
	definition SHOULD allow for association based on identical		definition SHOULD allow for association based on identical
	ASSOCIATION objects. This document does not define any Association		ASSOCIATION objects. This document does not define any Association
	Type-specific rules.		Type-specific rules.
	When creating an ASSOCIATION object, the originator MUST format the		When creating an ASSOCIATION object, the originator MUST format the
	skipping to change at page 8, line 40		skipping to change at page 9, line 20
	Note that as more than one association may exist, the described		Note that as more than one association may exist, the described
	matching MUST continue after a match is identified, and MUST be		matching MUST continue after a match is identified, and MUST be
	performed against all local Resv state. It is also possible for there		performed against all local Resv state. It is also possible for there
	to be no match identified.		to be no match identified.
	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.
	2.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.		generally useful and its general use is defined in this section.
	2.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
	order to support [RFC4873]. The Resource Sharing Association Type		order to support [RFC4873]. The Resource Sharing Association Type
	MUST be supported by any implementation compliant with this document.		MUST be supported by any implementation compliant with this document.
	skipping to change at page 9, line 24		skipping to change at page 10, line 4
	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 SHOULD be shared across
	the identified sessions. Resource sharing is discussed in general in		the identified sessions. Resource sharing is discussed in general in
	[RFC2205] and within the context of LSPs in [RFC3209].		[RFC2205] and within the context of LSPs in [RFC3209].
	3. 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
	skipping to change at page 10, line 11		skipping to change at page 10, line 41
	ASSOCIATION object are defined below. Both new objects include the		ASSOCIATION object are defined below. Both new objects include the
	fields necessary to enable identification of a larger number of		fields necessary to enable identification of a larger number of
	associations, as well as MPLS-TP required identification.		associations, as well as MPLS-TP required identification.
	The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION		The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION
	object SHOULD be supported by an implementation compliant with this		object SHOULD be supported by an implementation compliant with this
	document. The processing rules for the IPv4 and IPv6 Extended		document. The processing rules for the IPv4 and IPv6 Extended
	ASSOCIATION object are described below, and are based on the rules		ASSOCIATION object are described below, and are based on the rules
	for the IPv4 and IPv6 ASSOCIATION objects as described above.		for the IPv4 and IPv6 ASSOCIATION objects as described above.
	3.1. IPv4 and IPv6 Extended ASSOCIATION Object Format		4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format
	The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb		The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb
	with value = 199, C-Type = TBA) has the format:		with value = 199, C-Type = TBA) has the format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num(199)| C-Type (TBA) |		| Length | Class-Num(199)| C-Type (TBA) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Association Type | Association ID |		| Association Type | Association ID |
	skipping to change at page 11, line 11		skipping to change at page 11, line 49
	: Extended Association ID :		: Extended Association ID :
	: . :		: . :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Association Type: 16 bits		Association Type: 16 bits
	Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].		Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
	Association ID: 16 bits		Association ID: 16 bits
	Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].		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.
	This field MAY contain the 2-octet or 4-octet value of the		This field MAY contain the 2-octet or 4-octet value of the
	provider's Autonomous System Number (ASN). It is expected that		provider's Autonomous System Number (ASN). It is expected that
	skipping to change at page 11, line 46		skipping to change at page 12, line 34
	[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,		determined by the Association Source. This field MAY be omitted,
	i.e., have a zero length. This field MUST be padded with zeros		i.e., have a zero length. This field MUST be padded with zeros
	(0s) to ensure 32-bit alignment.		(0s) to ensure 32-bit alignment.
	3.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
	object processing:		object processing:
	skipping to change at page 13, line 5		skipping to change at page 13, line 34
	object length in bytes, and is always a multiple of 4, and at		object length in bytes, and is always a multiple of 4, and at
	least 4.		least 4.
	Identification of association is not modified by this section. It is		Identification of association is not modified by this section. It is
	important to note that Section 4 defines association identification		important to note that Section 4 defines association identification
	based on ASSOCIATION object matching, and that such matching is based		based on ASSOCIATION object matching, and that such matching is based
	on the comparison of all fields in a ASSOCIATION object (unless type-		on the comparison of all fields in a ASSOCIATION object (unless type-
	specific comparison rules are defined). This applies equally to		specific comparison rules are defined). This applies equally to
	ASSOCIATION objects and Extended ASSOCIATION objects.		ASSOCIATION objects and Extended ASSOCIATION objects.
	4. Security Considerations		5. Security Considerations
	A portion of this document reviews procedures defined in [RFC4872]		A portion of this document reviews procedures defined in [RFC4872]
	and [RFC4873] and does not define any new procedures. As such, no		and [RFC4873] and does not define any new procedures. As such, no
	new security considerations are introduced in this portion.		new security considerations are introduced in this portion.
	Section 2 defines broader usage of the ASSOCIATION object, but does		Section 2 defines broader usage of the ASSOCIATION object, but does
	not fundamentally expand on the association function that was		not fundamentally expand on the association function that was
	previously defined in [RFC4872] and [RFC4873]. Section 3 increases		previously defined in [RFC4872] and [RFC4873]. Section 3 increases
	the number of bits that are carried in an ASSOCIATION object (by 32),		the number of bits that are carried in an ASSOCIATION object (by 32),
	and similarly does not expand on the association function that was		and similarly does not expand on the association function that was
	previously defined. This broader definition does allow for		previously defined. This broader definition does allow for
	additional information to be conveyed, but this information is not		additional information to be conveyed, but this information is not
	fundamentally different from the information that is already carried		fundamentally different from the information that is already carried
	in RSVP. Therefore there are no new risks or security considerations		in RSVP. Therefore there are no new risks or security considerations
	introduced by this document.		introduced by this document.
	For a general discussion on MPLS and GMPLS related security issues,		For a general discussion on MPLS and GMPLS related security issues,
	see the MPLS/GMPLS security framework [RFC5920].		see the MPLS/GMPLS security framework [RFC5920].
	5. IANA Considerations		6. IANA Considerations
	IANA is requested to administer assignment of new values for		IANA is requested to administer assignment of new values for
	namespaces defined in this document and summarized in this section.		namespaces defined in this document and summarized in this section.
	5.1. IPv4 and IPv6 Extended ASSOCIATION Objects		6.1. IPv4 and IPv6 Extended ASSOCIATION Objects
	Upon approval of this document, IANA will make the assignment of two		Upon approval of this document, IANA will make the assignment of two
	new C-Types (which are defined in section 3.1) for the existing		new C-Types (which are defined in section 3.1) for the existing
	ASSOCIATION object in the "Class Names, Class Numbers, and Class		ASSOCIATION object in the "Class Names, Class Numbers, and Class
	Types" section of the "Resource Reservation Protocol (RSVP)		Types" section of the "Resource Reservation Protocol (RSVP)
	Parameters" registry located at http://www.iana.org/assignments/rsvp-		Parameters" registry located at http://www.iana.org/assignments/rsvp-
	parameters:		parameters:
	199 ASSOCIATION [RFC4872]		199 ASSOCIATION [RFC4872]
	Class Types or C-Types		Class Types or C-Types
	3 Type 3 IPv4 Extended Association [this document]		3 Type 3 IPv4 Extended Association [this document]
	4 Type 4 IPv6 Extended Association [this document]		4 Type 4 IPv6 Extended Association [this document]
	5.2. Resource Sharing Association Type		6.2. Resource Sharing Association Type
	This document also broadens the potential usage of the Resource		This document also broadens the potential usage of the Resource
	Sharing Association Type defined in [RFC4873]. As such, IANA is		Sharing Association Type defined in [RFC4873]. As such, IANA is
	requested to change the Reference of the Resource Sharing Association		requested to change the Reference of the Resource Sharing Association
	Type included in the associate registry. This document also directs		Type included in the associate registry. This document also directs
	IANA to correct the duplicate usage of '(R)' in this Registry. In		IANA to correct the duplicate usage of '(R)' in this Registry. In
	particular, the Association Type registry found at		particular, the Association Type registry found at
	http://www.iana.org/assignments/gmpls-sig-parameters/ should be		http://www.iana.org/assignments/gmpls-sig-parameters/ should be
	updated as follows:		updated as follows:
	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.
	6. 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		and Fei Zhang. We thank Subha Dhesikan for her contribution to the
	early work on sharing of resources across RSVP reservations.		early work on sharing of resources across RSVP reservations.
	7. References		8. References
	7.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.
	[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.
	[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
	Extensions in Support of End-to-End Generalized Multi-
	Protocol Label Switching (GMPLS) Recovery", RFC 4872,
	May 2007.
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
	"GMPLS Segment Recovery", RFC 4873, May 2007.
	[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 LSP		V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January		Engineering (RSVP-TE) Extensions", RFC 3473, January
	2003.		2003.
			[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
			Extensions in Support of End-to-End Generalized Multi-
			Protocol Label Switching (GMPLS) Recovery", RFC 4872,
			May 2007.
			[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
			"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
	7.2. Informative References		8.2. Informative References
	[ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object",		[ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object",
	work in progress, draft-ietf-ccamp-assoc-info.		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,
	skipping to change at page 15, line 45		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.
	8. 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
	Sophia Antipolis 06410		Sophia Antipolis 06410
	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
	skipping to change at line 721		skipping to change at line 753
	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: Wed, Feb 15, 2012 12:33:04 PM		Generated on: Mon, Feb 27, 2012 10:30:59 AM
End of changes. 37 change blocks.
	73 lines changed or deleted		105 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/