draft-ietf-ccamp-gmpls-ether-svcs-00.txt		draft-ietf-ccamp-gmpls-ether-svcs-01.txt
	Internet Draft Lou Berger (LabN)		Internet Draft Lou Berger (LabN)
	Updates: 3471, 3473, 3945, 4202		Updates: 3471, 3473, 3945, 4202
	Category: Standards Track Don Fedyk (Nortel)		Category: Standards Track Don Fedyk (Nortel)
	Expiration Date: October 14, 2008		Expiration Date: January 14, 2009
	April 14, 2008		July 14, 2008
	Generalized MPLS (GMPLS) Support For Metro Ethernet Forum		Generalized MPLS (GMPLS) Support For Metro Ethernet Forum
	and G.8011 Ethernet Service Switching		and G.8011 Ethernet Service Switching
	draft-ietf-ccamp-gmpls-ether-svcs-00.txt		draft-ietf-ccamp-gmpls-ether-svcs-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on October 14, 2008.		This Internet-Draft will expire on January 14, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document describes a method for controlling two specific types		This document describes a method for controlling two specific types
	of Ethernet switching via Generalized Multi-Protocol Label Switching		of Ethernet switching via Generalized Multi-Protocol Label Switching
	(GMPLS). This document supports the types of switching required to		(GMPLS). This document supports the types of switching required to
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	2.3.1 L2 Control Protocol TLV ................................... 8		2.3.1 L2 Control Protocol TLV ................................... 8
	2.4 Bundling and VLAN Identification .......................... 9		2.4 Bundling and VLAN Identification .......................... 9
	3 EPL Service ............................................... 9		3 EPL Service ............................................... 9
	3.1 EPL Service Parameters .................................... 10		3.1 EPL Service Parameters .................................... 10
	4 EVPL Service .............................................. 10		4 EVPL Service .............................................. 10
	4.1 EVPL Generalized Label Format ............................. 11		4.1 EVPL Generalized Label Format ............................. 11
	4.2 Egress VLAN ID Control and VLAN ID preservation ........... 11		4.2 Egress VLAN ID Control and VLAN ID preservation ........... 11
	4.3 Single Call - Single LSP .................................. 12		4.3 Single Call - Single LSP .................................. 12
	4.4 Single Call - Multiple LSPs ............................... 12		4.4 Single Call - Multiple LSPs ............................... 12
	5 Generic GMPLS Extensions .................................. 12		5 Generic GMPLS Extensions .................................. 12
	5.1 Notify Message Format ..................................... 13		5.1 Data Channel Switching .................................... 13
	5.2 Data Channel Switching .................................... 13		5.2 Generalized Channel_Set Label Related Formats ............. 13
	5.3 Generalized Channel_Set Label Related Formats ............. 14		5.2.1 Generalized Channel_Set LABEL_REQUEST Object .............. 13
	5.3.1 Generalized Channel_Set LABEL_REQUEST Object .............. 14		5.2.2 Generalized Channel_Set LABEL Object ...................... 14
	5.3.2 Generalized Channel_Set LABEL Object ...................... 14		5.2.3 Other Label related Objects ............................... 16
	5.3.3 Other Label related Objects ............................... 17
	6 IANA Considerations ....................................... 17		6 IANA Considerations ....................................... 17
	6.1 Endpoint ID Attributes TLV ................................ 17		6.1 Endpoint ID Attributes TLV ................................ 17
	6.2 Line LSP Encoding ......................................... 17		6.2 Line LSP Encoding ......................................... 17
	6.3 Data Channel Switching Type ............................... 18		6.3 Data Channel Switching Type ............................... 17
	6.4 Generalized Channel_Set LABEL_REQUEST Object .............. 18		6.4 Generalized Channel_Set LABEL_REQUEST Object .............. 18
	6.5 Generalized Channel_Set LABEL Object ...................... 18		6.5 Generalized Channel_Set LABEL Object ...................... 18
	7 Security Considerations ................................... 19		7 Security Considerations ................................... 18
	8 References ................................................ 19		8 References ................................................ 19
	8.1 Normative References ...................................... 19		8.1 Normative References ...................................... 19
	8.2 Informative References .................................... 20		8.2 Informative References .................................... 20
	9 Acknowledgments ........................................... 21		9 Acknowledgments ........................................... 21
	10 Author's Addresses ........................................ 21		10 Author's Addresses ........................................ 21
	11 Full Copyright Statement .................................. 21		11 Full Copyright Statement .................................. 21
	12 Intellectual Property ..................................... 22		12 Intellectual Property ..................................... 22
	1. Introduction		1. Introduction
	skipping to change at page 3, line 27		skipping to change at page 3, line 27
	[MEF6] and [G.8011] are focused on service interfaces and not the		[MEF6] and [G.8011] are focused on service interfaces and not the
	underlying technology used to support the service. For example,		underlying technology used to support the service. For example,
	[G.8011] refers to the defined services being transported over one of		[G.8011] refers to the defined services being transported over one of
	several possible "server layers". This document focuses on the types		several possible "server layers". This document focuses on the types
	of switching that may directly support these services and provides a		of switching that may directly support these services and provides a
	method for GMPLS based control of such switching technologies. This		method for GMPLS based control of such switching technologies. This
	document defines the GMPLS extensions needed to support such		document defines the GMPLS extensions needed to support such
	switching, but does not define the UNI or External NNI (E-NNI)		switching, but does not define the UNI or External NNI (E-NNI)
	reference points. See [GMPLS-MEF-UNI] for a description of the UNI		reference points. See [GMPLS-MEF-UNI] for a description of the UNI
	reference point. This document makes use of the traffic parameters		reference point. This document makes use of the traffic parameters
	defined in [MEF-TRAFFIC].		defined in [ETH-TRAFFIC].
	Some of the extensions defined in this document are generic in nature		Some of the extensions defined in this document are generic in nature
	and not specific to Ethernet, or [MEF6] and [G.8011] related		and not specific to Ethernet, or [MEF6] and [G.8011] related
	switching. [AUTHORS' NOTE: These extensions are presented in a		switching. [AUTHORS' NOTE: These extensions are presented in a
	separate section and may be split into their own document as this		separate section and may be split into their own document as this
	work progresses.]		work progresses.]
	1.1. Overview		1.1. Overview
	This document uses a largely common approach to supporting the		This document uses a largely common approach to supporting the
	skipping to change at page 4, line 45		skipping to change at page 4, line 45
	per connection. Other attributes are specific to a particular		per connection. Other attributes are specific to a particular
	connection, or must be consistent across the connection. The		connection, or must be consistent across the connection. The
	approach taken in this document to communicate these attributes is to		approach taken in this document to communicate these attributes is to
	exclude the static class of attributes from signaling. This class of		exclude the static class of attributes from signaling. This class of
	attributes will not be explicitly discussed in this document. The		attributes will not be explicitly discussed in this document. The
	other class of attributes are communicated via signaling and will be		other class of attributes are communicated via signaling and will be
	reviewed in the sections below. The major attributes that will be		reviewed in the sections below. The major attributes that will be
	supported in signaling include:		supported in signaling include:
	- Endpoint identifiers		- Endpoint identifiers
	- Connection identifiers		- Connection identifiers
	- Traffic parameters (see [MEF-TRAFFIC])		- Traffic parameters (see [ETH-TRAFFIC])
	- Bundling / VLAN IDs map (EVPL only)		- Bundling / VLAN IDs map (EVPL only)
	- VLAN ID Preservation (EVPL only)		- VLAN ID Preservation (EVPL only)
	Common procedures used to support Ethernet LSPs are described in		Common procedures used to support Ethernet LSPs are described in
	Section 2 of this document. Procedures related to signaling		Section 2 of this document. Procedures related to signaling
	switching in support of EPL services are described in Section 3.		switching in support of EPL services are described in Section 3.
	Procedures related to signaling switching in support of EVPL services		Procedures related to signaling switching in support of EVPL services
	are described in Section 4. Section 5 covers the generic GMPLS		are described in Section 4. Section 5 covers the generic GMPLS
	extensions proposed by this document.		extensions proposed by this document.
	skipping to change at page 5, line 36		skipping to change at page 5, line 36
	2.1. Ethernet Endpoint Identification		2.1. Ethernet Endpoint Identification
	Ethernet endpoint identifiers, as they are defined in [G.8011] and		Ethernet endpoint identifiers, as they are defined in [G.8011] and
	[MEF10.1], differ significantly from the identifiers used by GMPLS.		[MEF10.1], differ significantly from the identifiers used by GMPLS.
	Specifically, the Ethernet endpoint identifiers are character based		Specifically, the Ethernet endpoint identifiers are character based
	as apposed to the GMPLS norm of being IP address based.		as apposed to the GMPLS norm of being IP address based.
	The approach taken by this document to address this disparity		The approach taken by this document to address this disparity
	leverages the solution used for connection identification, see		leverages the solution used for connection identification, see
	Section 2.2 and [RFC4974], and the LSP attributes object, see		Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in
	[RFC4420]. The solution makes use of the [RFC4974] short call ID,		this document. The solution makes use of the [RFC4974] short call
	and supports the Ethernet endpoint identifier much like [RFC4974]		ID, and supports the Ethernet endpoint identifier much like [RFC4974]
	supports the long call ID. That is, the SENDER_TEMPLATE and SESSION		supports the long call ID. That is, the SENDER_TEMPLATE and SESSION
	objects carry IP addresses and a short call ID, and long identifiers		objects carry IP addresses and a short call ID, and long identifiers
	are carried in the attributes object. As with the long call ID, the		are carried in the attributes object. As with the long call ID, the
	Ethernet endpoint identifier is typically only relevant at the		Ethernet endpoint identifier is typically only relevant at the
	ingress and egress nodes.		ingress and egress nodes.
	As defined below, the Ethernet endpoint identifier is carried in the		As defined below, the Ethernet endpoint identifier is carried in the
	LSP_ATTRIBUTES object in a new TLV. The new TLV is referred to as		CALL_ATTRIBUTES object in a new TLV. The new TLV is referred to as
	the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels		the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels
	the processing of the long call ID in [RFC4974]. This processing		the processing of the long call ID in [RFC4974]. This processing
	requires the inclusion of the LSP_ATTRIBUTES object in a Notify		requires the inclusion of the CALL_ATTRIBUTES object in a Notify
	message, see Section 5.1.		message.
	2.1.1. Endpoint ID TLV		2.1.1. Endpoint ID TLV
	The Endpoint ID TLV follows the Attributes TLV format defined in		The Endpoint ID TLV follows the Attributes TLV format defined in
	[RFC4420]. The Endpoint ID TLV has uses the Type value of TBA (by		[GMPLS-MRN]. The Endpoint ID TLV has the following format:
	IANA).
	The TLV has the following 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (TBA) | Length (variable) |		| Type (TBA) | Length (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Endpoint ID |		| Endpoint ID |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [RFC4420] for a description of the Type and Length fields.		Type and Length fields are defined in [GMPLS-MRN]. Note that as
	Note that per [RFC4420], the Length field is set to the unpadded		defined in [GMPLS-MRN], the Length field is set to length of the
	length of the Endpoint ID field.		whole TLV including the Type, Length and Endpoint ID fields.
	Endpoint ID		Endpoint ID
	The Endpoint ID field is a variable length field that carries		The Endpoint ID field is a variable size field that carries an
	an endpoint identifier, see [MEF10.1] and [G.8011]. This field		endpoint identifier, see [MEF10.1] and [G.8011]. This field
	MUST be null padded as defined in [RFC4420].		MUST be null padded as defined in [GMPLS-MRN].
	2.1.1.1. Procedures		2.1.1.1. Procedures
	The use of the Endpoint ID TLV is required during call management.		The use of the Endpoint ID TLV is required during call management.
	When a call is established or torn down per [RFC4974], an		When a call is established or torn down per [RFC4974], a
	LSP_ATTRIBUTES object containing an Endpoint ID TLV MUST be included		CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included
	in the Notify message along with the Long Call ID.		in the Notify message along with the Long Call ID.
	Short Call ID processing, including those procedures related to call		Short Call ID processing, including those procedures related to call
	and connection processing, is not modified by this document and MUST		and connection processing, is not modified by this document and MUST
	proceed according to [RFC4974].		proceed according to [RFC4974].
	An LSP_ATTRIBUTES object containing an Endpoint ID TLV MAY be		A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be
	included in the signaling messages of an LSP (connection) associated		included in the signaling messages of an LSP (connection) associated
	with an established call. Such objects are processed according to		with an established call. Such objects are processed according to
	[RFC4420].		[4420BIS].
	Transit nodes supporting this document MUST propagate the Endpoint ID		Transit nodes supporting this document MUST propagate the Endpoint ID
	TLV without modification.		TLV without modification.
	2.2. Connection Identification		2.2. Connection Identification
	Signaling for Ethernet connections follows the procedures defined in		Signaling for Ethernet connections follows the procedures defined in
	[RFC4974]. In particular the Call related mechanisms are reused to		[RFC4974]. In particular the Call related mechanisms are reused to
	support endpoint identification. In the context of Ethernet		support endpoint identification. In the context of Ethernet
	connections, a call only exists when one or more LSPs (connections in		connections, a call only exists when one or more LSPs (connections in
	skipping to change at page 7, line 38		skipping to change at page 7, line 37
	establish a Call per the procedures defined in [RFC4974]. LSP		establish a Call per the procedures defined in [RFC4974]. LSP
	management, including removal and addition, then follows [RFC4974].		management, including removal and addition, then follows [RFC4974].
	As stated in [RFC4974], once a Call is established the initiator		As stated in [RFC4974], once a Call is established the initiator
	SHOULD establish at least one Ethernet LSP. Also, when the last LSP		SHOULD establish at least one Ethernet LSP. Also, when the last LSP
	associated with a Call is removed, the Call SHOULD be torn down per		associated with a Call is removed, the Call SHOULD be torn down per
	the procedures in [RFC4974].		the procedures in [RFC4974].
	2.3. Traffic Parameters		2.3. Traffic Parameters
	Several types of service attributes are carried in the traffic		Several types of service attributes are carried in the traffic
	parameters defined in [MEF-TRAFFIC]. These parameters are carried in		parameters defined in [ETH-TRAFFIC]. These parameters are carried in
	the FLOWSPEC and TSPEC objects as discussed in [MEF-TRAFFIC]. The		the FLOWSPEC and TSPEC objects as discussed in [ETH-TRAFFIC]. The
	service attributes that are carried are:		service attributes that are carried are:
	- Bandwidth Profile		- Bandwidth Profile
	- VLAN CoS Preservation		- VLAN CoS Preservation
	- Layer Two (L2) Control Protocol Processing (see Section 2.3.1)		- Layer Two (L2) Control Protocol Processing (see Section 2.3.1)
	Ethernet connections established according to this document MUST use		Ethernet connections established according to this document MUST use
	the traffic parameters defined in [MEF-TRAFFIC] in the FLOWSPEC and		the traffic parameters defined in [ETH-TRAFFIC] in the FLOWSPEC and
	TSPEC objects.		TSPEC objects. Additionally, the Switching Granularity field of the
			Ethernet SENDER_TSPEC object MUST be set to zero (0).
	2.3.1. L2 Control Protocol TLV		2.3.1. L2 Control Protocol TLV
	[MEF10.1], [8011.1] and [8011.2] define service attributes that		[MEF10.1], [8011.1] and [8011.2] define service attributes that
	impact the layer two (L2) control protocol processing at the ingress		impact the layer two (L2) control protocol processing at the ingress
	and egress. [MEF-TRAFFIC] does not define support for these service		and egress. [ETH-TRAFFIC] does not define support for these service
	attributes, but does allow the attributes to be carried in a TLV.		attributes, but does allow the attributes to be carried in a TLV.
	This section defines the L2 Control Protocol (L2CP) TLV to carry the		This section defines the L2 Control Protocol (L2CP) TLV to carry the
	L2 control protocol processing related service attributes.		L2 control protocol processing related service attributes.
	The format of the L2 Control Protocol (L2CP) TLV is as follows:		The format of the L2 Control Protocol (L2CP) TLV is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=2 | Length=4 |		| Type=3 | Length=8 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IL2CP | EL2CP | Reserved |		| IL2CP | EL2CP | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [MEF-TRAFFIC] for a description of the Type and Length fields.		See [ETH-TRAFFIC] for a description of the Type and Length fields.
	Per [MEF-TRAFFIC], the Type field MUST be set to two (2), and the		Per [ETH-TRAFFIC], the Type field MUST be set to two (2), and the
	Length field MUST be set to four (4) for the L2CP TLV.		Length field MUST be set to eight (8) for the L2CP TLV.
	Ingress Layer 2 Control Processing (IL2CP): 4 bits		Ingress Layer 2 Control Processing (IL2CP): 4 bits
	This field controls processing of Layer 2 Control Protocols		This field controls processing of Layer 2 Control Protocols
	on a receiving interface. Valid usage is service specific,		on a receiving interface. Valid usage is service specific,
	see [MEF10.1], [8011.1] and [8011.2].		see [MEF10.1], [8011.1] and [8011.2].
	Permitted values are:		Permitted values are:
	Value Description Reference		Value Description Reference
	skipping to change at page 9, line 22		skipping to change at page 9, line 22
	3 None [8011.1] and [8011.2]		3 None [8011.1] and [8011.2]
	4 Reserved		4 Reserved
	Reserved: 24 bits		Reserved: 24 bits
	This field is reserved. It MUST be set to zero on transmission		This field is reserved. It MUST be set to zero on transmission
	and MUST be ignored on receipt. This field SHOULD be passed		and MUST be ignored on receipt. This field SHOULD be passed
	unmodified by transit nodes.		unmodified by transit nodes.
	Ethernet connections established according to this document MUST		Ethernet connections established according to this document MUST
	include the L2CP TLV in the [MEF-TRAFFIC] traffic parameters carried		include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried
	in the FLOWSPEC and TSPEC objects.		in the FLOWSPEC and TSPEC objects.
	2.4. Bundling and VLAN Identification		2.4. Bundling and VLAN Identification
	The control of bundling and listing of VLAN identifiers is only		The control of bundling and listing of VLAN identifiers is only
	supported for EVPL services. EVPL service specific details are		supported for EVPL services. EVPL service specific details are
	provided in Section 4.		provided in Section 4.
	3. EPL Service		3. EPL Service
	skipping to change at page 13, line 5		skipping to change at page 13, line 5
	5. Generic GMPLS Extensions		5. Generic GMPLS Extensions
	This section presents extensions to GMPLS that, while motivated by		This section presents extensions to GMPLS that, while motivated by
	EPL and EVPL service, are generic in nature and may be useful to any		EPL and EVPL service, are generic in nature and may be useful to any
	switching technology controlled via GMPLS.		switching technology controlled via GMPLS.
	[AUTHORS' NOTE: The extensions presented in this section and may be		[AUTHORS' NOTE: The extensions presented in this section and may be
	split into one or more independent documents as this work		split into one or more independent documents as this work
	progresses.]		progresses.]
	5.1. Notify Message Format		5.1. Data Channel Switching
	The Notify message format is extended based on the format defined in
	[RFC4974] to allow for the use of the LSP_ATTRIBUTES object as
	defined in this document. The inclusion of an LSP_ATTRIBUTES object
	in Notify messages is optional. When present, the LSP_ATTRIBUTES
	object SHOULD follow the SESSION_ATTRIBUTE object.
	The format of the Notify Message is updated as follows:
	<Notify message> ::= see [RFC4974]
	<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
	[ <POLICY_DATA> ...]
	[ <LINK_CAPABILITY> ]
	[ <SESSION_ATTRIBUTE> ]
	[ <LSP_ATTRIBUTES> ]
	[ <sender descriptor> | <flow descriptor> ]
	<sender descriptor> ::= see [RFC3473]
	<flow descriptor> ::= see [RFC3473]
	5.2. Data Channel Switching
	Current GMPLS switching types are defined in [RFC3945] and [RFC3471]		Current GMPLS switching types are defined in [RFC3945] and [RFC3471]
	and support switching at the packet (PSC), frame (L2SC), time-slot		and support switching at the packet (PSC), frame (L2SC), time-slot
	(TDM), frequency (LSC) and fiber (FSC) granularities. One type of		(TDM), frequency (LSC) and fiber (FSC) granularities. One type of
	switching that is not well represented in this current set switching		switching that is not well represented in this current set switching
	that takes all data received on an ingress port and switches it		that takes all data received on an ingress port and switches it
	through a network to an egress port. While there are similarities		through a network to an egress port. While there are similarities
	between this level of switching and the "opaque single wavelength"		between this level of switching and the "opaque single wavelength"
	case described in Section 3.5 of [RFC4202], such port-to-port		case described in Section 3.5 of [RFC4202], such port-to-port
	switching is not limited to the optical switching technology implied		switching is not limited to the optical switching technology implied
	skipping to change at page 14, line 11		skipping to change at page 13, line 35
	digital channel are included. Examples include concatenated TDM and		digital channel are included. Examples include concatenated TDM and
	line encoded interfaces. Framed interfaces may also be included when		line encoded interfaces. Framed interfaces may also be included when
	they support switching on an interface granularity.		they support switching on an interface granularity.
	DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the		DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the
	value TBA (by IANA).		value TBA (by IANA).
	Port labels, as defined in [RFC3471], SHOULD be used for LSPs		Port labels, as defined in [RFC3471], SHOULD be used for LSPs
	signaled using the DCSC Switching Type.		signaled using the DCSC Switching Type.
	5.3. Generalized Channel_Set Label Related Formats		5.2. Generalized Channel_Set Label Related Formats
	This section defines a new type of generalized label and updates		This section defines a new type of generalized label and updates
	related objects. This section updates the label related definitions		related objects. This section updates the label related definitions
	of [RFC3473]. The ability to communicate more than one label as part		of [RFC3473]. The ability to communicate more than one label as part
	of the same LSP was motivated by the support for the communication of		of the same LSP was motivated by the support for the communication of
	one or more VLAN IDs, but the formats defined in this section are not		one or more VLAN IDs, but the formats defined in this section are not
	technology specific and may be useful for other switching		technology specific and may be useful for other switching
	technologies.		technologies.
	5.3.1. Generalized Channel_Set LABEL_REQUEST Object		5.2.1. Generalized Channel_Set LABEL_REQUEST Object
	The Generalized Channel_Set LABEL_REQUEST object is used to indicate		The Generalized Channel_Set LABEL_REQUEST object is used to indicate
	that the Generalized Channel_Set LABEL Object is to be used with the		that the Generalized Channel_Set LABEL Object is to be used with the
	associated LSP. The format of the Generalized Channel_Set		associated LSP. The format of the Generalized Channel_Set
	LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST		LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST
	object and uses of C-Type of TBA.		object and uses of C-Type of TBA.
	5.3.2. Generalized Channel_Set LABEL Object		5.2.2. Generalized Channel_Set LABEL Object
	The Generalized Channel_Set LABEL Object communicates one or more		The Generalized Channel_Set LABEL Object communicates one or more
	labels, all of which can be used equivalently in the data path		labels, all of which can be used equivalently in the data path
	associated with a single LSP. The format of the Generalized		associated with a single LSP. The format of the Generalized
	Channel_Set LABEL Object is based on the LABEL_SET object defined in		Channel_Set LABEL Object is based on the LABEL_SET object defined in
	[RFC3473]. It differs from the the LABEL_SET object in that the full		[RFC3473]. It differs from the the LABEL_SET object in that the full
	set may be represented in a single object rather than the multiple		set may be represented in a single object rather than the multiple
	objects required by the [RFC3473] LABEL_SET object. The object MUST		objects required by the [RFC3473] LABEL_SET object. The object MUST
	be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST		be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST
	object. The object MUST be processed per [RFC3473]. Make-before-		object. The object MUST be processed per [RFC3473]. Make-before-
	break procedures, see [RFC3209], SHOULD be used when modifying the		break procedures, see [RFC3209], SHOULD be used when modifying the
	Channel_Set LABEL object.		Channel_Set LABEL object.
	The format of the Generalized Channel_Set LABEL object is:		The format of the Generalized Channel_Set LABEL object is:
			o eneralized Channel_Set LABEL object: Class = 16, C-Type = TBA (By
			IANA)
	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 (16)| C-Type (TBA) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Channel_Set Sub-Object 1 |		| Channel_Set Sub-Object 1 |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: : :		: : :
	: : :		: : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Channel_Set Sub-Object N |		| Channel_Set Sub-Object N |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Channel_Set Sub-Object size is measured in bytes and MUST always		The Channel_Set Sub-Object size is measured in bytes and MUST always
	be a multiple of 4, and at least 4, and has the following format:		be a multiple of 4, and at least 4, and has the following 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Action | Num Subchannels | Label Type |		| Action | Num Subchannels | Label Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subchannel 1 |		| Subchannel 1 |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 17, line 5		skipping to change at page 16, line 32
	The Padding field MUST be included when the number of bits		The Padding field MUST be included when the number of bits
	represented in all the Subchannel fields included in a		represented in all the Subchannel fields included in a
	Generalized Channel_Set Sub-Object result in the Sub-Object not		Generalized Channel_Set Sub-Object result in the Sub-Object not
	being 32 bit aligned. When present, the Padding field MUST		being 32 bit aligned. When present, the Padding field MUST
	have a length that results in the Sub-Object being 32 bit		have a length that results in the Sub-Object being 32 bit
	aligned. When present, the Padding field MUST be set to a zero		aligned. When present, the Padding field MUST be set to a zero
	(0) value on transmission and MUST be ignored on receipt.		(0) value on transmission and MUST be ignored on receipt.
	These bits SHOULD be passed through unmodified by transit		These bits SHOULD be passed through unmodified by transit
	nodes.		nodes.
	5.3.3. Other Label related Objects		5.2.3. Other Label related Objects
	The previous section introduces a new LABEL object. As such the		The previous section introduces a new LABEL object. As such the
	formats of the other label related objects are also impacted.		formats of the other label related objects are also impacted.
	Processing of these objects is not modified and remain per their		Processing of these objects is not modified and remain per their
	respective specifications. The other label related objects are		respective specifications. The other label related objects are
	defined in [RFC3473] and include:		defined in [RFC3473] and include:
	- SUGGESTED_LABEL object		- SUGGESTED_LABEL object
	- LABEL_SET object		- LABEL_SET object
	- ACCEPTABLE_LABEL_SET object		- ACCEPTABLE_LABEL_SET object
	- UPSTREAM_LABEL object		- UPSTREAM_LABEL object
	- RECOVERY_LABEL object		- RECOVERY_LABEL object
	6. 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 reviewed in this section.		namespaces defined in this document and reviewed in this section.
	6.1. Endpoint ID Attributes TLV		6.1. Endpoint ID Attributes TLV
	Upon approval of this document, the IANA will make the assignment in		Upon approval of this document, the IANA will make the assignment in
	the "Attributes TLV Space" section of the "RSVP TE Parameters"		the "CALL_ATTRIBUTES TLV Space" section of the "RSVP TE Parameters"
	registry located at http://www.iana.org/assignments/rsvp-te-		registry located at http://www.iana.org/assignments/rsvp-te-
	parameters:		parameters:
	Allowed on Allowed on		Type Name Reference
	Type Name LSP_ATTRIBUTES LSP_REQUIRED_ATTRIBUTES Reference		---- ----------- ---------
	---- ----------- -------------- ----------------------- ---------		2* Endpoint ID [This document]
	2* Endpoint ID Yes Yes [This document]
	(*) Suggested value.		(*) Suggested value.
	6.2. Line LSP Encoding		6.2. Line LSP Encoding
	Upon approval of this document, the IANA will make the assignment in		Upon approval of this document, the IANA will make the assignment in
	the "LSP Encoding Types" section of the "GMPLS Signaling Parameters"		the "LSP Encoding Types" section of the "GMPLS Signaling Parameters"
	registry located at http://www.iana.org/assignments/gmpls-sig-		registry located at http://www.iana.org/assignments/gmpls-sig-
	parameters:		parameters:
	skipping to change at page 19, line 18		skipping to change at page 19, line 9
	signaling [RFC3473]. It does not introduce any new signaling		signaling [RFC3473]. It does not introduce any new signaling
	messages, nor change the relationship between LSRs that are adjacent		messages, nor change the relationship between LSRs that are adjacent
	in the control plane. As such, this document introduces no additional		in the control plane. As such, this document introduces no additional
	security considerations. See [RFC3473] for relevant security		security considerations. See [RFC3473] for relevant security
	considerations.		considerations.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic		[ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters,"
	Parameters,"		draft-ietf-ccamp-ethernet-traffic-parameters-05.txt,
	draft-ietf-ccamp-ethernet-traffic-parameters-03.txt,		Work in progress, July 12, 2008.
	Work in progress, November 2007.
			[GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol
			Label Switching (GMPLS) Protocol Extensions for
			Multi-Layer and Multi-Region Networks (MLN/MRN)",
			draft-ietf-ccamp-gmpls-mln-extensions-02.txt,
			Work in progress, July 2008.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," RFC 2119.		Requirement Levels," RFC 2119.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
	Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions		Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
	to RSVP for LSP Tunnels", RFC 3209, December 2001.		to RSVP for LSP Tunnels", RFC 3209, December 2001.
	[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label		[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description",		Switching (GMPLS) Signaling Functional Description",
	skipping to change at page 20, line 5		skipping to change at page 20, line 5
	Switching (GMPLS) Architecture", RFC 3945, October		Switching (GMPLS) Architecture", RFC 3945, October
	2004.		2004.
	[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress		[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
	Control", RFC 4003, February 2005.		Control", RFC 4003, February 2005.
	[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing		[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
	Extensions in Support of Generalized Multi-Protocol		Extensions in Support of Generalized Multi-Protocol
	Label Switching (GMPLS)", RFC 4202, October 2005.		Label Switching (GMPLS)", RFC 4202, October 2005.
	[RFC4420] Farrel, A., et al. "Encoding of Attributes for		[4420BIS] Farrel, A., et al. "Encoding of Attributes for
	Multiprotocol Label Switching (MPLS) Label Switched Path		Multiprotocol Label Switching (MPLS) Label Switched
	(LSP) Establishment Using Resource ReserVation		Path (LSP) Establishment Using Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE)", RFC 4420,		Protocol-Traffic Engineering (RSVP-TE)",
	February 2006.		draft-ietf-ccamp-rfc4420bis-03.txt,
			Work in progress, May 27, 2008,
	[RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS		[RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS
	(GMPLS) RSVP-TE Signaling Extensions in support of Calls",		(GMPLS) RSVP-TE Signaling Extensions in support of Calls",
	RFC 4974, August 2007.		RFC 4974, August 2007.
	8.2. Informative References		8.2. Informative References
	[G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport		[G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport
	Ethernet services framework", August 2004.		Ethernet services framework", August 2004.
	skipping to change at line 975		skipping to change at line 954
	any copyrights, patents or patent applications, or other		any copyrights, patents or patent applications, or other
	proprietary rights that may cover technology that may be required		proprietary rights that may cover technology that may be required
	to implement this standard. Please address the information to the		to implement this standard. Please address the information to the
	IETF at ietf-ipr@ietf.org.		IETF at ietf-ipr@ietf.org.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is provided by the IETF		Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).		Administrative Support Activity (IASA).
	Generated on: Mon Apr 14 18:11:06 EDT 2008		Generated on: Mon Jul 14 12:19:42 EDT 2008
End of changes. 37 change blocks.
	89 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/