draft-ietf-ccamp-assoc-ext-00.txt		draft-ietf-ccamp-assoc-ext-01.txt
	Internet Draft Lou Berger (LabN)		Internet Draft Lou Berger (LabN)
	Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco)		Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco)
	Category: Standards Track Ashok Narayanan (Cisco)		Category: Standards Track Ashok Narayanan (Cisco)
	Expiration Date: November 1, 2011		Expiration Date: April 28, 2012
	May 1, 2011		October 28, 2011
	RSVP Association Object Extensions		RSVP Association Object Extensions
	draft-ietf-ccamp-assoc-ext-00.txt		draft-ietf-ccamp-assoc-ext-01.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 48		skipping to change at page 1, line 48
	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 November 1, 2011		This Internet-Draft will expire on April 28, 2012
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	2 Non-GMPLS Recovery Usage ............................... 4		2 Non-GMPLS Recovery Usage ............................... 4
	2.1 Upstream Initiated Association ......................... 4		2.1 Upstream Initiated Association ......................... 4
	2.1.1 Path Message Format .................................... 5		2.1.1 Path Message Format .................................... 5
	2.1.2 Path Message Processing ................................ 5		2.1.2 Path Message Processing ................................ 5
	2.2 Downstream Initiated Association ....................... 6		2.2 Downstream Initiated Association ....................... 6
	2.2.1 Resv Message Format .................................... 7		2.2.1 Resv Message Format .................................... 7
	2.2.2 Resv Message Processing ................................ 7		2.2.2 Resv Message Processing ................................ 7
	2.3 Association Types ...................................... 8		2.3 Association Types ...................................... 8
	2.3.1 Resource Sharing Association Type ...................... 8		2.3.1 Resource Sharing Association Type ...................... 8
	3 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 9		3 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 9
	3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10		3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 9
	3.2 Processing ............................................. 11		3.2 Processing ............................................. 11
	4 Security Considerations ................................ 13		4 Security Considerations ................................ 12
	5 IANA Considerations .................................... 13		5 IANA Considerations .................................... 13
	5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 13		5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 13
	5.2 Resource Sharing Association Type ...................... 14		5.2 Resource Sharing Association Type ...................... 13
	6 Acknowledgments ........................................ 14		6 Acknowledgments ........................................ 14
	7 References ............................................. 14		7 References ............................................. 14
	7.1 Normative References ................................... 14		7.1 Normative References ................................... 14
	7.2 Informative References ................................. 15		7.2 Informative References ................................. 14
	8 Authors' Addresses ..................................... 15		8 Authors' Addresses ..................................... 15
	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 5, line 37		skipping to change at page 5, line 37
	<Path Message> ::= <Common Header> [ <INTEGRITY> ]		<Path Message> ::= <Common Header> [ <INTEGRITY> ]
	<SESSION> <RSVP_HOP>		<SESSION> <RSVP_HOP>
	<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. Association type specific		type SHOULD be preserved by transit nodes.
	ordering requirements MAY be defined in the future.
	2.1.2. Path Message Processing		2.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 that wishes to allow downstream nodes to associate Path state		A node that wishes to allow downstream nodes to associate Path state
	across RSVP sessions MUST include an ASSOCIATION object in the		across RSVP sessions MUST include an ASSOCIATION object in the
	skipping to change at page 9, line 25		skipping to change at page 9, line 25
	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.)
	Furthermore, per [TP-IDENTIFIERS], MPLS-TP LSPs can be identified in		An additional case that cannot be supported using the existing
	two forms that cannot be supported using the existing ASSOCIATION		ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370],
	objects. The first form is a global identifier and the second uses		MPLS-TP LSPs can be identified based on an operator unique global
	an ITU Carrier Code (ICC). The [TP-IDENTIFIERS] defined "global		identifier. The [RFC6370] defined "global identifier", or Global_ID,
	identifier", or Global_ID, is based on [RFC5003] and includes the		is based on [RFC5003] and includes the operator's Autonomous System
	operator's Autonomous System Number (ASN). [TP-IDENTIFIERS]		Number (ASN).
	identifies the ICC as "a string of one to six characters, each
	character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9)
	characters. Alphabetic characters in the ICC SHOULD be represented
	with upper case letters."
	This sections defines new ASSOCIATION objects to support extended		This sections defines new ASSOCIATION objects to support extended
	identification in order to address the limitations described above.		identification in order to address the limitations described above.
	Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended		Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended
	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
	skipping to change at page 11, line 24		skipping to change at page 11, line 20
	the global identifier will be derived from the globally unique ASN		the global identifier will be derived from the globally unique ASN
	of the autonomous system hosting the Association Source. The		of the autonomous system hosting the Association Source. The
	special value of zero (0) indicates that no global identifier is		special value of zero (0) indicates that no global identifier is
	present. Note that a Global Association Source of zero SHOULD be		present. Note that a Global Association Source of zero SHOULD be
	limited to entities contained within a single operator.		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.
	Please note that, as stated in [TP-IDENTIFIERS], the use of the		Please note that, as stated in [RFC6370], the use of the
	provider's ASN as a global identifier DOES NOT have anything at		provider's ASN as a global identifier DOES NOT have anything at
	all to do with the use of the ASN in protocols such as BGP.		all to do with 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 [TP-IDENTIFIERS].		[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		3.2. Processing
	skipping to change at page 12, line 23		skipping to change at page 12, line 20
	o The Extended ASSOCIATION object originator MAY include the		o The Extended ASSOCIATION object originator MAY include the
	Extended Association ID field. The field is included based on		Extended Association ID field. The field is included based on
	local policy. The field MUST be included when the Association ID		local policy. The field MUST be included when the Association ID
	field is insufficient to uniquely identify association within the		field is insufficient to uniquely identify association within the
	scope of the source of the association. When included, this		scope of the source of the association. When included, this
	field MUST be set to a value that, when taken together with the		field MUST be set to a value that, when taken together with the
	other fields in the object, uniquely identifies the sessions to		other fields in the object, uniquely identifies the sessions to
	be associated.		be associated.
	When used in support of ICC identified (MPLS-TP) LSPs, this field
	MUST be at least eight (8) bytes long, and MAY be longer; the
	first six (6) bytes MUST be set to the ICC as defined in Section
	3.2 of [TP-IDENTIFIERS] and the next two bytes MUST be set to
	zero (0). For non-ICC identified MPLS-TP LSPs, this field MUST
	either be omitted, or MUST have the first 6 bytes set to all
	zeros (0s).
	o The object Length field is set based on the length of the		o The object Length field is set based on the length of the
	Extended Association ID field. When the Extended Association ID		Extended Association ID field. When the Extended Association ID
	field is omitted, the object Length field MUST be set to 16 or 28		field is omitted, the object Length field MUST be set to 16 or 28
	for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the		for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the
	Extended Association ID field is present, the object Length field		Extended Association ID field is present, the object Length field
	MUST be set to indicate the additional bytes carried in the		MUST be set to indicate the additional bytes carried in the
	Extended Association ID field, including pad bytes.		Extended Association ID field, including pad bytes.
	Note: per [RFC2205], the object Length field is set to the total		Note: per [RFC2205], the object Length field is set to the total
	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
	skipping to change at page 15, line 41		skipping to change at page 15, line 22
	[RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J.,		[RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J.,
	"Attachment Individual Identifier (AII) Types for		"Attachment Individual Identifier (AII) Types for
	Aggregation", RFC 5003, September 2007.		Aggregation", RFC 5003, September 2007.
	[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", work in progress, RFC 5920, July 2010.		GMPLS Networks", RFC 5920, July 2010.
	[TP-IDENTIFIERS] Bocci, M., Swallow, G., Gray, E., "MPLS-TP		[RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",
	Identifiers", work in progress,		RFC 6370, June 2011.
	draft-ietf-mpls-tp-identifiers.
	8. Authors' Addresses		8. 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 725		skipping to change at line 712
	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, May 02, 2011 10:17:58 AM		Generated on: Fri, Oct 28, 2011 8:00:39 AM
End of changes. 17 change blocks.
	34 lines changed or deleted		21 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/