draft-ietf-ccamp-gmpls-ethernet-arch-04.txt		draft-ietf-ccamp-gmpls-ethernet-arch-05.txt
	Internet Draft Don Fedyk, Nortel		Internet Draft Don Fedyk, Alcatel-Lucent
	Category: Informational Lou Berger, LabN		Category: Informational Lou Berger, LabN
	Expiration Date: August 13, 2009 Loa Andersson, Ericsson AB		Expiration Date: March 1, 2010 Loa Andersson, Ericsson AB
	February 13, 2009		September 1, 2009
	Generalized Multi-Protocol Label Switching (GMPLS) Ethernet		Generalized Multi-Protocol Label Switching (GMPLS) Ethernet
	Label Switching Architecture and Framework		Label Switching Architecture and Framework
	draft-ietf-ccamp-gmpls-ethernet-arch-04.txt		draft-ietf-ccamp-gmpls-ethernet-arch-05.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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 34		skipping to change at page 1, line 34
	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 13, 2009.		This Internet-Draft will expire on March 1, 2010.
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	There has been significant recent work in increasing the capabilities		There has been significant recent work in increasing the capabilities
	of Ethernet switches and Ethernet forwarding models. As a		of Ethernet switches and Ethernet forwarding models. As a
	consequence, the role of Ethernet is rapidly expanding into		consequence, the role of Ethernet is rapidly expanding into
	"transport networks" that previously were the domain of other		"transport networks" that previously were the domain of other
	technologies such as Synchronous Optical Network (SONET)/Synchronous		technologies such as Synchronous Optical Network (SONET)/Synchronous
	Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and		Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and
	Asynchronous Transfer Mode (ATM). This document defines an		Asynchronous Transfer Mode (ATM). This document defines an
	architecture and framework for a Generalized GMPLS based control		architecture and framework for a Generalized GMPLS based control
	plane for Ethernet in this "transport network" capacity. GMPLS has		plane for Ethernet in this "transport network" capacity. GMPLS has
	already been specified for similar technologies. Some additional		already been specified for similar technologies. Some additional
	extensions to the GMPLS control plane are needed and this document		extensions to the GMPLS control plane are needed and this document
	provides a framework for these extensions.		provides a framework for these extensions.
	Table of Contents		Table of Contents
	1 Introduction .............................................. 4		1 Introduction ........................................... 4
	1.1 Terminology ............................................... 6		1.1 Terminology ............................................ 6
	1.1.1 Concepts .................................................. 6		1.1.1 Concepts ............................................... 6
	1.1.2 Abbreviations and Acronyms ................................ 7		1.1.2 Abbreviations and Acronyms ............................. 8
	2 Background ................................................ 8		2 Background ............................................. 8
	2.1 Ethernet Switching ........................................ 9		2.1 Ethernet Switching ..................................... 9
	2.2 Operations, Administration, and Maintenance (OAM) ......... 11		2.2 Operations, Administration, and Maintenance (OAM) ...... 11
	2.3 Ethernet Switching Characteristics ........................ 12		2.3 Ethernet Switching Characteristics ..................... 12
	3 Framework ................................................. 12		3 Framework .............................................. 12
	4 GMPLS Routing and Addressing Model ........................ 14		4 GMPLS Routing and Addressing Model ..................... 14
	4.1 GMPLS Routing ............................................. 15		4.1 GMPLS Routing .......................................... 15
	4.2 Control Plane Network ..................................... 15		4.2 Control Plane Network .................................. 15
	5 GMPLS Signaling .......................................... 15		5 GMPLS Signaling ........................................ 16
	6 Link Management .......................................... 16		6 Link Management ........................................ 16
	7 Path Computation and Selection ............................ 17		7 Path Computation and Selection ......................... 18
	8 Multiple VLANs ............................................ 18		8 Multiple VLANs ......................................... 18
	9 Security Considerations ................................... 18		9 Security Considerations ................................ 18
	10 IANA Considerations ....................................... 18		10 IANA Considerations .................................... 19
	11 References ................................................ 18		11 References ............................................. 19
	11.1 Normative References ...................................... 18		11.1 Normative References ................................... 19
	11.2 Informative References .................................... 19		11.2 Informative References ................................. 19
	12 Acknowledgments ........................................... 20		12 Acknowledgments ........................................ 21
	13 Author's Addresses ........................................ 21		13 Author's Addresses ..................................... 21
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
	document are to be interpreted as described in [RFC2119].		in this document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	There has been significant recent work in increasing the capabilities		There has been significant recent work in increasing the capabilities
	of Ethernet switches. As a consequence, the role of Ethernet is		of Ethernet switches. As a consequence, the role of Ethernet is
	rapidly expanding into "transport networks" that previously were the		rapidly expanding into "transport networks" that previously were the
	domain of other technologies such as SONET/SDH TDM and ATM. The		domain of other technologies such as SONET/SDH TDM and ATM. The
	evolution and development of Ethernet capabilities in these areas is		evolution and development of Ethernet capabilities in these areas is
	a very active and ongoing process.		a very active and ongoing process.
	Multiple organizations have been active in extending Ethernet		Multiple organizations have been active in extending Ethernet
	technology. This activity has taken place in the Institute of		technology to support transport networks. This activity has taken
	Electrical and Electronics Engineers (IEEE) 802.1 Working Group, the		place in the Institute of Electrical and Electronics Engineers (IEEE)
	International Telecommunication Union (ITU) and the Metro Ethernet		802.1 Working Group, the International Telecommunication Union (ITU)
	Forum (MEF). These groups have been focusing on Ethernet forwarding,		and the Metro Ethernet Forum (MEF). These groups have been focusing
	Ethernet management plane extensions and the Ethernet Spanning Tree		on Ethernet forwarding, Ethernet management plane extensions and the
	Control Plane, but not on an explicitly routed, constraint based		Ethernet Spanning Tree Control Plane, but not on an explicitly
	control plane.		routed, constraint based control plane.
	In the forwarding plane context, extensions have been, or are being,		In the forwarding plane context, extensions have been, or are being,
	defined to support different Ethernet forwarding models, protection		defined to support different transport Ethernet forwarding models,
	modes and service interfaces. Examples of such extensions include		protection modes, and service interfaces. Examples of such
	[802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions allow		extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These
	for greater flexibility in the forwarding plane and, in some cases,		extensions allow for greater flexibility in the Ethernet forwarding
	the extensions allow for a departure from forwarding based on		plane and, in some cases, the extensions allow for a departure from
	Ethernet spanning tree. In the 802.1Qay case, greater flexibility in		forwarding based on Ethernet spanning tree. For example, in the
	forwarding is achieved through the addition of a "provider" address		[802.1Qah] case, greater flexibility in forwarding is achieved
	space.		through the addition of a "provider" address space. [802.1Qay]
			supports the use of provisioning systems and network control
			protocols that explicitly select traffic engineered paths.
	This document provides a framework for GMPLS Ethernet Label switching		This document provides a framework for GMPLS Ethernet Label switching
	(GELS). It will be followed by technology specific documents. GELS		(GELS). GELS will likely require more than one switching type to
	will likely require more than one switching type, and the GMPLS		support the different models, and as the GMPLS procedures that will
	procedures that will need to be changed are dependent on switching,		need to be extended are dependent on switching type, these will be
	and thus will be covered in the technology specific documents.		covered in the technology specific documents.
	In the new provider bridge model developed in the IEEE 802.1ad		In the provider bridge model developed in the IEEE 802.1ad project
	project and amended to the IEEE 802.1Q standard [802.1Q], an extra		and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual
	Virtual Local Area Network (VLAN) identifier (VID) is added. This		Local Area Network (VLAN) identifier (VID) is added. This VLAN is
	VLAN is referred to as the Service VID, (S-VID and is carried in a		referred to as the Service VID, (S-VID and is carried in a Service
	Service TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a		TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a backbone
	backbone VID (B-VID) and B-MAC header with a Service Instance (I-TAG)		VID (B-VID) and B-MAC header with a Service Instance (I-TAG)
	encapsulates a customer Ethernet frame or a service Ethernet frame.		encapsulates a customer Ethernet frame or a service Ethernet frame.
	An example of Ethernet protection extensions can be found in
	[G.8031]. In the IEEE 802.1Q standard the terms Provider Backbone
	Bridges (PBB) and Provider Backbone Bridged Network (PBBN) is used in
	the context of these extensions.
	Ethernet operations, administration, and maintenance (OAM) is another		In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB)
	important area that is being extended to enable provider Ethernet		and Provider Backbone Bridged Network (PBBN) are used in the context
	services. Related extensions can be found in [802.1ag] and [Y.1731].		of these extensions.
	An Ethernet based service model is also being defined within the		An example of Ethernet protection extensions can be found in
	context of the Metro Ethernet Forum (MEF) and International		[G.8031]. Ethernet operations, administration, and maintenance (OAM)
	Telecommunication Union (ITU). [MEF.6] and [G.8011] provide parallel		is another important area that is being extended to enable provider
	frameworks for defining network-oriented characteristics of Ethernet		Ethernet services. Related extensions can be found in [802.1ag] and
	services in transport networks. The framework discusses general		[Y.1731].
			An Ethernet based service model is being defined within the context
			of the Metro Ethernet Forum (MEF) and International Telecommunication
			Union (ITU). [MEF.6] and [G.8011] provide parallel frameworks for
			defining network-oriented characteristics of Ethernet services in
			transport networks. These framework documents discuss general
	Ethernet connection characteristics, Ethernet User-Network Interfaces		Ethernet connection characteristics, Ethernet User-Network Interfaces
	(UNIs) and Ethernet Network-Network Interfaces (NNIs). Within this		(UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1]
	framework, [G.8011.1] defines the Ethernet Private Line (EPL) service		defines the Ethernet Private Line (EPL) service and [G.8011.2]
	and [G.8011.2] defines the Ethernet Virtual Private Line (EVPL)		defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6]
	service. [MEF.6] covers both service types. These activities are		covers both service types. These activities are consistent with the
	consistent with the types of Ethernet switching defined in [802.1ah].		types of Ethernet switching defined in [802.1ah].
	The Ethernet forwarding and management plane extensions explicitly		The Ethernet forwarding and management plane extensions allow for the
	allow for the disabling of standard Ethernet spanning tree but do not		disabling of standard Ethernet spanning tree but do not define an
	define an explicitly routed, constraint based control plane. The		explicitly routed, constraint based control plane. For example
	IEEE 802.1, in [802.1Qay], works on an new amendment that explicitly		[802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for
	allows for traffic engineering of Ethernet forwarding paths.		traffic engineering of Ethernet forwarding paths.
	The IETF chartered the GMPLS work to specify a common control plane		The IETF's GMPLS work provides a common control plane for different
	for physical path and core tunneling technologies for the Internet		data plane technologies for Internet and telecommunication service
	and telecommunication service providers. The GMPLS architecture is		providers. The GMPLS architecture is specified in RFC3945 [RFC3945].
	specified in RFC3945 [RFC3945]. The protocols specified for GMPLS		The protocols specified for GMPLS can be used to control "Transport
	have been used to control "Transport Networks", e.g. Optical and TDM		Network" technologies, e.g. Optical and TDM networks. GMPLS can also
	networks.		be used for packet and Layer 2 Switching (frame/cell based networks.
	This document provides a framework for use of GMPLS to control		This document provides a framework for use of GMPLS to control
	"transport" Ethernet. The GMPLS architecture already handles a number		"transport" Ethernet Label Switched Paths (Eth-LSP). Transport
	of transport technologies but "transport" Ethernet adds a few new		Ethernet adds new constraints which require it to be distinguished
	constraints that must be documented. Some additional extensions to		from the previously specified technologies for GMPLS. Some additional
	the GMPLS control plane are needed and this document provides a		extensions to the GMPLS control plane are needed and this document
	framework for these extensions. All extensions to support Eth-LSPs		provides a framework for these extensions. All extensions to support
	are also expected to build on the GMPLS Architecture and related		Eth-LSPs will build on the GMPLS architecture and related
	specifications.		specifications.
	This document introduces and explains GMPLS control plane deployment		This document introduces and explains GMPLS control plane use for
	for Ethernet and the concept of the Ethernet Label Switched Path		transport Ethernet and the concept of the Ethernet Label Switched
	(Eth-LSP). The data plane aspects of Eth-LSPs are outside the scope		Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the
	of this document and IETF activities.		scope of this document and IETF activities.
	The intent of this document is to reuse and align with as much of the		The intent of this document is to reuse and align with as much of the
	GMPLS protocols as possible. For example reusing the IP control		GMPLS protocols as possible. For example, reusing the IP control
	plane addressing allows existing signaling, routing, LMP and path		plane addressing allows existing signaling, routing, LMP and path
	computation to be used as specified. The GMPLS protocols support a		computation to be used as specified. The GMPLS protocols support
	set of tools for hierarchical LSPs as well as contiguous LSPs. GMPLS		hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol
	specific protocol mechanisms support a variety of networks from peer		mechanisms support a variety of networks from peer to peer to UNIs
	to peer to UNIs and NNIs. Additions to existing GMPLS capabilities		and NNIs. Additions to existing GMPLS capabilities will only be made
	will only be made to accommodate features unique to "transport"		to accommodate features unique to transport Ethernet.
	Ethernet.
	1.1. Terminology		1.1. Terminology
	1.1.1. Concepts		1.1.1. Concepts
	The following are basic Ethernet and GMPLS terms:		The following are basic Ethernet and GMPLS terms:
	o Asymmetric Bandwidth		o Asymmetric Bandwidth
	This term refers to a property of a Bidirectional service		This term refers to a property of a Bidirectional service
	skipping to change at page 6, line 37		skipping to change at page 6, line 41
	o Bidirectional Congruent LSP		o Bidirectional Congruent LSP
	This term refers to the property of a bi-directional LSP that		This term refers to the property of a bi-directional LSP that
	uses only the same nodes, ports, and links in both directions.		uses only the same nodes, ports, and links in both directions.
	Ethernet data planes are normally bi-directional or reverse path		Ethernet data planes are normally bi-directional or reverse path
	congruent.		congruent.
	o Contiguous Eth-LSP		o Contiguous Eth-LSP
	A contiguous Eth-LSP is an Eth-LSP that maps one to one with an		A contiguous Eth-LSP is an Eth-LSP that maps one to one with an
	another LSP at a VLAN boundary. Stitched LSP are contiguous LSPs.		another LSP at a VLAN boundary. Stitched LSPs are contiguous
			LSPs.
	o Eth-LSP		o Eth-LSP
	This term refers to Ethernet switched paths that may be		This term refers to Ethernet switched paths that may be
	controlled via GMPLS.		controlled via GMPLS.
	o Hierarchical Eth-LSP		o Hierarchical Eth-LSP
	Hierarchical Eth-LSPs aggregate Eth-LSPs by creating a hierarchy		Hierarchical Eth-LSPs aggregate Eth-LSPs by creating a hierarchy
	of Eth-LSPs.		of Eth-LSPs.
	skipping to change at page 9, line 40		skipping to change at page 9, line 40
	_.-' ``-.._		_.-' ``-.._
	_.-' `-..		_.-' `-..
	many-to-one all-to-one		many-to-one all-to-one
	|		|
	|		|
	|		|
	Transparent		Transparent
	Figure 1: Ethernet Switching Service Types		Figure 1: Ethernet Switching Service Types
	The types are defined in Clause 25 of [802.1ah], and are consistent		The switching types are defined in Clause 25 of [802.1ah]. While not
	with the definitions of Ethernet services supported in [G.8011] and		specifically described in [802.1ah], the Ethernet services being
	[MEF.6]. To summarize the definitions:		defined in the context of [MEF.6] and [G.8011] also fall into the
			types defined in Figure 1 (with the exception of the newly defined I-
			tagged service type).
			[802.1ah] defines a new I-tagged service type but does not
			specifically define the Ethernet services being defined in the
			context of [MEF.6] and [G.8011] which are also illustrated in Figure
			1.
			To summarize the definitions:
	o Port based		o Port based
	This is a frame based service that supports specific frame types,		This is a frame based service that supports specific frame types,
	no Service VLAN tagging, with MAC address based switching.		no Service VLAN tagging, with MAC address based switching.
	o S-tagged		o S-tagged
	There are multiple Service VLAN tag (S-tag) aware services,		There are multiple Service VLAN tag (S-tag) aware services,
	including:		including:
	+ one-to-one		+ one-to-one
	skipping to change at page 10, line 37		skipping to change at page 10, line 47
	markings as well as some other fields. An I-Tagged service is		markings as well as some other fields. An I-Tagged service is
	typically between the edges of the PBBN and terminated at each edge		typically between the edges of the PBBN and terminated at each edge
	on an I-component that faces a customer port so the service is		on an I-component that faces a customer port so the service is
	often not visible except at the edges. However, since the I-		often not visible except at the edges. However, since the I-
	component relay involves a distinct relay, it is possible to have a		component relay involves a distinct relay, it is possible to have a
	visible I-Tagged Service by separating the I component relay from		visible I-Tagged Service by separating the I component relay from
	the B-component relay. Two examples where it makes sense to do		the B-component relay. Two examples where it makes sense to do
	this are: an I-Tagged service between two PBBNs and as an		this are: an I-Tagged service between two PBBNs and as an
	attachment to a customer's Provider Instance Port.		attachment to a customer's Provider Instance Port.
	In general, the different switching type determines which of the		In general, the different switching types determine which of the
	Ethernet header fields are used in the forwarding/switching function,		Ethernet header fields are used in the forwarding/switching function,
	e.g. VID only or VID and DMACs. The switching type may also require		e.g. VID only or VID and DMACs. The switching type may also require
	the use of additional Ethernet headers or fields. Services defined		the use of additional Ethernet headers or fields. Services defined
	for UNIs tend to use the headers on a hop-by-hop basis.		for UNIs tend to use the headers for requesting service (service
			delimiter) and are relevant between the customer site and network
			edge.
	In most bridging cases, the header fields cannot be changed hop-by-		In most bridging cases, the header fields cannot be changed, but some
	hop, but some translations of VID field values are permitted,		translations of VID field values are permitted, typically at the
	typically at the edges. While not specifically described in		network edges.
	[802.1ah], the Ethernet services being defined in the context of
	[MEF.6] and [G.8011] also fall into the types defined in Figure 1.
	Across all service types, the Ethernet data plane is bi-directional		Across all service types, the Ethernet data plane is bi-directional
	congruent. This means that the forward and reverse paths share the		congruent. This means that the forward and reverse paths share the
	exact same set of nodes, ports and bi-directional links. This		exact same set of nodes, ports and bi-directional links. This
	property is fundamental. The 802.1 group has maintained this bi-		property is fundamental. The 802.1 group has maintained this bi-
	directional congruent property in the definition of Connectivity		directional congruent property in the definition of Connectivity
	Fault Management (CFM) which is part of the overall Operations		Fault Management (CFM) which is part of the overall Operations
	Administration and Management (OAM) capability.		Administration and Management (OAM) capability.
	2.2. Operations, Administration, and Maintenance (OAM)		2.2. Operations, Administration, and Maintenance (OAM)
	Robustness is enhanced with the addition of data plane OAM to provide		Robustness is enhanced with the addition of data plane OAM to provide
	both fault and performance management.		both fault and performance management.
	Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane		Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane
	forwarding for both directions. Determining a broken path or		forwarding for both directions. Determining a broken path or
	misdirected packet in this case relies on OAM following the Eth-LSP.		misdirected packet in this case relies on OAM following the Eth-LSP.
	These identifiers are dependent on the data plane so it works equally		These OAM message identifiers are dependent on the data plane so they
	well for provisioned or GMPLS controlled paths.		work equally well for provisioned or GMPLS controlled paths.
	Ethernet OAM currently consists of:		Ethernet OAM currently consists of:
	Defined in both [802.1ag & Y.1731]:		Defined in both [802.1ag & Y.1731]:
	- CCM/RDI: Connectivity Check, Remote Defect Indication		- CCM/RDI: Connectivity Check, Remote Defect Indication
	- LBM/LBR: Loopback Message, Loopback Reply		- LBM/LBR: Loopback Message, Loopback Reply
	- LTM/LTR: Link trace Message, Link trace Reply		- LTM/LTR: Link trace Message, Link trace Reply
	- VSM/VSR: Vendor-specific extensions Message/Reply		- VSM/VSR: Vendor-specific extensions Message/Reply
	Additionally defined in [Y.1731]:		Additionally defined in [Y.1731]:
	- AIS: Alarm Indication Signal		- AIS: Alarm Indication Signal
	- LCK: Locked Signal		- LCK: Locked Signal
	- TST: Test		- TST: Test
	- LMM/LMR: Loss Measurement Message/Reply		- LMM/LMR: Loss Measurement Message/Reply
	- DM/DMM/DMR: Delay Measurement		- DM/DMM/DMR: Delay Measurement
	- EXM/EXR: Experimental		- EXM/EXR: Experimental
	- APS, MCC: Automatic Protection Switching, Maintenance		- APS, MCC: Automatic Protection Switching, Maintenance
	Communication Channel		Communication Channel
	With some Eth-LSP label formats bi-directional transactions (e.g.		These functions are supported across all the Standardized Eth-LSP
	LBM/LBR) and reverse direction transactions MAY have a different VID		formats.
	for each direction. Both Y.1731 & 802.1ag assumes that bi-
	directional transactions (e.g., LBM/LBR) use the same VID in both
	directions. However in some scenarios, especially with explicitly
	routed paths [802.1Qay], it is possible that different VIDs are used
	upstream and downstream. In the context of [802.1Qay] work is ongoing
	to update [802.1ag] to support such scenarios."
	2.3. Ethernet Switching Characteristics		2.3. Ethernet Switching Characteristics
	Ethernet is similar to MPLS it encapsulates many packet and frame		Ethernet is similar to MPLS it encapsulates different packet and
	types for data transmission. In Ethernet the encapsulated data is		frame types for data transmission. In Ethernet, the encapsulated
	referred to as MAC client data. The encapsulation is an Ethernet MAC		data is referred to as MAC client data. The encapsulation is an
	frame with a header, a source address, destination address, optional		Ethernet MAC frame with a header, a source address, destination
	VLAN identifier, Type and length on the front of the MAC client data		address, optional VLAN identifier, Type and length on the front of
	with optional padding and a Frame Check Sequence at the end of the		the MAC client data with optional padding and a Frame Check Sequence
	frame.		at the end of the frame.
	The type of MAC client data is typically identified by an "Ethertype"		The type of MAC client data is typically identified by an "Ethertype"
	value. This is an explicit type indication but Ethernet also supports		value. This is an explicit type indication but Ethernet also supports
	an implicit type indication.		an implicit type indication.
	Ethernet bridging switches Ethernet based on the Frame destination		Ethernet bridging switches Ethernet based on the Frame destination
	address and VLAN. The VLAN identifies an active topology. The		MAC address and VLAN. The VLAN identifies a virtual set of Bridges
	address is assumed to be unique and invariant within the VLAN. MAC		and LANs. The address is assumed to be unique and invariant within
	addresses are often globally unique but this is not necessary for		the VLAN. MAC addresses are often globally unique but this is not
	bridging.		necessary for bridging.
	3. Framework		3. Framework
	As defined in the GMPLS Architecture [RFC3945], the GMPLS control		As defined in the GMPLS Architecture [RFC3945], the GMPLS control
	plane can be applied to a technology by controlling the data plane		plane can be applied to a technology by controlling the data plane
	and switching characteristics of that technology. The architecture		and switching characteristics of that technology. The architecture
	includes a clear separation between a control plane and a data plane.		includes a clear separation between a control plane and a data plane.
	Control plane and data plane separation allows the GMPLS control		Control plane and data plane separation allows the GMPLS control
	plane to remain architecturally and functionally unchanged while		plane to remain architecturally and functionally unchanged while
	controlling different technologies. The architecture also requires		controlling different technologies. The architecture also requires
	skipping to change at page 13, line 12		skipping to change at page 13, line 12
	- bi-directional service;		- bi-directional service;
	- end-to-end and segment protection;		- end-to-end and segment protection;
	- hierarchy		- hierarchy
	The bandwidth profile may be used to set committed information rate,		The bandwidth profile may be used to set committed information rate,
	peak information rate, and policies based on either under-		peak information rate, and policies based on either under-
	subscription or over-subscription. Services covered by this		subscription or over-subscription. Services covered by this
	framework MUST use a TSpec that follows the Ethernet Traffic		framework MUST use a TSpec that follows the Ethernet Traffic
	parameters defined in [ETH-TSPEC].		parameters defined in [ETH-TSPEC].
	In applying GMPLS to "transport" Ethernet, GMPLS may be extended to
	work with the Ethernet data plane and switching functions. The
	definition of GMPLS support for Ethernet is multi-faceted due to the
	different forwarding/switching functions inherent in the different
	service types discussed in Section 2.1. In general, the header fields
	used in the forwarding/switching function, e.g. VID and DMAC, can be
	characterized as a data plane label. In some circumstances these
	fields will be constant along the path of the Eth-LSP, and in others
	they may vary hop-by-hop or at certain interfaces only along the
	path. In the case where the "labels" must be forwarded unchanged,
	there are a few constraints on the label allocation that are similar
	to some other technologies such as lambda labels.
	The GMPLS architecture, per [RFC3945], allowed for control of		The GMPLS architecture, per [RFC3945], allowed for control of
	Ethernet bridges and other layer 2 technologies using the L2SC		Ethernet bridges and other layer 2 technologies using the Layer-2
	switching type. Although, it is worth noting that the control of		Switch Capable (L2SC) switching type. The control of Ethernet
	Ethernet switching was not explicitly defined in [RFC3471], [RFC4202]		switching was not explicitly defined in [RFC3471], [RFC4202] or any
	or any other subsequent GMPLS reference document.		other subsequent GMPLS reference document.
			In applying GMPLS to "transport" Ethernet, GMPLS will need to be
			extended to work with the Ethernet data plane and switching
			functions. The definition of GMPLS support for Ethernet is multi-
			faceted due to the different forwarding/switching functions inherent
			in the different service types discussed in Section 2.1. In general,
			the header fields used in the forwarding/switching function, e.g. VID
			and DMAC, can be characterized as a data plane label. In some
			circumstances these fields will be constant along the path of the
			Eth-LSP, and in others they may vary hop-by-hop or at certain
			interfaces only along the path. In the case where the "labels" must
			be forwarded unchanged, there are a few constraints on the label
			allocation that are similar to some other technologies such as lambda
			labels.
	The characteristics of the "transport" Ethernet data plane are not		The characteristics of the "transport" Ethernet data plane are not
	modified in order to apply GMPLS control. For example, consider the		modified in order to apply GMPLS control. For example, consider the
	IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter"		IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter"
	pointing to a particular forwarding table, and if the DMAC is found		pointing to a particular forwarding table, and if the DMAC is found
	in that forwarding table the forwarding decision is taken based on		in that forwarding table the forwarding decision is taken based on
	the DMAC. When forwarding using an Ethernet spanning tree, if the		the DMAC. When forwarding using an Ethernet spanning tree, if the
	DMAC is not found the frame is broadcast over all outgoing interfaces		DMAC is not found the frame is broadcast over all outgoing interfaces
	for which that VID is defined. This valid MAC checking and broadcast		for which that VID is defined. This valid MAC checking and broadcast
	supports Ethernet learning. A special case is when a VID is defined		supports Ethernet learning. A special case is when a VID is defined
	skipping to change at page 14, line 21		skipping to change at page 14, line 22
	necessary to provide a mechanism to identify the required Ethernet		necessary to provide a mechanism to identify the required Ethernet
	service type in signaling and a way to advertise the capabilities of		service type in signaling and a way to advertise the capabilities of
	Ethernet switches in the routing protocols. These mechanisms must		Ethernet switches in the routing protocols. These mechanisms must
	make it possible to distinguish between requests for different		make it possible to distinguish between requests for different
	paradigms including new, future, and existing paradigms.		paradigms including new, future, and existing paradigms.
	The Switching Type and Interface Switching Capability Descriptor		The Switching Type and Interface Switching Capability Descriptor
	share a common set of values and are defined in [RFC3945], [RFC3471],		share a common set of values and are defined in [RFC3945], [RFC3471],
	and [RFC4202] as indicators of the type of switching that should		and [RFC4202] as indicators of the type of switching that should
	([RFC3471]) and can ([RFC4202]) be performed on a particular link for		([RFC3471]) and can ([RFC4202]) be performed on a particular link for
	an LSP. The L2SC switching type may already be used by		an LSP. Since the L2SC switching type may already be used by
	implementations performing layer 2 switching including Ethernet. To		implementations performing layer 2 switching including Ethernet, to
	support the continued use of that switching type and those		support the continued use of that switching type and those
	implementations, a new switching type MUST be defined for each new		implementations, and to distinguish the different Ethernet switching
			paradigms, a new Ethernet switching type MUST be defined for each new
	Ethernet switching paradigm that is supported.		Ethernet switching paradigm that is supported.
	For discussion purposes, we decompose the problem of applying GMPLS		For discussion purposes, we decompose the problem of applying GMPLS
	into the functions of Routing, Signaling, Link Management and Path		into the functions of Routing, Signaling, Link Management and Path
	Selection. It is possible to use some functions of GMPLS alone or in		Selection. It is possible to use some functions of GMPLS alone or in
	partial combinations. In most cases using all functions of GMPLS		partial combinations. In most cases using all functions of GMPLS
	leads to less operational overhead than partial combinations.		leads to less operational overhead than partial combinations.
	4. GMPLS Routing and Addressing Model		4. GMPLS Routing and Addressing Model
	skipping to change at page 15, line 7		skipping to change at page 15, line 7
	includes support for both numbered and unnumbered interfaces.		includes support for both numbered and unnumbered interfaces.
	In the case where another address family or type of identifier is		In the case where another address family or type of identifier is
	required to support an Ethernet service, extensions may be defined to		required to support an Ethernet service, extensions may be defined to
	provide mapping to an IP address. Support of Ethernet MUST strictly		provide mapping to an IP address. Support of Ethernet MUST strictly
	comply to the GMPLS protocol suite addressing as specific in RFC3471,		comply to the GMPLS protocol suite addressing as specific in RFC3471,
	RFC3473 and related.		RFC3473 and related.
	4.1. GMPLS Routing		4.1. GMPLS Routing
	GMPLS routing as defined in [RFC4202] is IP routing with the opaque		GMPLS routing as defined in [RFC4202] uses IP routing protocols with
	TLV extensions for the purpose of distributing GMPLS related TE		the opaque TLV extensions for the purpose of distributing GMPLS
	(router and link) information. As is always the case with GMPLS, TE		related TE (router and link) information. As is always the case with
	information is populated with TE resources coordinated with LMP or		GMPLS, TE information is populated with TE resources coordinated with
	from configured information. The bandwidth resources of the links are		LMP or from configured information. The bandwidth resources of the
	tracked as Eth-LSPs are set up. Interfaces supporting the switching		links are tracked as Eth-LSPs are set up. Interfaces supporting the
	of Eth-LSPs are identified using the appropriate Interface Switching		switching of Eth-LSPs are identified using the appropriate Interface
	Capabilities. As mentioned in Section 3, the definition of one or		Switching Capabilities Descriptor. As mentioned in Section 3, the
	more new Interface Switching Capabilities to support Eth-LSPs is		definition of one or more new Interface Switching Capabilities to
	expected. The L2SC Interface Switching Capabilities MUST NOT be used		support Eth-LSPs is expected. The L2SC Interface Switching
	to represent interfaces capable of supporting Eth-LSPs. Interface		Capabilities MUST NOT be used to represent interfaces capable of
	Switching Capability specific TE information may be defined as needed		supporting Eth-LSPs defined by this document and subsequent documents
	to support the requirements of a specific Ethernet Switching Service		in support of the transport Ethernet switching paradigms. In
	Type.		addition, Interface Switching Capability specific TE information may
			be defined as needed to support the requirements of a specific
			Ethernet Switching Service Type.
	GMPLS Routing is an optional piece but it is highly valuable in		GMPLS Routing is an optional functionality but it is highly valuable
	maintaining topology and distributing the TE database for path		in maintaining topology and distributing the TE database for path
	management and dynamic path computation.		management and dynamic path computation.
	4.2. Control Plane Network		4.2. Control Plane Network
	In order for a GMPLS control plane to operate, an IP network of		In order for a GMPLS control plane to operate, an IP connectivity
	sufficient capacity to handle the information exchange between the		network of sufficient capacity to handle the information exchange
	GMPLS routing and signaling protocols is necessary.		between the GMPLS routing and signaling protocols is necessary.
	One way to implement this is with an IGP that views each switch as a		One way to implement this is with an IGP that views each switch as a
	terminated IP adjacency. In other words, IP traffic and a simple		terminated IP adjacency. In other words, IP traffic and a simple
	routing table are available for the control plane but there is no		routing table are available for the control plane but there is no
	requirement for a high performance IP data plane.		requirement for needing a high performance IP data plane.
	This IP connectivity can be provided as a separate independent		This IP connectivity can be provided as a separate independent
	network (out of band) or integrated with the Ethernet switches (in-		network (out of band) or integrated with the Ethernet switches (in-
	band).		band).
	5. GMPLS Signaling		5. GMPLS Signaling
	GMPLS signaling, see [RFC3471][RFC3473], is well suited to the		GMPLS signaling, see [RFC3471][RFC3473], is well suited to the
	control of Eth-LSPs and Ethernet switches. Signaling enables the		control of Eth-LSPs and Ethernet switches. Signaling enables the
	ability to dynamically establish a path from an ingress node to an		ability to dynamically establish a path from an ingress node to an
	skipping to change at page 16, line 18		skipping to change at page 16, line 28
	GMPLS signaling supports the establishment and control of bi-		GMPLS signaling supports the establishment and control of bi-
	directional and unidirectional data paths. Ethernet is bi-directional		directional and unidirectional data paths. Ethernet is bi-directional
	by nature and the CFM has been built to leverage this. Prior to CFM		by nature and the CFM has been built to leverage this. Prior to CFM
	the emulation of a physical wire and the learning requirements also		the emulation of a physical wire and the learning requirements also
	mandated bi-directional connections. Given this, Eth-LSPs MUST be bi-		mandated bi-directional connections. Given this, Eth-LSPs MUST be bi-
	directional congruent. Eth-LSPs may be either P2P or P2MP (see		directional congruent. Eth-LSPs may be either P2P or P2MP (see
	[RFC4875]). GMPLS signaling also allows for full and partial LSP		[RFC4875]). GMPLS signaling also allows for full and partial LSP
	protection; see [RFC4872] and [RFC4873].		protection; see [RFC4872] and [RFC4873].
	Note that standard GMPLS does not support different bandwidth in each		Note that standard GMPLS does not support different bandwidth in each
	direction of a bi-directional LSP. See [GMPLS-ASYM] if asymmetric		direction of a bi-directional LSP. [GMPLS-ASYM], an Experimental
	bandwidth bi-directional LSPs are required.		document, provides procedures if asymmetric bandwidth bi-directional
			LSPs are required.
	6. Link Management		6. Link Management
	Link discovery has been specified for Ethernet in [802.1AB]. However		Link discovery has been specified for Ethernet in [802.1AB]. The
	the 802.1AB capability is an optional feature, is not necessarily		benefits of running link discovery in large systems are significant.
	operating before a link is operational, and it primarily supports the		Link discovery may reduce configuration and reduce the possibility of
	management plane. The benefits of running link discovery in large		undetected errors in configuration as well as exposing
	systems are significant. Link discovery may reduce configuration and		misconnections. However the 802.1AB capability is an optional
	reduce the possibility of undetected errors in configuration as well		feature, it is not necessarily operating before a link is
	as exposing misconnections.		operational, and it primarily supports the management plane.
	In the GMPLS context, LMP [RFC4204] has been defined to support link		In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS
	management and discovery features. LMP also supports the automated		control plane link management and discovery features. LMP also
	creation of unnumbered interfaces. If LMP is not used there is an		supports for the control plane the automated creation of unnumbered
	additional configuration requirement to add GMPLS link identifiers.		interfaces. If LMP is not used there is an additional configuration
	For large-scale implementations LMP would be beneficial. LMP also has		requirement for GMPLS link identifiers. For large-scale
	fault management capabilities that overlap with CFM [802.1ag] and		implementations LMP is beneficial. LMP also has optional fault
	[Y.1731]. It is the goal of the architecture to allow the selection		management capabilities, primarily for opaque and transparent network
	of the best tool set for the user needs so full functionality of		technology. With IEEE's newer CFM [802.1ag] and ITU's [Y.1731]
	Ethernet CFM should be allowed.		capabilities, this optional capability may not be needed. It is the
			goal of the GMPLS Ethernet architecture to allow the selection of the
			best tool set for the user
			needs. The full functionality of Ethernet CFM should be supported
			when using a GMPLS control plane.
	LMP and 802.1AB are relatively independent. The LMP capability should		LMP and 802.1AB are relatively independent. The LMP capability should
	be sufficient to remove the need for 802.1AB but 802.1 AB can be run		be sufficient to remove the need for 802.1AB but 802.1 AB can be run
	in parallel or independently if desired. Figure 2 provides possible		in parallel or independently if desired. Figure 2 provides possible
	ways of using LMP, 802.1AB and 802.1ag in combination.		ways of using LMP, 802.1AB and 802.1ag in combination.
	Figure 2 illustrates the functional relationship of link management		Figure 2 illustrates the functional relationship of link management
	and OAM schemes. It is intended that LMP would use functions of		and OAM schemes. It is expected that LMP would be used for control
	link property correlation but that Ethernet mechanisms for OAM such		plane functions of link property correlation but that Ethernet
	as CFM, link trace etc would be used for fault management and fault		mechanisms for OAM such as CFM, link trace etc would be used for data
	trace.		plane fault management and fault trace.
	+-------------+ +-------------+		+-------------+ +-------------+
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | | | | | | |GMPLS		| | | | | | | |GMPLS
	| | LMP |-|<------>|-| LMP | |Link Property		| | LMP |-|<------>|-| LMP | |Link Property
	| | | | | | | |Correlation		| | | | | | | |Correlation
	| | (opt) | |IP | | (opt) | |		| | (opt) | |GMPLS | | (opt) | |
	| | | | | | | | Bundling		| | | | | | | | Bundling
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | | | | | | |		| | | | | | | |
	| | 802.1AB |-|<------>|-| 802.1AB | |P2P		| | 802.1AB |-|<------>|-| 802.1AB | |P2P
	| | (opt) | |Ethernet| | (opt) | |link identifiers		| | (opt) | |Ethernet| | (opt) | |link identifiers
	| | | | | | | |		| | | | | | | |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | | | | | | |End to End		| | | | | | | |End to End
	skipping to change at page 18, line 17		skipping to change at page 18, line 36
	This document allows for the support the signaling of Ethernet		This document allows for the support the signaling of Ethernet
	parameters across multiple VLANs supporting both contiguous Eth-LSP		parameters across multiple VLANs supporting both contiguous Eth-LSP
	and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS		and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS
	hierarchy for the support of Peer to Peer models, UNIs and NNIs.		hierarchy for the support of Peer to Peer models, UNIs and NNIs.
	9. Security Considerations		9. Security Considerations
	The architecture for GMPLS controlled "transport" Ethernet assumes		The architecture for GMPLS controlled "transport" Ethernet assumes
	that the network consists of trusted devices, but does not require		that the network consists of trusted devices, but does not require
	that the ports over which a UNI are defined are trusted, nor does		that the ports over which a UNI are defined are trusted, nor does
	equipment connected to these ports need to be trusted. Access to the		equipment connected to these ports trusted. In general, these
	trusted network SHALL only occur through the protocols defined in the		requirements are no different from the security requirements for
	UNI or NNI or through protected management interfaces.		operating any GMPLS network. Access to the trusted network SHALL only
			occur through the protocols defined for the UNI or NNI or through
			protected management interfaces.
	When in-band GMPLS signaling is used for the control plane the		When in-band GMPLS signaling is used for the control plane the
	security of the control plane and the data plane may affect each		security of the control plane and the data plane may affect each
	other. When out-of-band GMPLS signaling is used the control plane		other. When out-of-band GMPLS signaling is used the control plane
	the data plane security is decoupled from the control plane and		the data plane security is decoupled from the control plane and
	therefore the security of the data plane has less impact on overall		therefore the security of the data plane has less impact on overall
	security.		security.
	Where GMPLS is applied to the control of VLAN only, the commonly		Where GMPLS is applied to the control of VLAN only, the commonly
	known techniques for mitigation of Ethernet DOS attacks may be		known techniques for mitigation of Ethernet DOS attacks may be
	required on UNI ports.		required on UNI ports.
	For a more comprehensive discussion on GMPLS security please see the		For a more comprehensive discussion on GMPLS security please see the
	MPLS and GMPLS Security Framework [SECURITY].		MPLS and GMPLS Security Framework [SECURITY]. It is expected that
			solution documents will include a full analysis of the security
			issues that any protocol extensions introduce.
	10. IANA Considerations		10. IANA Considerations
	No new values are specified in this document.		No new values are specified in this document.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 21, line 8		skipping to change at page 21, line 23
	acknowledge the work of these authors of these initial drafts:		acknowledge the work of these authors of these initial drafts:
	Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan,		Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan,
	Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia,		Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia,
	Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar.		Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar.
	George Swallow contributed significantly to this document.		George Swallow contributed significantly to this document.
	13. Author's Addresses		13. Author's Addresses
	Don Fedyk		Don Fedyk
	Nortel Networks		Alcatel-Lucent
	600 Technology Park Drive		Groton, MA, 01450
	Billerica, MA, 01821		Phone: +1-978-467-5645
	Phone: +1-978-288-3041		Email: donald.fedyk@alcatel-lucent.com
	Email: dwfedyk@nortel.com
	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
	Loa Andersson		Loa Andersson
	Ericsson AB		Ericsson AB
	Phone:+46 8 632 77 14		Phone: +46 10 717 52 13
	Email: loa@pi.nu		Email: loa.andersson@ericsson.com
	Generated on: Fri Feb 13 11:56:46 EST 2009		Generated on: Tue Sep 1 11:27:49 EDT 2009
End of changes. 49 change blocks.
	212 lines changed or deleted		230 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/