draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt		draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt
	Internet Draft Don Fedyk, Nortel		Internet Draft Don Fedyk, Alcatel-Lucent
	Category: Standards Track Himanshu Shah, Ciena		Category: Standards Track Himanshu Shah, Force10 Networks
	Expiration Date: August 25, 2009 Nabil Bitar, Verizon		Expiration Date: April 14, 2010 Nabil Bitar, Verizon
	Attila Takacs, Ericsson		Attila Takacs, Ericsson
	February 25, 2009		October 14, 2009
	Generalized Multiprotocol Label Switching (GMPLS) control of		Generalized Multiprotocol Label Switching (GMPLS) control of
	Ethernet PBB-TE		Ethernet PBB-TE
	draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt		draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with the
	the provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79. This document may contain material
			from IETF Documents or IETF Contributions published or made publicly
	This memo provides information for the Internet community. It		available before November 10, 2008. The person(s) controlling the
	does not specify an Internet standard of any kind. Distribution		copyright in some of this material may not have granted the IETF
	of this memo is unlimited.		Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
	By submitting this Internet-Draft, each author represents that any		the person(s) controlling the copyright in such materials, this
	applicable patent or other IPR claims of which he or she is aware		document may not be modified outside the IETF Standards Process, and
	have been or will be disclosed, and any of which he or she becomes		derivative works of it may not be created outside the IETF Standards
	aware will be disclosed, in accordance with BCP 78 and BCP 79.		Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	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.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other		and may be updated, replaced, or obsoleted by other documents at any
	documents at any time. It is inappropriate to use Internet-Drafts		time. It is inappropriate to use Internet-Drafts as reference
	as reference material or to cite them other than as "work in		material or to cite them other than as "work in progress."
	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 25, 2009.		This Internet-Draft will expire on April 14, 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		and restrictions with respect to this document.
	respect to this document.
	Abstract		Abstract
	This specification is complementary to the GMPLS controlled Ethernet		This specification is complementary to the GMPLS Ethernet Label
	architecture document [ARCH] and describes the technology specific		Switching Architecture and Framework [ARCH] and describes the
	aspects of GMPLS control for Provider Backbone Bridge Traffic		technology specific aspects of GMPLS control for Provider Backbone
	Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions		Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary
	and mechanisms are described to establish Ethernet PBB-TE point to		GMPLS extensions and mechanisms are described to establish Ethernet
	point (P2P) and point to multipoint (P2MP) connections. This document		PBB-TE point to point (P2P) and point to multipoint (P2MP)
	supports, but does not modify, the standard IEEE data plane.		connections. This document supports, but does not modify, the
			standard IEEE data plane.
	Table of Contents		Table of Contents
	1 Introduction .............................................. 4		1 Introduction ........................................... 4
	1.1 Co-authors ................................................ 4		1.1 Co-authors ............................................. 4
	2 Terminology ............................................... 5		2 Terminology ............................................ 5
	2.1 PBB-TE and GMPLS Terminology .............................. 5		2.1 PBB-TE and GMPLS Terminology ........................... 5
	3 Creation and Maintenance of PBB-TE paths using GMPLS ...... 6		3 Creation and Maintenance of PBB-TE paths using GMPLS ... 6
	4 Specific Procedures ....................................... 9		3.1 Shared Forwarding ...................................... 9
	4.1 P2P Ethernet LSPs ........................................ 9		3.2 P2P connections procedures for shared forwarding ....... 10
	4.1.1 Shared Forwarding ......................................... 10		4 Specific Procedures .................................... 10
	4.1.2 P2P connections procedures for shared forwarding .......... 11		4.1 P2P Ethernet LSPs ..................................... 10
	4.1.3 P2P Path Maintenance ...................................... 11		4.1.1 P2P Path Maintenance ................................... 12
	4.2 P2MP Ethernet-LSPs ........................................ 12		4.2 P2MP Ethernet-LSPs ..................................... 12
	4.2.1 Maintenance Procedures .................................... 12		4.3 PBB-TE Ethernet Label .................................. 12
	4.3 PBB-TE Ethernet Label ..................................... 12		4.4 Protection Paths ....................................... 13
	4.4 Protection Paths .......................................... 13		4.5 Service Instance Identification ....................... 13
	4.5 Service Instance Identification .......................... 13		5 Error conditions ....................................... 15
	5 Error conditions .......................................... 15		5.1 ESP-VID related errors ............................... 15
	5.1 Invalid ESP-VID value for PBB-TE ......................... 15		5.1.1 Invalid ESP-VID value in the PBB-TE Ethernet Label .... 15
	5.2 Invalid MAC Address ....................................... 15		5.1.2 Allocated ESP-VID range is exhausted .................. 15
	5.3 Switch is not ESP P2MP capable ............................ 15		5.2 Invalid MAC Address .................................... 15
	6 Security Considerations ................................... 15		6 Security Considerations ................................ 16
	7 IANA Considerations ....................................... 16		7 IANA Considerations .................................... 16
	7.1 Error Codes ............................................... 16		8 References ............................................. 16
	8 References ................................................ 16		8.1 Normative References ................................... 16
	8.1 Normative References ...................................... 16		8.2 Informative References ................................. 17
	8.2 Informative References .................................... 16		9 Acknowledgments ........................................ 18
	9 Acknowledgments ........................................... 17		10 Author's Address ....................................... 18
	10 Author's Address .......................................... 17
	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
	The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE)		The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE)
	[IEEE 802.1Qay] standard supports the establishment of explicitly		[IEEE 802.1Qay] standard supports the establishment of explicitly
	routed traffic engineered paths within Provider Backbone Bridged		routed traffic engineered paths within Provider Backbone Bridged
	(PBB) networks. PBB-TE allows disabling: the Spanning Tree Protocol,		(PBB) networks. PBB-TE allows disabling: the Spanning Tree Protocol,
	unknown destination address forwarding and source address learning		unknown destination address forwarding and source address learning
	for administratively selected VLAN Identifiers. With PBB-TE an		for administratively selected VLAN Identifiers. With PBB-TE an
	external provisioning system or control plane can be used to		external provisioning system or control plane can be used to
	configure static entries in the managed objects of bridges and so		configure static entries in the managed objects of bridges and so
	establish traffic engineered paths in the network.		establish traffic engineered paths in the network.
	Generalized MPLS (GMPLS) [RFC3945] is a family of control plane		Generalized MPLS (GMPLS) [RFC3945] is a family of control plane
	protocols designed to operate in connection oriented and traffic		protocols designed to operate in connection oriented and traffic
	engineering transport networks. GMPLS is applicable to a range of		engineering transport networks. GMPLS is applicable to a range of
	network technologies including Layer 2 Switching capable networks		network technologies including Layer 2 Switching capable networks
	(L2SC). The purpose of this document is to specify extensions for a		(L2SC). The purpose of this document is to specify extensions for a
	GMPLS based control plane to manage PBB-TE explicitly routed traffic		GMPLS based control plane to manage PBB-TE explicitly routed traffic
	engineered paths. This draft is complementary to with the GMPLS		engineered paths. This specification is complementary to with the
	Ethernet Label Switching Architecture and Framework [ARCH].		GMPLS Ethernet Label Switching Architecture and Framework [ARCH]
			document.
	1.1. Co-authors		1.1. Co-authors
	This document is the result the a large team of authors and		This document is the result of a large team of authors and
	contributors. The following is a list of the co-authors:		contributors. The following is a list of the co-authors:
	Don Fedyk (Nortel)		Don Fedyk (Alcatel-Lucent)
	David Allan (Nortel)		David Allan (Ericsson)
	Himanshu Shah (Ciena)		Himanshu Shah (Force10 Networks)
	Nabil Bitar (Verizon)		Nabil Bitar (Verizon)
	Attila Takacs (Ericsson)		Attila Takacs (Ericsson)
	Diego Caviglia (Ericsson)		Diego Caviglia (Ericsson)
	Alan McGuire (BT)		Alan McGuire (BT)
	Nurit Sprecher (Nokia Siemens Networks)		Nurit Sprecher (Nokia Siemens Networks)
	Lou Berger (LabN)		Lou Berger (LabN)
	2. Terminology		2. Terminology
	In addition to well understood GMPLS terms, this memo uses		In addition to well understood GMPLS terms, this memo uses
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	- BEB Backbone Edge Bridge		- BEB Backbone Edge Bridge
	- B-MAC Backbone MAC		- B-MAC Backbone MAC
	- B-VID Backbone VLAN ID		- B-VID Backbone VLAN ID
	- B-VLAN Backbone VLAN		- B-VLAN Backbone VLAN
	- CBP Customer Backbone Port		- CBP Customer Backbone Port
	- CCM Continuity Check Message		- CCM Continuity Check Message
	- CNP Customer Network Port		- CNP Customer Network Port
	- C-MAC Customer MAC		- C-MAC Customer MAC
	- C-VID Customer VLAN ID		- C-VID Customer VLAN ID
	- C-VLAN Customer VLAN		- C-VLAN Customer VLAN
	- DMAC Destination MAC Address
	- ESP Ethernet Switched Path		- ESP Ethernet Switched Path
	- ESP-MAC SA ESP Source MAC Address		- ESP-MAC SA ESP Source MAC Address
	- ESP-MAC DA ESP Destination MAC Address		- ESP-MAC DA ESP Destination MAC Address
	- ESP-VID ESP VLAN ID		- ESP-VID ESP VLAN ID
	- Eth-LSP Ethernet Label Switched Path		- Eth-LSP Ethernet Label Switched Path
	- IB-BEB A BEB comprising of both I and B components		- IB-BEB A BEB comprising of both I and B components
	- I-SID Ethernet Service Instance Identifier		- I-SID Ethernet Service Instance Identifier
	- MAC Media Access Control		- MAC Media Access Control
	- MMAC Multicast or Group MAC address
	- PBB Provider Backbone Bridges		- PBB Provider Backbone Bridges
	- PBB-TE Provider Backbone Bridges Traffic Engineering		- PBB-TE Provider Backbone Bridges Traffic Engineering
	- PIP Provider Instance Port		- PIP Provider Instance Port
	- PNP Provider Network Port		- PNP Provider Network Port
	- P2P Point to Point		- P2P Point to Point
	- P2MP Point to Multipoint		- P2MP Point to Multipoint
	- SVL Shared VLAN Learning		- SVL Shared VLAN Learning
	- TESI TE Service Instance		- TESI TE Service Instance
	- VID VLAN ID		- VID VLAN ID
	- VLAN Virtual LAN		- VLAN Virtual LAN
	skipping to change at page 6, line 32		skipping to change at page 6, line 30
	ESPs' endpoints have the same CBP MAC addresses. The two		ESPs' endpoints have the same CBP MAC addresses. The two
	unidirectional ESP are forming a bidirectional service. The PBB-		unidirectional ESP are forming a bidirectional service. The PBB-
	TE standard [IEEE 802.1Qay] notes the following: for reasons		TE standard [IEEE 802.1Qay] notes the following: for reasons
	relating to TE service monitoring diagnostics, operational		relating to TE service monitoring diagnostics, operational
	simplicity, etc. the IEEE PBB-TE standard assumes that the point-		simplicity, etc. the IEEE PBB-TE standard assumes that the point-
	to-point ESPs associated with a point-to-point TESI are co-		to-point ESPs associated with a point-to-point TESI are co-
	routed. Support for a point-to-point TE services which comprises		routed. Support for a point-to-point TE services which comprises
	non co-routed ESPs is problematic, and is not defined in this		non co-routed ESPs is problematic, and is not defined in this
	standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P		standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P
	TE Service instance. We use the term bidirectional Ethernet-LSP		TE Service instance. We use the term bidirectional Ethernet-LSP
	(Eth-LSP) for GMPLS established P2P PBB-TE Service instances.		for GMPLS established P2P PBB-TE Service instances.
	3. Creation and Maintenance of PBB-TE paths using GMPLS		3. Creation and Maintenance of PBB-TE paths using GMPLS
	IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs		IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs
	are created switch by switch by simple configuration of Ethernet		are created switch by switch by simple configuration of Ethernet
	forwarding entries. This document describes the use of GMPLS as a		forwarding entries. This document describes the use of GMPLS as a
	valid control plane for the set-up, teardown, protection and		valid control plane for the set-up, teardown, protection and
	recovery of ESPs and TESIs and specifies the required RSVP-TE		recovery of ESPs and TESIs and specifies the required RSVP-TE
	extensions for the control of PBB-TE service instances.		extensions for the control of PBB-TE service instances.
	skipping to change at page 7, line 18		skipping to change at page 7, line 16
	and use the MAC address of that port. The I-Component encapsulates		and use the MAC address of that port. The I-Component encapsulates
	the service frames arriving from the CNP by adding an I-SID and a		the service frames arriving from the CNP by adding an I-SID and a
	complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The		complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The
	B-Component adds the ESP-VID.		B-Component adds the ESP-VID.
	GMPLS is being defined here to establish ESPs and TESIs. As it can be		GMPLS is being defined here to establish ESPs and TESIs. As it can be
	seen from the above this requires configuration of both the I and B		seen from the above this requires configuration of both the I and B
	components of the IB-BEBs connected by the ESPs.		components of the IB-BEBs connected by the ESPs.
	In the GMPLS control plane TE Router IDs are used to identify the IB-		In the GMPLS control plane TE Router IDs are used to identify the IB-
	BEBs and Backbone Core Bridges (BCBs), and TE Links that describes		BEBs and Backbone Core Bridges (BCBs), and TE Links describe links
	links connected to PNPs and CNPs. TE Links are not associated with		connected to PNPs and CNPs. TE Links are not associated with CBPs or
	CBPs or PIPs.		PIPs.
	Note that since multiple internal CBPs may exit an IB-BEB receiving a		Note that since multiple internal CBPs may exist an IB-BEB receiving
	PATH message must be able to determine the appropriate CBP that is		a PATH message MUST be able to determine the appropriate CBP that is
	the termination point of the ESP. To this end, IB-BEBs SHOULD		the termination point of the Eth-LSP. To this end, IB-BEBs SHOULD
	advertises the CNP TE Links in the GMPLS control plane and RSVP-TE		advertise the CNP TE Links in the GMPLS control plane and RSVP-TE
	signaling SHOULD use the CNP TE Links to identify the termination		signaling SHOULD use the CNP TE Links to identify the termination
	point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one		point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one
	of its CNPs can locally determine which CBPs have internal		of its CNPs can locally determine which CBPs have internal
	connectivity to the I-component supporting the given CNP. In the case		connectivity to the I-component supporting the given CNP. In the case
	there are more than one suitable CBPs, and no I-SID information is		there are more than one suitable CBPs, and no I-SID information is
	provided in the PATH message or previously in the associated Call		provided in the PATH message or previously in the associated Call
	setup, then the IB-BEB can decide freely which CBP to assign to the		setup, then the IB-BEB can decide freely which CBP to assign to the
	requested connection. On the other hand, if there is information on		requested connection. On the other hand, if there is information on
	the service (I-SID) that the given ESP will support, then the IB-BEB		the service (I-SID) that the given ESP will support, then the IB-BEB
	MUST first determine which PIP and CBP is configured with the I-SID		MUST first determine which PIP and CBP is configured with the I-SID
	skipping to change at page 8, line 32		skipping to change at page 8, line 32
	^--------Configured--------------^		^--------Configured--------------^
	^-----------GMPLS or Configured------^		^-----------GMPLS or Configured------^
	Figure 1 IB-BEBs and GMPLS identifiers		Figure 1 IB-BEBs and GMPLS identifiers
	Control TE Router ID TE Router ID		Control TE Router ID TE Router ID
	Plane | (TE Link) |		Plane | (TE Link) |
	V | V		V | V
	+----+ | +-----+		+----+ | +-----+
	Data | | | label=ESP:VID/MAC DA | |		Data | | | | |
	Plane | | V label=ESP:VID/MMAC | |		Plane | | V label=ESP:VID/MAC DA | |
	-----N N----------------------------N N----------		-----N N----------------------------N N----------
	| | PBB-TE | | \ Network		| | PBB-TE | | \ Network
	| | / | Or		| | / | Or
	+----+ /+-----+ Customer		+----+ /+-----+ Customer
	BCB ESP:MAC IB-BEB Facing		BCB ESP:MAC IB-BEB Facing
	Ethernet		Ethernet
	Ports		Ports
	Figure 2 Ethernet/GMPLS Addressing & Label Space		Figure 2 Ethernet/GMPLS Addressing & Label Space
	PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a		PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a
	unique connection identifier in the data plane but the forwarding		unique connection identifier in the data plane but the forwarding
	operation only uses the ESP-MAC DA and the ESP-VID in each direction.		operation only uses the ESP-MAC DA and the ESP-VID in each direction.
	The ESP-VID typically comes from a small number of VIDs dedicated to		The ESP-VID typically comes from a small number of VIDs dedicated to
	PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement		PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement
	that ESP-VIDs for two ESPs that form a P2P TESI be the same.		that ESP-VIDs for two ESPs that form a P2P TESI be the same.
	When configuring a ESP with GMPLS, the ESP-MAC DA and ESP-VID are		When configuring an ESP with GMPLS, the ESP-MAC DA and ESP-VID are
	carried in a generalized label object and are assigned hop by hop but		carried in a generalized label object and are assigned hop by hop but
	are invariant within a domain. This invariance is similar to GMPLS		are invariant within a domain. This invariance is similar to GMPLS
	operation in transparent optical networks. As is typical with other		operation in transparent optical networks. As is typical with other
	technologies controlled by GMPLS, the data plane receiver must		technologies controlled by GMPLS, the data plane receiver MUST
	accept, and usually assigns, labels from its available label pool.		accept, and usually assigns, labels from its available label pool.
	This, together with the label invariance requirement mentioned above,		This, together with the label invariance requirement mentioned above,
	result in each PBB-TE Ethernet Label being a domain wide unique		result in each PBB-TE Ethernet Label being a domain wide unique
	label, with a unique ESP-VID + ESP-MAC DA, for each direction.		label, with a unique ESP-VID + ESP-MAC DA, for each direction.
	The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P		The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P
	TESI.		TESI.
	GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)		GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)
	GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)		GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
	Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)		Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)
	Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)		Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
	Table 1 Labels and ESPs		Table 1 Labels and ESPs
	4. Specific Procedures		3.1. Shared Forwarding
	4.1. P2P Ethernet LSPs
	Note, PBB-TE is designed to be bidirectional and symmetrically routed
	just like Ethernet. That is, complete and proper functionality of
	Ethernet protocols is only guaranteed for bidirectional Eth-LSPs.
	To initiate a bidirectional Eth-LSP, the initiator of the PATH
	message uses procedures outlined in [RFC3473], it:
	1) Sets the LSP encoding type to Ethernet.
	2) Sets the LSP switching type to 802_1 PBB-TE suggested value 40
	[IANA to define].
	3) Sets the GPID to service type.
	4) Sets the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the
	ESP-VID1 is administered locally for the local MAC address: MAC1
	5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to
	influence the choice of ESP-VID/ESP-MAC DA.
	6) Optionally look at Call / Connection ID for Carrying I-SID.
	Intermediate and egress switch processing is not modified by this
	document, i.e., is per [RFC3473]. Note, as previously stated
	intermediate bridges supporting the 802_1 PBB-TE switching type MUST
	NOT modify LABEL values.
	The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL is used
	to create a static forwarding entry in the Filtering Database of
	bridges at each hop for the upstream direction. This behavior is
	inferred from the switching type which is 802_1 PBB-TE. The port
	derived from the RSVP_HOP object and the ESP-VID1 and ESP- MAC1
	included in the PBB-TE Ethernet Label constitute the static entry.
	At the destination, an ESP-VID2 is allocated for the local MAC
	address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL
	object in the RESV message. As with the PATH message, intermediate
	switch processing is per [RFC3473], and the LABEL object is passed on
	unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained in the
	LABEL Object is installed in the forwarding table as a static
	forwarding entry at each hop. This creates a bidirectional path as
	the PATH and RESV messages follow the same path.
	4.1.1. Shared Forwarding
	One capability of a connectionless Ethernet data plane is to reuse		One capability of a connectionless Ethernet data plane is to reuse
	destination forwarding entries for packets from any source within a		destination forwarding entries for packets from any source within a
	VLAN to a destination. When setting up P2P PBB-TE connections for		VLAN to a destination. When setting up P2P PBB-TE connections for
	multiple sources sharing a common destination this capability MAY be		multiple sources sharing a common destination this capability MAY be
	preserved provided certain requirements are met. We refer to this		preserved provided certain requirements are met. We refer to this
	capability as Shared Forwarding. Shared forwarding is invoked based		capability as Shared Forwarding. Shared forwarding is invoked based
	on policy when conditions are met. It is a local decision by label		on policy when conditions are met. It is a local decision by label
	allocation at each end plus the path constraints. Shared forwarding		allocation at each end plus the path constraints. Shared forwarding
	has no impact on the actual paths setup, but it allows the reduction		has no impact on the actual paths that are setup, but it allows the
	of forwarding entries. Shared forwarding paths are identical in		reduction of forwarding entries. Shared forwarding paths are
	function to independently routed paths that share a path from an		identical in function to independently routed paths that share a path
	intersecting switch or link except they share a single forwarding		from an intersecting switch or link except they share a single
	entry.		forwarding entry.
	Share forwarding savings can be quite dramatic in some topologies		The forwarding memory savings from shared forwarding can be quite
	where a high degree of meshing is required however it is typically		dramatic in some topologies where a high degree of meshing is
	easier to achieve when the connectivity is know in advance. Normally		required however it is typically easier to achieve when the
	the originating GMPLS switch will not have knowledge of the set of		connectivity is known in advance. Normally the originating GMPLS
	shared forwarding paths rooted on the source or destination switch.		switch will not have knowledge of the set of shared forwarding paths
			rooted on the source or destination switch.
	Use of a Path Computation Server [PATHCOMP] or other planning style		Use of a Path Computation Server [PATHCOMP] or other planning style
	of tool with more complete knowledge of the network configuration is		of tool with more complete knowledge of the network configuration is
	a way to impose pre-selection of shared forwarding multiplexes to use		a way to impose pre-selection of shared forwarding with multiple
	for both directions. In this scenario the originating switch uses		paths using a single forwarding entry and optimizing for both
	the LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the		directions. In this scenario the originating switch uses the
	shared forwarding multiplexes at both ends.		LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the
			shared forwarding labels at both ends.
	4.1.2. P2P connections procedures for shared forwarding		3.2. P2P connections procedures for shared forwarding
	The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding		The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding
	identifier or label for a multiplex consisting of some number of P2P		identifier or label consisting of some number of P2P connections
	connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP-		distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- MAC SA
	MAC SA tuple. This is analogous to an LDP label merge but in the		tuple. This is analogous to an LDP label merge but in the shared
	shared forwarding case the original ESP header still identifies the		forwarding case the original ESP header still identifies the complete
	complete path. Resources can continue to be allocated per LSP with		path. Resources can continue to be allocated per LSP with Shared
	Shared forwarding.		forwarding.
	VLAN tagged Ethernet packets include priority marking. Priority bits		VLAN tagged Ethernet packets include priority marking. Priority bits
	MAY be used to indicate class of Service (COS) and drop priority.		MAY be used to indicate class of Service (COS) and drop priority.
	Thus, traffic from multiple COSs could be multiplexed on the same		Thus, traffic from multiple COSs could be multiplexed on the same
	Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are		Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are
	made based on the p-bits. This means that the queue selection can be		made based on the p-bits. This means that the queue selection can be
	done based on a per flow (i.e., Eth-LSP + priority) basis and is		done based on a per flow (i.e., Eth-LSP + priority) basis and is
	decoupled from the actual steering of the packet at any given switch.		decoupled from the actual steering of the packet at any given switch.
	A switch terminating an Eth-LSP will frequently have more than one		A switch terminating an Eth-LSP will frequently have more than one
	skipping to change at page 11, line 38		skipping to change at page 10, line 39
	shared forwarding.		shared forwarding.
	The concept of bandwidth management still applies equally well with		The concept of bandwidth management still applies equally well with
	shared forwarding. As an example consider a PBB-TE edge switch that		shared forwarding. As an example consider a PBB-TE edge switch that
	terminates an Ethernet LSP with the following attributes: bandwidth		terminates an Ethernet LSP with the following attributes: bandwidth
	B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an		B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an
	additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D,		additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D,
	ESP-MAC SA S2, ESP-VID V) can be accepted provided there is		ESP-MAC SA S2, ESP-VID V) can be accepted provided there is
	sufficient link capacity remaining.		sufficient link capacity remaining.
	4.1.3. P2P Path Maintenance		4. Specific Procedures
			4.1. P2P Ethernet LSPs
			Note, PBB-TE is designed to be bidirectional and symmetrically routed
			just like Ethernet. That is, complete and proper functionality of
			Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In
			the following we discuss the establishment of bidirectional Eth-LSPs.
			Note however that it is also possible to use RSVP-TE to configure
			unidirectional ESPs, if the UPSTREAM_LABEL is not included in the
			PATH message. To initiate a bidirectional Eth-LSP, the initiator
			of the PATH message MUST use the procedures outlined in [RFC3473]
			with the following specifics:
			1) MUST set the LSP encoding type to Ethernet (2) [RFC3471].
			2) MUST set the LSP switching type to 802_1 PBB-TE suggested value 40
			IANA to define, assigned by this document].
			3) SHOULD set the GPID to Ethernet (33) [RFC3471].
			4) MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where
			the
			ESP-VID1 is administered locally for the local MAC address: MAC1
			5) SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to
			influence the choice of ESP-VID/ESP-MAC DA.
			6) SHOULD look at Call / Connection ID for Carrying I-SID.
			Intermediate and egress switch processing is not modified by this
			document, i.e., is per [RFC3473]. However, as previously stated
			intermediate bridges supporting the 802_1 PBB-TE switching type MUST
			NOT modify LABEL values.
			The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL are used
			to create a static forwarding entry in the Filtering Database of
			bridges at each hop for the upstream direction. This behavior is
			inferred from the switching type which is 802_1 PBB-TE. The port
			derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1
			included in the PBB-TE Ethernet Label constitute the static entry.
			At the destination, an ESP-VID (ESP-VID2) is allocated for the local
			MAC address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL
			object in the RESV message. As with the PATH message, intermediate
			switch processing is per [RFC3473], and the LABEL object MUST be
			passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained
			in the LABEL Object is installed in the forwarding table as a static
			forwarding entry at each hop. This creates a bidirectional Eth-LSP as
			the PATH and RESV messages follow the same path.
			4.1.1. P2P Path Maintenance
	Make before break procedures can be employed to modify the		Make before break procedures can be employed to modify the
	characteristics of a P2P Eth LSP. As described in [RFC3209], the LSP		characteristics of a P2P Eth LSP. As described in [RFC3209], the LSP
	ID in the sender template is updated as the new path is signaled. The		ID in the sender template is updated as the new path is signaled. The
	procedures (including those for shared forwarding) are identical to		procedures (including those for shared forwarding) are identical to
	those employed in establishing a new LSP, with the extended tunnel ID		those employed in establishing a new LSP, with the extended tunnel ID
	in the signaling exchange ensuring that double booking of the		in the signaling exchange ensuring that double booking of an
	associated resources does not occur.		associated resource does not occur.
	Where individual paths in a protection group are modified, signaling		Where individual paths in a protection group are modified, signaling
	procedures may be combined with Protection Switching (PS)		procedures MAY be combined with Protection Switching (PS)
	coordination to administratively force PS switching operations such		coordination to administratively force PS switching operations such
	that modifications are only ever performed on the protection path.		that modification is only ever performed on the protection path.
	4.2. P2MP Ethernet-LSPs		4.2. P2MP Ethernet-LSPs
	PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In P2MP		PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In this
	the whole tree in the forward direction has the same destination MMAC		case the PBB-TE Ethernet Label consists of a VID and a Group MAC
	ESP-MAC-DA.		address. The procedures outlined in [RFC3473] and [RFC4875]could be
			adapted to signal P2MP LSPs for the source (point) to destination
	The procedures outlined in [RFC3473] and [RFC4875]could be adapted to		(multipoint) direction. Each one of the branches of the P2MP Eth-LSP
	signal P2MP LSPs for the source (point) to destination (multipoint)		would be associated with a reverse path symmetric and congruent P2P
	direction. Each one of the branches of the P2MP Eth-LSP would be		Eth-LSP.
	associated with a reverse path symmetric and congruent P2P Eth-LSP.
	Complete procedures for signaling bidirectional P2MP are out of scope		Complete procedures for signaling bidirectional P2MP are out of scope
	for this document.		for this document.
	4.2.1. Maintenance Procedures
	Maintenance and modification to a P2MP tree can be achieved by a
	number of means. The preferred technique is to modify existing VLAN
	configuration vs. assignment of a new label and completely
	constructing a new tree.
	Make before break on a live tree reusing existing label assignments
	requires a 1:1 or 1+1 construct. The protection switch state of the
	traffic is forced on the working tree and locked (PS not allowed)
	while the backup tree is modified. Explicit path tear of leaves to be
	modified is required to ensure no loops are left behind as artifacts
	of tree modification. Once modifications are complete, a forced
	switch to the backup tree occurs and the original tree may be
	similarly modified. This also suggests that 1+1 or 1:1 resilience can
	be achieved for P2MP trees for any single failure (switch on any
	failure and use restoration techniques to repair the failed tree).
	4.3. PBB-TE Ethernet Label		4.3. PBB-TE Ethernet Label
	The PBB-TE Ethernet Label is a new generalized label with the		The PBB-TE Ethernet Label is a new generalized label with the
	following format:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |		|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ESP MAC |		| ESP MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3 PBB-TE Ethernet Label		Figure 3 PBB-TE Ethernet Label
	This format is used to carry for both P2P and P2MP Eth-LSPs. For P2P		This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth-
	Eth-LSPs labels the fields specify a VID and a unicast MAC address,		LSPs the fields specify a VID and a unicast MAC address, while for
	while for P2MP Eth-LSPs a VID and a group MAC address is carried in		P2MP Eth-LSPs a VID and a group MAC address is carried in the label.
	the label. The PBB-TE Ethernet Label is a domain wide unique label		The PBB-TE Ethernet Label is a domain wide unique label and MUST be
	and MUST be passed unchanged at each hop. This has similarity to the		passed unchanged at each hop. This has similarity to the way in which
	way in which a wavelength label is handled at an intermediate switch		a wavelength label is handled at an intermediate switch that cannot
	that cannot perform wavelength conversion, and is described in		perform wavelength conversion, and is described in [RFC3473].
	[RFC3473].
	4.4. Protection Paths		4.4. Protection Paths
	When protection is used for path recovery it is required to associate		When protection is used for path recovery it is required to associate
	the working and protection paths into a protection group. This is		the working and protection paths into a protection group. This is
	achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION		achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION
	and PROTECTION objects.		and PROTECTION objects.
	4.5. Service Instance Identification		4.5. Service Instance Identification
	The I-SID is used to uniquely identify services within the network.		The I-SID is used to uniquely identify services within the network.
	Unambiguous identification is achieved by ensuring global uniqueness		Unambiguous identification is achieved by ensuring global uniqueness
	of the I-SIDs within the network or at least between any pair of edge		of the I-SIDs within the network or at least between any pair of edge
	switches. On IB-BEBs the Backbone Service Instance Table is used to		switches. On IB-BEBs the Backbone Service Instance Table is used to
	configure the mapping between I-SIDs and ESPs. This configuration can		configure the mapping between I-SIDs and ESPs. This configuration can
	be either manual or semi-automated by signaling described here.		be either manual or semi-automated by signaling described here.
	RSVP-TE signaling can be used to automate I-SID to ESP mapping. By		RSVP-TE signaling MAY be used to automate I-SID to ESP mapping. By
	relying on signaling it is ensured that the same I-SID is assigned to		relying on signaling it is ensured that the same I-SID is assigned to
	the service and mapped to the same ESP. Note, by signaling the I-SID		the service and mapped to the same ESP. Note, by signaling the I-SID
	associated to the ESP one can ensure that IB-BEBs select the		associated to the ESP one can ensure that IB-BEBs select the
	appropriate CBP port.		appropriate CBP port.
	The CALL signaling [RFC4974] can be used to create the I-SID		The CALL signaling [RFC4974] can be used to create the I-SID
	association between the endpoints prior to Eth-LSP establishment.		association between the endpoints prior to Eth-LSP establishment.
	Alternatively, the PATH messages can carry the I-SID association at		Alternatively, the PATH messages can carry the I-SID association at
	the time of Eth-LSP signaling. Therefore it is possible to create I-		the time of Eth-LSP signaling. Therefore it is possible to create I-
	SID association either when the path is set up or at a later time.		SID association either when the path is set up or at a later time.
	A new Service ID TLV is defined for the CALL_ATTRIBUTES object. The		A new Service ID TLV is defined for the CALL_ATTRIBUTES and
	format is depicted below.		LSP_ATTRIBUTES objects. The format is depicted below.
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags |		| Reserved | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| I-SID Set 1 |		| I-SID Set 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: : :		: : :
	: : :		: : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| I-SID Set n |		| I-SID Set n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4 Service ID TLV		Figure 4 Service ID TLV
	- Flags: are used to control properties of service configuration.		- Flags: are used to control properties of service configuration.
	This document does not define flags.		This document does not define flags.
	- I-SID Set TLV: is used to define a list or range of I-SIDs.		- I-SID Set TLV(Type 1): is used to define a list or range of I-
	Multiple I-SID Set TLVs can be present. At least one I-SID Set		SIDs. Multiple I-SID Set TLVs can be present. At least one I-SID
	TLV MUST be present. In most of the cases a single I-SID Set with		Set TLV MUST be present. In most of the cases a single I-SID Set
	a single I-SID value is used. The I-SID Set TLV is used to define		with a single I-SID value is used. The I-SID Set TLV is used to
	a list or range of I-SIDs. The format of the I-SID Set TLV is		define a list or range of I-SIDs. The format of the I-SID Set TLV
	based on the LABEL_SET Object:		is based on the LABEL_SET Object:
	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 | Reserved |		| Action | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | I-SID 1 |		| Reserved | I-SID 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: : :		: : :
	: : :		: : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 4		skipping to change at page 14, line 46
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: : :		: : :
	: : :		: : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | I-SID n |		| Reserved | I-SID n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5 I-SID Set TLV		Figure 5 I-SID Set TLV
	- Action: 8 bits		- Action: 8 bits
	The following actions are defined: list (0), range (1).		The following actions are defined: list (0), range (1).
	- I-SID: 24 bits		- I-SID: 24 bits
	The I-SID value identifies a particular backbone service		The I-SID value identifies a particular backbone service
	instance.		instance.
	5. Error conditions		5. Error conditions
	The following errors are possible. They are extension of some base		The following errors identify Eth-LSP specific problems.
	error types that arise due to the constraints on the label.
	5.1. Invalid ESP-VID value for PBB-TE		5.1. ESP-VID related errors
	The originator of the error is not configured to use the ESP-VID		The network operator administratively selects a
	value for PBB-TE in conjunction with GMPLS signaling of <ESP: VID,		set of VLAN Identifiers that can be used to setup ESPs.
	MAC DA > tuples. This may be originated by any switch along the path.		Consequently, any VID outside the allocated range is invalid and an
			error MUST be generated where the mismatch is discovered.
	Note this is a refinement of the more general Unacceptable label		5.1.1. Invalid ESP-VID value in the PBB-TE Ethernet Label
	value Error code.
	5.2. Invalid MAC Address		If a bridge is not configured to use the ESP-VID value, carried in
			the Label object, for PBB-TE ESPs, it MUST immediately generate an
			error: Routing problem (24) / Unacceptable label value (6). Handling
			of this error is according to [RFC3209].
	The MAC address is out of a reserved range that cannot be used by the		Note, this error may be originated by any switch along the path.
	switch which is processing the address. While almost all MAC
	addresses are valid there are a small number of IEEE reserved MAC
	addresses.
	Note this is a refinement of the more general Unacceptable label		5.1.2. Allocated ESP-VID range is exhausted
	value Error code.
	5.3. Switch is not ESP P2MP capable		The destination bridge after receiving the PATH message has to
			allocate a VID, which together with its MAC address will constitute
			the PBB-TE Ethernet Label. Depending on the size of the allocated
			VLAN range and the number of Eth-LSPs terminated on a particular
			bridge, it is possible that the available VIDs are exhausted and
			hence no PBB-TE Ethernet Label can be allocated. In this case the
			destination bridge SHOULD generate a PathErr message with error code:
			Routing problem (24) and error value: PBB-TE Ethernet Label VID
			allocation failure (35?) [the new error sub-code to be allocated by
			IANA]
	This error may arise only in P2MP Tree allocation.		5.2. Invalid MAC Address
			IEEE defines a set of reserved MAC addresses that have special
			meaning, processing and follow specific forwarding rules. These
			addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE
			Ethernet Label refers to such a MAC address, a bridge encountering
			the mismatch MUST immediately generate an error: Routing problem (24)
			/ Unacceptable label value (6). Handling of this error is according
			to [RFC3209].
	6. Security Considerations		6. Security Considerations
	The architecture assumes that the GMPLS controlled Ethernet subnet		This document does not introduces new security issues; the
	consists of trusted devices and that the UNI ports or in this case		considerations in [RFC4872] and [RFC4873] apply.
	BEB Ethernet UNI Ports to the domain are untrusted. Care is required
	to ensure untrusted access to the trusted domain does not occur.		The GMPLS controlled Ethernet subnet consists of trusted devices and
	Where GMPLS is applied to the control of VLAN only, the commonly		that the UNI ports or in this case BEB Ethernet UNI Ports to the
	known techniques for mitigation of Ethernet DOS attacks may be		domain are untrusted. Care is required to ensure untrusted access to
	required on UNI ports.		the trusted domain does not occur. Where GMPLS is applied to the
			control of VLAN only, the commonly known techniques for mitigation of
			Ethernet DOS attacks may be required on UNI ports. PBB-TE has been
			designed to interwork with legacy VLANs and the VLANs provide
			isolation from Ethernet legacy control planes.
	7. IANA Considerations		7. IANA Considerations
	New values are required for signaling and error codes as indicated		- Assign a new Switching Type: "802_1 PBB-TE" (suggested value 40)
	IANA to define. Value are needed for:		in the GMPLS Signaling Parameters / Switching Types registry.
	- Switching type: 802_1 PBB-TE suggested value 40.		- Assign a new globally defined error value: "PBB-TE Ethernet Label
			VID allocation failure" (suggested value: 35?) under the
			"Routing problem" (24) error code in the RSVP Parameters / Error
			Codes and Globally-Defined Error Value Sub-Codes registry.
	7.1. Error Codes		- Assign a new type from the Attributes TLV Space in the RSVP-TE
			Parameters registry (suggested value 2) for the Service ID TLV
			that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
			= 1) [RFC5420].
	- Invalid ESP-VID value for PBB-TE		- Assign a new type (suggested value 2) for the Service ID TLV that
	- Invalid MAC Address		is carried in the CALL_ATTRIBUTES Object (class = 201, C-Type =
	- Switch is not ESP P2MP capable		1) [MLN-EXT].
	8. References		8. References
	8.1. Normative References		8.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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label		[ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label
	Switching Architecture and Framework", work in progress.		Switching Architecture and Framework", work in progress.
			[RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label
			Switching (GMPLS) Signaling Functional Description" IETF RFC 3471,
			January 2003.
	[RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label		[RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic		Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003.
	[RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label		[RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label
	Switching (GMPLS) Architecture", IETF RFC 3945, October 2004.		Switching (GMPLS) Architecture", IETF RFC 3945, October 2004.
			[MLN-EXT] Papadimitriou, D. et al, "Generalized Multi-Protocol
			Label Switching (GMPLS) Protocol Extensions for Multi-Layer
			and Multi-Region Networks (MLN/MRN)", work in progress.
			[RFC5420] Farrel, A. Ed., "Encoding of Attributes for MPLS LSP
			Establishment Using Resource Reservation Protocol Traffic
			Engineering (RSVP-TE), IETF RFC 5420, February 2009.
	8.2. Informative References		8.2. Informative References
	[IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic		[IEEE 802.1ay] "IEEE Standard for Local and Metropolitan Area
	Engineering", work in progress.		Networks - Virtual Bridged Local Area Networks
			- Amendment : Provider Backbone Bridges Traffic Engineering
			(2009).
	[IEEE 802.1ag] "IEEE Standard for Connectivity Fault		[IEEE 802.1ag] "IEEE Standard for Local and Metropolitan Area
	Management", (2007).		Networks - Virtual Bridged Local Area Networks
			- Amendment 5: Connectivity Fault Management (2007).
	[IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area		[IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area
	Networks - Virtual Bridged Local Area Networks		Networks - Virtual Bridged Local Area Networks
	- Amendment 6: Provider Backbone Bridges", (2008)		- Amendment 6: Provider Backbone Bridges", (2008)
	[RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to		[RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to
	Multipoint TE LSPs", IETF RFC 4875, May 2007		Multipoint TE LSPs", IETF RFC 4875, May 2007
	[PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE)		[PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE)
	Architecture", work in progress.		Architecture", IETF RFC 4655, August 2006
	[RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of End-to-		[RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of End-to-
	End		End
	Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery		Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery
	", RFC 4872, May 2007.		", RFC 4872, May 2007.
	[RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May		[RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May
	2007.		2007.
	[RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP		[RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP
	skipping to change at page 17, line 37		skipping to change at page 18, line 26
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen		The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen
	Shew, Dave Martin and Sandra Ballarte for their contributions to this		Shew, Dave Martin and Sandra Ballarte for their contributions to this
	document.		document.
	10. Author's Address		10. Author's Address
	Don Fedyk		Don Fedyk
	Nortel Networks		Alcatel-Lucent
	600 Technology Park Drive		Groton, MA, 01450
	Billerica, MA, 01821		Phone: +1-978-467-5645
	Email: dwfedyk@nortel.com		Email: donald.fedyk@alcatel-lucent.com
	David Allan		David Allan
	Nortel Networks		Ericsson
	3500 Carling Ave.		Email: david.i.allan@ericsson.com
	Ottawa, Ontario, CANADA
	Email: dallan@nortel.com
	Himanshu Shah		Himanshu Shah
	Ciena		Force10 Networks
	35 Nagog Park,		30 Nagog Park,
	Acton, MA 01720		Acton, MA 01720
	Email: hshah@ciena.com		Email: hshah@force10networks.com
	Nabil Bitar		Nabil Bitar
	Verizon,		Verizon,
	40 Sylvan Rd.,		40 Sylvan Rd.,
	Waltham, MA 02451		Waltham, MA 02451
	Email: nabil.n.bitar@verizon.com		Email: nabil.n.bitar@verizon.com
	Attila Takacs		Attila Takacs
	Ericsson		Ericsson
	1. Laborc u.		1. Laborc u.
	Budapest, HUNGARY 1037		Budapest, HUNGARY 1037
	Email: attila.takacs@ericsson.com		Email: attila.takacs@ericsson.com
	Diego Caviglia		Diego Caviglia
	Ericsson		Ericsson
	Via Negrone 1/A		Via Negrone 1/A
	Genoa, Italy 16153		Genoa, Italy 16153
	skipping to change at line 754		skipping to change at line 777
	COO RTP IE Fixed		COO RTP IE Fixed
	3 Hanagar St. Neve Ne'eman B,		3 Hanagar St. Neve Ne'eman B,
	45241 Hod Hasharon, Israel		45241 Hod Hasharon, Israel
	Email: nurit.sprecher@nsn.com		Email: nurit.sprecher@nsn.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
	Generated on: Wed Feb 25 13:53:58 EST 2009		Generated on: Wed Oct 14 13:52:17 EDT 2009
End of changes. 67 change blocks.
	262 lines changed or deleted		285 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/