draft-ietf-ccamp-assoc-ext-05.txt		draft-ietf-ccamp-assoc-ext-06.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: March 5, 2013		Expiration Date: March 21, 2013
	September 5, 2012		September 21, 2012
	RSVP Association Object Extensions		RSVP Association Object Extensions
	draft-ietf-ccamp-assoc-ext-05.txt		draft-ietf-ccamp-assoc-ext-06.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
	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 March 5, 2013		This Internet-Draft will expire on March 21, 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 37		skipping to change at page 2, line 37
	3.1.1 Path Message Format .................................... 6		3.1.1 Path Message Format .................................... 6
	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 .................................... 8		3.2.1 Resv Message Format .................................... 8
	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
	3.3.2 Unknown Association Types .............................. 10		3.3.2 Unknown Association Types .............................. 10
	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 ....... 11		4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 11
	4.2 Processing ............................................. 12		4.2 Processing ............................................. 13
	5 Compatibility .......................................... 13		5 Compatibility .......................................... 14
	6 Security Considerations ................................ 14		6 Security Considerations ................................ 14
	7 IANA Considerations .................................... 14		7 IANA Considerations .................................... 15
	7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14		7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 15
	7.2 Resource Sharing Association Type ...................... 15		7.2 Resource Sharing Association Type ...................... 15
	8 Acknowledgments ........................................ 15		8 Acknowledgments ........................................ 16
	9 References ............................................. 15		9 References ............................................. 16
	9.1 Normative References ................................... 15		9.1 Normative References ................................... 16
	9.2 Informative References ................................. 16		9.2 Informative References ................................. 16
	10 Authors' Addresses ..................................... 17		10 Authors' Addresses ..................................... 17
	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
	skipping to change at page 7, line 41		skipping to change at page 7, line 41
	the scope of this document.		the scope of this document.
	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,		MUST forward all ASSOCIATION objects received in a Path message,
	without modification, in any corresponding outgoing Path messages.		without modification, in any corresponding outgoing Path messages.
			This processing MUST be followed for unknown Association Type field
			values.
	3.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-LSP		Resv state across MPLS Tunnels / RSVP sessions. Cross-LSP
	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
	skipping to change at page 9, line 25		skipping to change at page 9, line 25
	compared. Type-specific processing of ASSOCIATION objects is outside		compared. Type-specific processing of ASSOCIATION objects is outside
	the scope of this document.		the scope of this document.
	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, without		forward all ASSOCIATION objects received in a Resv message, without
	modification, in any corresponding outgoing Resv messages.		modification, in any corresponding outgoing Resv messages. This
			processing MUST be followed for unknown Association Type field
			values.
	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
	applicable to any context and its general use is defined in this		applicable to any context and its general use is defined in this
	section.		section.
	3.3.1. Resource Sharing Association Type		3.3.1. Resource Sharing Association Type
	skipping to change at page 10, line 21		skipping to change at page 10, line 23
	shared across the identified sessions by the admission control		shared across the identified sessions by the admission control
	function. Since the implementation specifics of the admission control		function. Since the implementation specifics of the admission control
	function is outside the scope of RSVP, we observe that how resource		function is outside the scope of RSVP, we observe that how resource
	sharing is actually reflected may vary according to specific		sharing is actually reflected may vary according to specific
	implementations (e.g. depending on the specific admission control and		implementations (e.g. depending on the specific admission control and
	resource management algorithm, or on how local policy is taken into		resource management algorithm, or on how local policy is taken into
	account).		account).
	3.3.2. Unknown Association Types		3.3.2. Unknown Association Types
	A node that receives an ASSOCIATION object with an unknown		As required by Sections 3.1.2 and 3.2.2 above, a node that receives
	ASSOCIATION type MUST forward all received ASSOCIATION objects as		an ASSOCIATION object containing an unknown ASSOCIATION type forwards
	defined above. The node MAY also identify associations per the		all received ASSOCIATION objects as defined above. The node MAY also
	defined processing, e.g., to make this information available via a		identify associations per the defined processing, e.g., to make this
	management interface.		information available via a management interface.
	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. As		Association Source field and a 16-bit Association ID field. As
	described above, the contents of the object uniquely identifies an		described above, the contents of the object uniquely identify an
	association. Because the Association ID field is a 16-bit field, an		association. Because the Association ID field is a 16-bit field, an
	association source can allocate up to 65536 different associations		association source can allocate up to 65536 different associations
	and no more. There are scenarios where this number is insufficient.		and no more. There are scenarios where this number is insufficient.
	(For example where the association identification is best known and		(For example where the association identification is best known and
	identified by a fairly centralized entity, which therefore may be		identified by a fairly centralized entity, which therefore may be
	involved in a large number of associations.)		involved in a large number of 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 13, line 45		skipping to change at page 14, line 17
	The procedures related to association identification are not modified		The procedures related to association identification are not modified
	by this section. It is important to note that Section 4 defines the		by this section. It is important to note that Section 4 defines the
	identification of associations based on ASSOCIATION object matching		identification of associations based on ASSOCIATION object matching
	and that such matching, in the absence of type-specific comparison		and that such matching, in the absence of type-specific comparison
	rules, is based on the comparison of all fields in an ASSOCIATION		rules, is based on the comparison of all fields in an ASSOCIATION
	object. This applies equally to ASSOCIATION objects and Extended		object. This applies equally to ASSOCIATION objects and Extended
	ASSOCIATION objects.		ASSOCIATION objects.
	5. Compatibility		5. Compatibility
	Per [RFC4872], the ASSOCIATION object uses an object class number of		Per [RFC4872], the ASSOCIATION object uses an object class number
	the form 11bbbbbb to ensure compatibility with non- supporting nodes.		of the form 11bbbbbb to ensure compatibility with non-supporting
	Per [RFC2205], such nodes will ignore the object but forward it		nodes. Per [RFC2205], such nodes will ignore the object but
	without modification. This is essentially also the action taken for		forward it without modification. This is also the action taken
	unknown association types as discussed above in Section 3.3.2.		for unknown association types as discussed above in Section
	Operators wishing to use a function supported by particular		3.1.2,
	association type should ensure that the type is supported on any node		3.2.2, and 3.3.2.
	which is expected to act on the association.
			Per [RFC4872], transit nodes that support the ASSOCIATION object,
			but not the Extended Association C-Types, will "transmit, without
			modification, any received ASSOCIATION object in the
			corresponding
			outgoing Path message." Per [RFC2205], an egress node that
			supports
			the ASSOCIATION object, but not the Extended Association C-Types
			may generate an "Unknown object C-Type" error. This error will
			propagate to the ingress node for standard error processing.
			Operators wishing to use a function supported by particular
			association type should ensure that the type is supported on any
			node which is expected to act on the association.
	6. Security Considerations		6. 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
	skipping to change at line 782		skipping to change at line 799
	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, Sep 05, 2012 5:37:17 PM		Generated on: Fri, Sep 21, 2012 9:36:09 AM
End of changes. 13 change blocks.
	26 lines changed or deleted		43 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/