< draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt		draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.txt >
	Network Working Group W. Imajuku, Ed., NTT		Network Working Group W. Imajuku, Ed.
	Internet-Draft Otani, Ed., KDDI		Internet-Draft NTT Com
	Intended status: Informational N. Bitar, Ed., Verizon		Intended status: Informational T. Otani, Ed.
	Expires: June 13, 2009		Expires: December 14, 2009 KDDI
	December 10, 2008		N. Bitar, Ed.
			Verizon
			June 12, 2009
	Service Provider Requirements for Ethernet control with GMPLS		Service Provider Requirements for Ethernet control with GMPLS
	draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt		draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with
	applicable patent or other IPR claims of which he or she is aware		the provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	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 months		Internet-Drafts are draft documents valid for a maximum of six months
	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/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	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 June 13, 2009.		This Internet-Draft will expire on December 14, 2009.
	Abstract		Abstract
	Generalized Multi-Protocol Label Switching (GMPLS) is applicable to		Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
	Ethernet switches supporting Provider Backbone Bridge Traffic		Ethernet switches supporting Provider Backbone Bridge Traffic
	Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label		Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label
	switch network not only automates creation of Ethernet Label Switched		switch network not only automates creation of Ethernet Label Switched
	Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery		Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
	Mechanisms such as protection and restoration of an Eth-LSP. This		Mechanisms such as protection and restoration of an Eth-LSP. This
	document describes the requirements for the set of solutions of GMPLS		document describes the requirements for the set of solutions of GMPLS
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	4.1. Control plane architecture and functionality . . . . . . . 7		4.1. Control plane architecture and functionality . . . . . . . 7
	4.1.1. In-band control channel . . . . . . . . . . . . . . . 7		4.1.1. In-band control channel . . . . . . . . . . . . . . . 7
	4.1.2. Neighbor discovery mechanism . . . . . . . . . . . . . 7		4.1.2. Neighbor discovery mechanism . . . . . . . . . . . . . 7
	4.1.3. Addressing . . . . . . . . . . . . . . . . . . . . . . 7		4.1.3. Addressing . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . . 7		4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . . 7
	4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . 7		4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . 7
	4.2.2. Service control . . . . . . . . . . . . . . . . . . . 7		4.2.2. Service control . . . . . . . . . . . . . . . . . . . 7
	4.2.3. P2MP and MP2MP requirements . . . . . . . . . . . . . 8		4.2.3. P2MP and MP2MP requirements . . . . . . . . . . . . . 8
	4.2.4. Asymmetric bandwidth . . . . . . . . . . . . . . . . . 8		4.2.4. Asymmetric bandwidth . . . . . . . . . . . . . . . . . 8
	4.2.5. QoS control . . . . . . . . . . . . . . . . . . . . . 8		4.2.5. QoS control . . . . . . . . . . . . . . . . . . . . . 8
	4.3. OA&M related functionality . . . . . . . . . . . . . . . . 8		4.3. OA&M related functionality . . . . . . . . . . . . . . . . 9
	4.4. Protection and Restoration related functionality . . . . . 8		4.4. Protection and Restoration related functionality . . . . . 9
	4.5. Link Aggregation Group (LAG) related functionality . . . . 9		4.5. Link Aggregation Group (LAG) related functionality . . . . 9
	4.5.1. Failure or deletion of LAG member link . . . . . . . . 9		4.5.1. Failure or deletion of LAG member link . . . . . . . . 9
	4.5.2. Recovery or addition of LAG member link . . . . . . . 9		4.5.2. Recovery or addition of LAG member link . . . . . . . 9
	4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 9		4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 9
	4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 10		4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 10
	4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . 10		4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . 10
	4.7.2. Other requirements . . . . . . . . . . . . . . . . . . 10		4.7.2. Other requirements . . . . . . . . . . . . . . . . . . 10
	4.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10		4.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the		supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the
	solutions for service providers to provide enterprise WAN/LAN		solutions for service providers to provide enterprise WAN/LAN
	services. IEEE standardization activities of Provider Backbone		services. IEEE standardization activities of Provider Backbone
	Bridge(PBB) [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE)		Bridge(PBB) [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE)
	[IEEE802.1Qay] provide an opportunity not only for enhancing the		[IEEE802.1Qay] provide an opportunity not only for enhancing the
	scalability, manageability, and controllability of the Ethernet		scalability, manageability, and controllability of the Ethernet
	service networks, but also for more efficiently deploying access/		service networks, but also for more efficiently deploying access/
	metro access networks.		metro access networks.
	Generalized Multi-Protocol Label Switching (GMPLS) provides the		Generalized Multi-Protocol Label Switching (GMPLS) provides the
	framework for handling and controlling various types of switching		framework for handling and controlling various types of connection-
	technologies, namely packet switching with various label formats TDM		oriented switching technologies, namely packet switching with various
	switching, and wavelength switching [RFC3945]. Therefore, the		label formats TDM switching, and wavelength switching [RFC3945].
	combined use of GMPLS and PBB-TE is a fairly suitable "use case" that		Therefore, the combined use of GMPLS and PBB-TE is a fairly suitable
	contributes to enhancing the flexibility of Ethernet Label Switched		"use case" that contributes to enhancing the flexibility of Ethernet
	Path (Eth-LSP) over Ethernet switch networks without defining		Label Switched Path (Eth-LSP) over Ethernet switch networks without
	additional connection layers.		defining additional connection layers.
	This document describes requirements for GMPLS protocols to control		This document describes requirements for GMPLS protocols to control
	Ethernet label switch networks and comprises mainly two parts. The		Ethernet label switch networks and comprises mainly two parts. The
	first one is the requirements for GMPLS extension for controlling		first one is the requirements for GMPLS extension for controlling
	Ethernet layer. The second one includes the requirements for GMPLS		Ethernet layer. The second one includes the requirements for GMPLS
	extensions to support multi-layer operation. Although a large		extensions to support multi-layer operation. Although a large
	portion of requirements in the second scope coincides with the		portion of requirements in the second scope coincides with the
	description in [RFC5145] and [RFC5146], some of important		description in [RFC5145] and [RFC5146], some of important
	requirements are also described in this document.		requirements are also described in this document.
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Reference model		3. Reference model
	3.1. Single Layer		3.1. Single Layer
	This document describes requirements based on the reference model		This document describes requirements based on the reference model
	depicted in Fig.1. The first reference model is an intra-domain and		depicted in Fig.1. The first reference model is an intra-domain and
	single layer GMPLS controlled Ethernet label switching network in		single layer GMPLS controlled Ethernet label switching network in
	which Eth-LSPs traverse over between Back Bone Core Bridges (BCBs) or		which Eth-LSPs traverse over between Backbone Core Bridges (BCBs) or
	Back Bone Edge Bridges (BEBs).		Backbone Edge Bridges (BEBs).
			-------- ----- --------
			P-based IF --| LSR1 |____|LSR2 |_____| LSR3 |-- P-based IF
			S-tagged IF --|(IB-BEB)| |(BCB)| |(IB-BEB)|-- S-tagged IF
			I-tagged IF --| | | | | |-- I-tagged IF
			-------- ----- --------
	--------
	| LSR3 |__ P-based IF
	-------- ----- _____|(IB-BEB)|__ S-tagged IF
	P-based IF | LSR1 |____|LSR2 | | |__ I-tagged IF
	S-tagged IF |(IB-BEB)| |(BCB)| --------
	I-tagged IF | | | |_____ --------
	-------- ----- | LSR4 |
	| (B-BEB)|
	| |__ I-tagged IF
	--------
	| GMPLS Eth-LSP |		| GMPLS Eth-LSP |
	| (BVID/BMAC) |		| (BVID/BMAC) |
	|<---------------|		|<-------------->|
	Figure 1 Single layer GMPLS controlled PBB-TE network		Figure 1 Single layer GMPLS controlled PBB-TE network
	The BEBs provide mainly three types of service interfaces, namely		The BEBs provide mainly three types of service interfaces, namely
	Port based service interface (P-based IF), S-tagged service interface		Port based service interface (P-based IF), S-tagged service interface
	(S-tagged IF), and I-tagged service Interface (I-tagged IF)		(S-tagged IF), and I-tagged service Interface (I-tagged IF)
	[IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to		[IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to
	the I-component of a BEB (I-BEB), while the I-tagged IF is connected		the I-component of a BEB (I-BEB), while the I-tagged IF is connected
	to the B-component of a BEB (B-BEB). "S-tagged IF" can perform		to the B-component of a BEB (B-BEB). "S-tagged IF" can perform
	various types of mapping between Service VLAN ID (S-VID) and Backbone		various types of mapping between Service VLAN ID (S-VID) and Backbone
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 8 ¶
	Also, it is technically possible to form multiple layer Ethernet		Also, it is technically possible to form multiple layer Ethernet
	switch networks. Namely, the reference model is defined as the case		switch networks. Namely, the reference model is defined as the case
	that Ethernet switch network substitutes L1 network in Fig.2, and		that Ethernet switch network substitutes L1 network in Fig.2, and
	realizes MAC in MAC Ethernet transport. The routing information of		realizes MAC in MAC Ethernet transport. The routing information of
	optical layer may be isolated (overlay model), shuffled (peer model),		optical layer may be isolated (overlay model), shuffled (peer model),
	or virtualized with FA-LSPs (augmented model) for Ethernet switch		or virtualized with FA-LSPs (augmented model) for Ethernet switch
	layer.		layer.
	-------- ------ --------		-------- ------ --------
	P-based IF __| LSR1 | | LSR2 | | LSR3 |__ P-based IF		P-based IF --| LSR1 | | LSR2 | | LSR3 |-- P-based IF
	S-tagged IF __|(IB-BEB)| | (BCB)| |(IB-BEB)|__ S-tagged IF		S-tagged IF --|(IB-BEB)| | (BCB)| |(IB-BEB)|-- S-tagged IF
	I-tagged IF __| | | | | |__ I-tagged IF		I-tagged IF --| | | | | |-- I-tagged IF
	-------- ------ --------		-------- ------ --------
	| | ||LAG LAG||		| | ||LAG LAG||
	..................|...........|..||..........||...................		..................|...........|..||..........||...................
	| | || ||		| | || ||
	---+---- ------ ------		---+---- ------ ------
	| LSR A |_____|LSR B |_____|LSR C |		| LSR A |_____|LSR B |_____|LSR C |
	| (LSC) | |(LSC) | WDM |(LSC) |		| (LSC) | |(LSC) | WDM |(LSC) |
	-------- ------ ------		-------- ------ ------
	| GMPLS Eth-LSP (BVID/BMAC)|		| GMPLS Eth-LSP (BVID/BMAC)|
	|<------------------------>|		|<------------------------>|
	| O-LSP | | O-LSP |		| O-LSP | | O-LSP |
	|<--------->| |<-------->|		|<--------->| |<-------->|
	Figure 2 Multi-layer GMPLS controlled Ethernet label switched network		Figure 2 Multi-layer GMPLS controlled Ethernet label switched network
	4. Requirements		4. Requirements
			Section 4.1 to 4.6 describe requirements for single layer Ethernet
			label swicth network based on the reference model from Fig.1. In
			addition, section 4.7 describes requirements for multiple layer
			network with Ethernet layer and circuit switch layer (such as
			wavelength switched layer and so on). Finally, section 4.8 describes
			generic requirements applicable to single and multiple layer
			networks.
	4.1. Control plane architecture and functionality		4.1. Control plane architecture and functionality
	4.1.1. In-band control channel		4.1.1. In-band control channel
	The solution should be able to establish in-band control channel,		The solution should be able to establish in-band control channel,
	while preserving the solution of out-band control channel. The		while preserving the solution of out-band control channel. The
	solution should include negotiation mechanism to specify bandwidth		solution should include negotiation mechanism to specify bandwidth
	and priority of control-channel between peer Ethernet switches.		and priority of control-channel between peer Ethernet switches.
	4.1.2. Neighbor discovery mechanism		4.1.2. Neighbor discovery mechanism
	The solution MUST be able to realize automatic neighbor discover as		The solution MUST be able to realize automatic neighbor discovery as
	realized in current PB or PBB networks. Namely, the solution MUST		realized in current PB or PBB networks. Namely, the solution MUST
	support an automatic negotiation mechanism to exchange information of		support an automatic negotiation mechanism to exchange information of
	Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and		Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and
	IP address of the control channel. On the other hand, the extension		IP address of the control channel for these configuration between
	should be minimized by making use of [IEEE802.1AB].		neighbors. On the other hand, the extension should be minimized by
			making use of [RFC4394] and [IEEE802.1AB].
	4.1.3. Addressing		4.1.3. Addressing
	TBD		All service interfaces, TE-Link IDs and Data-link IDs MUST be able to
			be indicated by standard IEEE MAC address format, but Node ID should
			be with IP addresses.
	4.2. Ethernet LSP control		4.2. Ethernet LSP control
	4.2.1. Prevention of Loops		4.2.1. Prevention of Loops
	The solution should have reliability to prevent creating loops of		The solution should have reliability to prevent creating loops of
	Eth-LSPs. Specifically if the solution supports numbered TE-Link		Eth-LSPs. Specifically if the solution supports numbered TE-Link
	addressing, the solution should define a methodology and protocol		addressing, the solution should define a methodology and protocol
	extensions if needed to detect or prevent loops.		extensions if needed to detect or prevent loops.
	skipping to change at page 7, line 42 ¶		skipping to change at page 8, line 4 ¶
	The solution should have reliability to prevent creating loops of		The solution should have reliability to prevent creating loops of
	Eth-LSPs. Specifically if the solution supports numbered TE-Link		Eth-LSPs. Specifically if the solution supports numbered TE-Link
	addressing, the solution should define a methodology and protocol		addressing, the solution should define a methodology and protocol
	extensions if needed to detect or prevent loops.		extensions if needed to detect or prevent loops.
	4.2.2. Service control		4.2.2. Service control
	The solution should control various types of service interfaces		The solution should control various types of service interfaces
	defined in [IEEE802.1ah]. The service types of Egress port		defined in [IEEE802.1ah]. The service types of Egress port
	1) Port based service interface		1) Port based service interface
	2) S-tagged service interface		2) S-tagged service interface
	a) one-to-one mapping of S-VIDs to I-SIDs		a) one-to-one mapping of S-VIDs to I-SIDs
	b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to-		b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to-
	one, transparent mapping		one, transparent mapping
			3) I-tagged service interface should be controllable in addition to
			assignment of Egress port itself.
	Also, the solution should be flexible to following operational		Also, the solution should be flexible to following operational
	scenarios,		scenarios,
	1) Any change of mapping of S-VIDs to I-SIDs		1) Any change of mapping of S-VIDs to I-SIDs
	2) Flexibility to nest or stitch higher layer Eth-LSPs.		2) Flexibility to nest or stitch higher layer Eth-LSPs.
	3) Any change of bandwidth of Eth-LSPs. Here, the solution of		3) Any change of bandwidth of Eth-LSPs. Here, the solution of
	bandwidth modification scenario may include bundling of multiple Eth-		bandwidth modification scenario may include bundling of multiple Eth-
	LSPs.		LSPs.
	4.2.3. P2MP and MP2MP requirements		4.2.3. P2MP and MP2MP requirements
	To provide the service such as a content distribution, the creation		To provide the service such as a content distribution, the creation
	of uni-directional P2MP Eth-LSPs should be supported. Also, to		of uni-directional P2MP Eth-LSPs should be supported. Also, to
	provide E-tree type services with multicast traffic, the creation of		provide E-tree type services with multicast traffic, the creation of
	bi-directional P2MP/MP2P Eth-LSPs should be supported. The MP2MP		bi-directional P2MP Eth-LSPs should be supported. The MP2MP
	requirement is under discussion.		requirement is for further study.
	4.2.4. Asymmetric bandwidth		4.2.4. Asymmetric bandwidth
	To provide the service which has asymmetric traffic pattern such as a		To provide the service which has asymmetric traffic pattern such as a
	kind of E-tree type services, the creation of asymmetric bandwidth		kind of E-tree type services, the creation of asymmetric bandwidth
	bi-directional Eth-LSPs should be supported. The bandwidth		bi-directional Eth-LSPs should be supported. The bandwidth
	modification of Eth-LSPs in operation should be also supported.		modification of Eth-LSPs in operation should be also supported.
	4.2.5. QoS control		4.2.5. QoS control
	skipping to change at page 9, line 8 ¶		skipping to change at page 9, line 23 ¶
	[IEEE802.1ag].		[IEEE802.1ag].
	4.4. Protection and Restoration related functionality		4.4. Protection and Restoration related functionality
	1:1 protection, Shared protection and dynamic restoration should be		1:1 protection, Shared protection and dynamic restoration should be
	supported. Protection and Restoration may be triggered by Ethernet		supported. Protection and Restoration may be triggered by Ethernet
	OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731].		OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731].
	4.5. Link Aggregation Group (LAG) related functionality		4.5. Link Aggregation Group (LAG) related functionality
	Link Aggregation is beneficial functionality to realize reliable		Link Aggregation is beneficial functionality to realize flexible
	Ethernet label switched networks. The availability of connection		reconfiguration of logical link bandwidth and reliable Ethernet label
	between peer Ethernet switches can be enhanced in the case of single		switched networks. The availability of link bandwidth between peer
	link failure, if member links of the LAG are diversely routed. In		Ethernet switches can be enhanced.
	this operational scenario, LAG provides for link protection
	functionality.
	The solution should include methodology to explicitly assign the		The solution should support Link Bundling mechanism described in
	links forming LAG a desired link type (which is similar sense to		[RFC4201] to explicitly assign the links forming LAG.
	assign link protection type described in [RFC3471]).
	4.5.1. Failure or deletion of LAG member link		4.5.1. Failure or deletion of LAG member link
	The solution should include functionality to prioritize Eth-LSPs,		The solution should include functionality to prioritize Eth-LSPs,
	specifically when total bandwidth of Eth-LSPs exceeds total bandwidth		specifically when total bandwidth of Eth-LSPs exceeds total bandwidth
	of healthy LAG members after the failure of one or more LAG member		of healthy LAG members after the failure of one or more LAG member
	links.		links.
	The solution should provide for rerouting an Eth-LSP setup over a		The solution should provide for rerouting an Eth-LSP setup over a
	failed member link in a LAG to another member link in the LAG.		failed member link in a LAG to another member link in the LAG.
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 18 ¶
	2) S-tagged service interfaces, and		2) S-tagged service interfaces, and
	3) C-tagged service interfaces.		3) C-tagged service interfaces.
	4.7. Multi-layer network		4.7. Multi-layer network
	4.7.1. Dynamic formation of LAG		4.7.1. Dynamic formation of LAG
	The solution should include dynamic formation of a LAG after the		The solution should include dynamic formation of a LAG after the
	creation or deletion of optical LSPs which interconnect ports of		creation or deletion of optical LSPs which interconnect ports of
	Ethernet switches.		Ethernet switches. It should use the existing Link Bundling
			mechanism to assign bandwidth to dynamically formulated LAG.
	4.7.2. Other requirements		4.7.2. Other requirements
	The architecture and requirements for MPLS-GMPLS inter-working are		The architecture and requirements for MPLS-GMPLS inter-working are
	described in [RFC5145] and [RFC5146]. Some of the requirements		described in [RFC5145] and [RFC5146]. Some of the requirements
	described in [RFC5146] are valid even for the case of GMPLS-GMPLS		described in [RFC5146] are valid even for the case of GMPLS-GMPLS
	interworking between Ethernet label switched network and L1 network.		interworking between Ethernet label switched network and L1 network.
	In other words,		In other words,
	1) End-to-End signaling of Eth-LSPs		1) End-to-End signaling of Eth-LSPs
	2) Triggered establishment of L1 LSPs		2) Triggered establishment of L1 LSPs
	3) Avoiding complexity and risks.		3) Avoiding complexity and risks.
	should be satisfied even for GMPLS control plane for Ethernet. For		should be satisfied even for GMPLS control plane for Ethernet. For
	more details, see [Interwk-req] and MPLS-TE client network written in		more details, see [RFC5146] and MPLS-TE client network written in the
	the document should be understood as Ethernet client network.		document should be understood as Ethernet client network.
	Regarding to routing issue,		Regarding to routing issue,
	1) Advertisement of Ethernet label switch network information via L1		1) Advertisement of Ethernet label switch network information via L1
	GMPLS networks		GMPLS networks
	2) Selective Advertisement of Ethernet label switched network		2) Selective Advertisement of Ethernet label switched network
	information via a Border node		information via a Border node
	should be satisfied even in the case of GMPLS-GMPLS inter-working.		should be satisfied even in the case of GMPLS-GMPLS inter-working.
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 13 ¶
	control channel.		control channel.
	4.8. Scalability		4.8. Scalability
	The solution MUST be designed to scale according to following		The solution MUST be designed to scale according to following
	metrics.		metrics.
	- Number of nodes		- Number of nodes
	- Number of TE-Links		- Number of TE-Links
	- Number of LSPs		- Number of LSPs
	- Number of service ports		- Number of service ports
	- Number of bundled S-VLANs mapped to I-SID and Eth-LSPs.		- Number of bundled S-VLANs mapped to I-SID and Eth-LSPs
			- Number of advertised VLANs
			- Number of MEPs and MIPs.
	5. Security Considerations		5. Security Considerations
	The extension for GMPLS controlled Ethernet label switching should be		The extension for GMPLS controlled Ethernet label switching should be
	considered under the same security as current work. This extension		considered under the same security as current work. This extension
	will not change the underlying security issues.		will not change the underlying security issues.
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Mr. Allan McGuire, Mr. Jullien		The authors would like to thank Mr. Allan McGuire, Mr. Jullien
	Meuric, Mr. Lou Berger and Mr. Don Fedyk for their valuable comments.		Meuric, Mr. Lou Berger, Mr. Don Fedyk and Mr. Attila Takacs for their
			valuable comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[IEEE802.1AB]		[IEEE802.1AB]
	IEEE Standard for Local and Metropolitan Area Networks,		"IEEE Standard for Local and Metropolitan Area Networks,
	Station and Media Access Control Connectivity		Station and Media Access Control Connectivity Discovery".
	Discovery
	[IEEE802.1Qay]		[IEEE802.1Qay]
	"IEEE standard for Provider Backbone Bridges Traffic		"IEEE standard for Provider Backbone Bridges Traffic
	Engineering", work in progress.		Engineering", work in progress.".
	[IEEE802.1ad]		[IEEE802.1ad]
	IEEE Computer Society, "Virtual Bridged Local Area		"IEEE Computer Society, "Virtual Bridged Local Area
	Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0,		Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0,
	Draft, Work in Progress.		Draft, Work in Progress".
	[IEEE802.1ag]		[IEEE802.1ag]
	IEEE Computer Society, "Virtual Bridged Local Area		"IEEE Computer Society, "Virtual Bridged Local Area
	Networks - Amendment 5 : Connectivity Fault Management",		Networks - Amendment 5 : Connectivity Fault Management",
	P802.1ag/D5.2, Draft, Work in Progress.		P802.1ag/D5.2, Draft, Work in Progress".
	[IEEE802.1ah]		[IEEE802.1ah]
	"IEEE standard for Provider Backbone Bridges", work in		"IEEE standard for Provider Backbone Bridges", work in
	progress.		progress.".
	[IEEE802.3]		[IEEE802.3]
	IEEE Computer Society, "Amendment to Carrier Sense		"IEEE Computer Society, "Amendment to Carrier Sense
	Multiple Access with Collision Detection (CAMS/CD) Access		Multiple Access with Collision Detection (CAMS/CD) Access
	Method and Physical Layer Specifications.		Method and Physical Layer Specifications".
	[MEF10.1] MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http		[MEF10.1] "MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http
	://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf,		://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf,
	Nov. 2006.		Nov. 2006.".
	[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.
	[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Functional Description", RFC 3471,		(GMPLS) Signaling Functional Description", RFC 3471,
	January 2003.		January 2003.
	[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching		[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
	(GMPLS) Architecture", RFC 3945, October 2004.		(GMPLS) Architecture", RFC 3945, October 2004.
	[Y.1731] "ITU-T Y.1731".		[Y.1731] "ITU-T Y.1731".
	8.2. Informative References		8.2. Informative References
	[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of		[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
	Diffserv-aware MPLS Traffic Engineering", RFC 4124,		Diffserv-aware MPLS Traffic Engineering", RFC 4124,
	June 2005.		June 2005.
			[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
			in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
			[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
			October 2005.
			[RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D.
			Papadimitriou, "A Transport Network View of the Link
			Management Protocol (LMP)", RFC 4394, February 2006.
	[RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration",		[RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration",
	RFC 5145, March 2008.		RFC 5145, March 2008.
	[RFC5146] Kumaki, K., "Interworking Requirements to Support		[RFC5146] Kumaki, K., "Interworking Requirements to Support
	Operation of MPLS-TE over GMPLS Networks", RFC 5146,		Operation of MPLS-TE over GMPLS Networks", RFC 5146,
	March 2008.		March 2008.
	Authors' Addresses		Authors' Addresses
	Wataru Imajuku (editor)		Wataru Imajuku (editor)
	NTT Network Innovation Labs		NTT Communications Corporation
	1-1 Hikari-no-oka		1-1-6 Uchisaiwai-cho
	Yokosuka, Kanagawa		Chiyoda-ku, Tokyo
	Japan		Japan
	Phone: +81-(46) 859-4315		Phone: +81-(46) 859-4315
	Email: imajuku.wataru@lab.ntt.co.jp		Email: imajuku.wataru@lab.ntt.co.jp
	Yoshiaki Sone		Yoshiaki Sone
	NTT Network Innovation Labs		NTT Network Innovation Labs
	1-1 Hikari-no-oka		1-1 Hikari-no-oka
	Yokosuka, Kanagawa		Yokosuka, Kanagawa
	Japan		Japan
	skipping to change at page 18, line 6 ¶		skipping to change at page 18, line 6 ¶
	Kazuhiro Matsuda		Kazuhiro Matsuda
	NTT Network Innovation Labs		NTT Network Innovation Labs
	1-1 Hikari-no-oka		1-1 Hikari-no-oka
	Yokosuka, Kanagawa		Yokosuka, Kanagawa
	Japan		Japan
	Phone: (46) 859-3177		Phone: (46) 859-3177
	Email: matsuda.kazuhiro@lab.ntt.co.jp		Email: matsuda.kazuhiro@lab.ntt.co.jp
	Tomohiro Otani (editor)		Tomohiro Otani (editor)
	KDDI Corporation		KDDI Corporation
	2-3-2 Nishi-shinjukuOhara		2-3-2 Nishi-shinjuku
	Shinjuku-ku, Tokyo 163-8003		Shinjuku-ku, Tokyo 163-8003
	Japan		Japan
	Phone: +81-(3) 3347-6006		Phone: +81-(3) 3347-6006
	Email: tm-otani@kddi.com		Email: tm-otani@kddi.com
	Kenichi Ogaki		Kenichi Ogaki
	KDDI R&D Laboratories, Inc.		KDDI R&D Laboratories, Inc.
	2-1-15 Ohara		2-1-15 Ohara
	Kamifukuoka, Saitama 356-8502		Kamifukuoka, Saitama 356-8502
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 7 ¶
	Nabil Bitar (editor)		Nabil Bitar (editor)
	Verizon		Verizon
	40 Sylvan Road		40 Sylvan Road
	Waltham, MA 02451		Waltham, MA 02451
	USA		USA
	Email: nabil.n.bitar@verizon.com		Email: nabil.n.bitar@verizon.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	This document is subject to the rights, licenses and restrictions		This document is subject to BCP 78 and the IETF Trust's Legal
	contained in BCP 78, and except as set forth therein, the authors		Provisions Relating to IETF Documents in effect on the date of
	retain all their rights.		publication of this document
			(http://trustee.ietf.org/license-info). Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document.
	This document and the information contained herein are provided on an		All IETF Documents and the information contained therein are provided
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
			FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF Trust takes no position regarding the validity or scope of
	Intellectual Property Rights or other rights that might be claimed to		any Intellectual Property Rights or other rights that might be
	pertain to the implementation or use of the technology described in		claimed to pertain to the implementation or use of the technology
	this document or the extent to which any license under such rights		described in any IETF Document or the extent to which any license
	might or might not be available; nor does it represent that it has		under such rights might or might not be available; nor does it
	made any independent effort to identify any such rights. Information		represent that it has made any independent effort to identify any
	on the procedures with respect to rights in RFC documents can be		such rights.
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of Intellectual Property disclosures made to the IETF
	assurances of licenses to be made available, or the result of an		Secretariat and any assurances of licenses to be made available, or
	attempt made to obtain a general license or permission for the use of		the result of an attempt made to obtain a general license or
	such proprietary rights by implementers or users of this		permission for the use of such proprietary rights by implementers or
	specification can be obtained from the IETF on-line IPR repository at		users of this specification can be obtained from the IETF on-line IPR
	http://www.ietf.org/ipr.		repository at http://www.ietf.org/ipr
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		any standard or specification contained in an IETF Document. Please
	ietf-ipr@ietf.org.		address the information to the IETF at ietf-ipr@ietf.org.
			The definitive version of an IETF Document is that published by, or
			under the auspices of, the IETF. Versions of IETF Documents that are
			published by third parties, including those that are translated into
			other languages, should not be considered to be definitive versions
			of IETF Documents. The definitive version of these Legal Provisions
			is that published by, or under the auspices of, the IETF. Versions of
			these Legal Provisions that are published by third parties, including
			those that are translated into other languages, should not be
			considered to be definitive versions of these Legal Provisions.
			For the avoidance of doubt, each Contributor to the IETF Standards
			Process licenses each Contribution that he or she makes as part of
			the IETF Standards Process to the IETF Trust pursuant to the
			provisions of RFC 5378. No language to the contrary, or terms,
			conditions or rights that differ from or are inconsistent with the
			rights and licenses granted under RFC 5378, shall have any effect and
			shall be null and void, whether published or posted by such
			Contributor, or included with or in such Contribution.
End of changes. 45 change blocks.
	100 lines changed or deleted		126 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/