draft-ietf-ccamp-gmpls-otn-b100g-applicability-01.txt		draft-ietf-ccamp-gmpls-otn-b100g-applicability-02.txt
	Internet Engineering Task Force Q. Wang, Ed.		Internet Engineering Task Force Q. Wang, Ed.
	Internet-Draft ZTE		Internet-Draft ZTE Corporation
	Intended status: Informational R. Valiveti, Ed.		Intended status: Informational R. Valiveti, Ed.
	Expires: January 8, 2020 Infinera Corp		Expires: September 7, 2020 Infinera Corp
	H. Zheng, Ed.		H. Zheng, Ed.
	Huawei		Huawei
	H. Helvoort		H. Helvoort
	Hai Gaoming B.V		Hai Gaoming B.V
	S. Belotti		S. Belotti
	Nokia		Nokia
	July 7, 2019		March 6, 2020
	Applicability of GMPLS for B100G Optical Transport Network		Applicability of GMPLS for B100G Optical Transport Network
	draft-ietf-ccamp-gmpls-otn-b100g-applicability-01		draft-ietf-ccamp-gmpls-otn-b100g-applicability-02
	Abstract		Abstract
	This document examines the applicability of using current existing		This document examines the applicability of using current existing
	GMPLS routing and signaling to set up ODUk/ODUflex over ODUCn link,		GMPLS routing and signaling to set up ODUk/ODUflex over ODUCn link,
	as a result of the support of OTU/ODU links with rates larger than		as a result of the introduction of OTU/ODU links with rates larger
	100G in the 2016 version of G.709.		than 100G in the 2016 version of G.709.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on January 8, 2020.		This Internet-Draft will expire on September 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. OTN terminology used in this document . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.2. OTN terminology used in this document . . . . . . . . . . 3
	3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4		3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4
	3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. Carrying OTUCn between 3R points . . . . . . . . . . 5
	3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Time Slot Granularity . . . . . . . . . . . . . . . . . . 8		3.4. Time Slot Granularity . . . . . . . . . . . . . . . . . . 8
	3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8		3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8
	3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 8		3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 8
	4. Applicability and GMPLS Implications . . . . . . . . . . . . 10		4. Applicability and GMPLS Implications . . . . . . . . . . . . 10
	4.1. Applicability and Challenges . . . . . . . . . . . . . . 10		4.1. Applicability and Challenges . . . . . . . . . . . . . . 10
	4.2. GMPLS Implications and Applicability . . . . . . . . . . 12		4.2. GMPLS Implications and Applicability . . . . . . . . . . 12
	4.2.1. TE-Link Representation . . . . . . . . . . . . . . . 12		4.2.1. TE-Link Representation . . . . . . . . . . . . . . . 12
	4.2.2. Implications and Applicability for GMPLS Signalling . 13		4.2.2. Implications and Applicability for GMPLS Signalling . 13
	4.2.3. Implications and Applicability for GMPLS Routing . . 14		4.2.3. Implications and Applicability for GMPLS Routing . . 14
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 15		6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 15
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. Normative References . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The current GMPLS routing [RFC7138] and signaling extensions		The current GMPLS routing [RFC7138] and signaling extensions
	[RFC7139] only includes coverage for the control of all the OTN		[RFC7139] only supports the control of OTN signals and capabilities
	capabilities that were defined in the 2012 version of G.709		that were defined in the 2012 version of G.709 [ITU-T_G709_2012].
	[ITU-T_G709_2012].
	While the 2016 version of G.709 [ITU-T_G709_2016] introduces support		Since the publishment of the latest 2016 version of G.709
	for new higher rate ODU signals, termed ODUCn (which have a nominal		[ITU-T_G709_2016], which introduces support for new higher rate ODU
	rate of n x 100 Gbps), how to use GMPLS to configure ODUCn should be		signals, termed ODUCn (which have a nominal rate of n x 100 Gbps),
	taken into consideration. But it seems how to configure the ODUCn		how to applied GMPLS to ODUCn case should be taken into
	link needs more discussion, so this draft mainly focuses on the use		consideration. As OTUCn and ODUCn only perform section layer role
	of current GMPLS mechanisms to set up ODUk/ODUflex over an existing		only according to the definition in G.709 [ITU-T_G709_2016], which
	ODUCn link.		means the OTUCn and ODUCn are only used to provide for the transfer
			of information between two adjacent upper layer cross-connects, i.e.,
			ODUk/ODUflex cross connects, it's not appropriate to apply GMPLS to
			OTUCn and ODUCn. Therefore, this document mainly focuses on the use
			of GMPLS mechanisms to set up ODUk/ODUflex over an existing ODUCn
			link.
	This document presents an overview of the changes introduced in		This document first presents an overview of the changes introduced in
	[ITU-T_G709_2016] to motivate the present topic and then analyzes how		[ITU-T_G709_2016] to motivate the present topic and then analyzes how
	the current GMPLS routing and signalling mechanisms can be utilized		the current GMPLS routing and signalling mechanisms can be utilized
	to setup ODUk/ODUflex connections over ODUCn links.		to setup ODUk/ODUflex connections over ODUCn links. In order to make
			the description in this document clear, how to set up ODUCn link is
			also mentioned.
	1.1. Scope		1.1. Scope
	For the purposes of the B100G control plane discussion, the OTN		For the purposes of the B100G control plane discussion, the OTN
	should be considered as a combination of ODU and OTSi layers. Note		should be considered as a combination of ODU and OTSi layers. Note
	that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for		that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for
	B100G entities, and leaving it intact only for maintaining continuity		B100G entities, and leaving it intact only for maintaining continuity
	in the description of the signals with bandwidth upto 100G. This		in the description of the signals with bandwidth upto 100G.
	document focuses on only the control of the ODU layer. The control
	of the OTSi layer is out of scope of this document. But in order to
	facilitate the description of the challenges brought by
	[ITU-T_G709_2016] to B100G GMPLS routing and signalling, some general
	description about OTSi will be included in this draft.
	2. Terminology
	2.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document only focuses on the control of the ODU layer. The
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		control of the OTSi layer is out of scope of this document. But in
	document are to be interpreted as described in RFC 2119 [RFC2119].		order to facilitate the description of the challenges brought by
			[ITU-T_G709_2016] to B100G GMPLS routing and signalling, some general
			description about OTSi is included in section 4 of this document.
	2.2. OTN terminology used in this document		2. OTN terminology used in this document
	a. OPUCn: Optical Payload Unit -Cn.		a. OPUCn: Optical Payload Unit -Cn.
	b. ODUCn: Optical Data Unit - Cn.		b. ODUCn: Optical Data Unit - Cn.
	c. OTUCn: Fully standardized Optical Transport Unit - Cn.		c. OTUCn: Fully standardized Optical Transport Unit - Cn.
	d. OTUCn-M: This signal is an extension of the OTUCn signal		d. OTUCn-M: This signal is an extension of the OTUCn signal
	introduced above. This signal contains the same amount of		introduced above. This signal contains the same amount of
	overhead as the OTUCn signal, but contains a reduced amount of		overhead as the OTUCn signal, but contains a reduced amount of
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 9 ¶
	Multiplex Structrure Indicator (MSI) defined below.		Multiplex Structrure Indicator (MSI) defined below.
	f. MSI: Multiplex Structure Indicator. This structure indicates the		f. MSI: Multiplex Structure Indicator. This structure indicates the
	grouping of the tributary slots in an OPU payload area to realize		grouping of the tributary slots in an OPU payload area to realize
	a client signal that is multiplexed into an OPU. The individual		a client signal that is multiplexed into an OPU. The individual
	clients multiplexed into the OPU payload area are distinguished		clients multiplexed into the OPU payload area are distinguished
	by the Tributary Port number (TPN).		by the Tributary Port number (TPN).
	g. GMP: Generic Mapping Procedure.		g. GMP: Generic Mapping Procedure.
	h. OTSiG: see [ITU-T_G872]		h. OTSiG: The set of OTSi that supports a single digital client.
	i. OTSiA: see [ITU-T_G872]		i. OTSiA: The OTSiG together with the non-associated overhead
			(OTSiG-O).
	Detailed description of these terms can be found in		Detailed description of these terms can be found in [ITU-T_G709_2016]
	[ITU-T_G709_2016].		and [ITU-T_G807].
	3. Overview of B100G in G.709		3. Overview of B100G in G.709
	This section provides an overview of new features in		This section provides an overview of new features in
	[ITU-T_G709_2016].		[ITU-T_G709_2016].
	3.1. OTUCn		3.1. OTUCn
	In order to carry client signals with rates greater than 100Gbps,		In order to carry client signals with rates greater than 100Gbps,
	[ITU-T_G709_2016] takes a general and scalable approach that		[ITU-T_G709_2016] takes a general and scalable approach that
	decouples the rates of OTU signals from the client rate evolution.		decouples the rates of OTU signals from the client rate. The new OTU
	The new OTU signal is called OTUCn; this signal is defined to have a		signal is called OTUCn, and this signal is defined to have a rate of
	rate of (approximately) n*100G. The following are the key		(approximately) n*100G. The following are the key characteristics of
	characteristics of the OTUCn signal:		the OTUCn signal:
	a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals		a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals
	perform digital section roles only (see		perform digital section roles only (see
	[ITU-T_G709_2016]:Section 6.1.1)		[ITU-T_G709_2016]:Section 6.1.1)
	b. The OTUCn signals can be viewed as being formed by interleaving n		b. The OTUCn signals can be viewed as being formed by interleaving n
	OTUC signals (where are labeled 1, 2, ..., n), each of which has		OTUC signals (which are labeled 1, 2, ..., n), each of which has
	the format of a standard OTUk signal without the FEC columns (per		the format of a standard OTUk signal without the FEC columns (per
	[ITU-T_G709_2016]Figure 7-1). The ODUCn have a similar		[ITU-T_G709_2016]Figure 7-1). The ODUCn have a similar
	structure, i.e. they can be seen as being formed by interleaving		structure, i.e. they can be seen as being formed by interleaving
	n instances of ODUC signals (respectively). The OTUC signal		n instances of ODUC signals (respectively). The OTUC signal
	contains the ODUC signals, just as in the case of fixed rate OTUs		contains the ODUC signals, just as in the case of fixed rate OTUs
	defined in G.709 [ITU-T_G709_2016].		defined in G.709 [ITU-T_G709_2016].
	c. Each of the OTUC "slices" have the same overhead (OH) as the		c. Each of the OTUC "slices" have the same overhead as the standard
	standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined		OTUk signal in G.709 [ITU-T_G709_2016]. The combined signal
	signal OTUCn has n instances of OTUC OH, ODUC OH.		OTUCn has n instances of OTUC overhead, ODUC overhead.
	d. The OTUC signal has a slightly higher rate compared to the OTU4		d. The OTUC signal has a slightly higher rate compared to the OTU4
	signal (without FEC); this is to ensure that the OPUC payload		signal (without FEC); this is to ensure that the OPUC payload
	area can carry an ODU4 signal.		area can carry an ODU4 signal.
	3.1.1. Carrying OTUCn between 3R points
	As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn		As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn
	and OPUCn signal structures are presented in a (physical) interface		and OPUCn signal structures are presented in a (physical) interface
	independent manner, by means of n OTUC, ODUC and OPUC instances that		independent manner, by means of n OTUC, ODUC and OPUC instances that
	are marked #1 to #n. Specifically, the definition of the OTUCn		are marked #1 to #n. Specifically, the definition of the OTUCn
	signal does not cover aspects such as FEC, modulation formats, etc.		signal does not cover aspects such as FEC, modulation formats, etc.
	These details are defined as part of the adaptation of the OTUCn		These details are defined as part of the adaptation of the OTUCn
	layer to the optical layer(s). The specific interleaving of		layer to the optical layer(s). The specific interleaving of
	OTUC/ODUC/OPUC signals onto the optical signals is interface specific		OTUC/ODUC/OPUC signals onto the optical signals is interface specific
	and specified for OTN interfaces with standardized application codes		and specified for OTN interfaces with standardized application codes
	in the interface specific recommendations (G.709.x).		in the interface specific recommendations (G.709.x).
	The following scenarios of OTUCn transport need to be considered (see		OTUCn interfaces can be categorized as follows, based on the type of
	Figure 1):		peer network element (see Figure 1):
	a. inter-domain interfaces: These types of interfaces are used for		a. inter-domain interfaces: These types of interfaces are used for
	connecting OTN edge nodes to (a) client equipment (e.g. routers)		connecting OTN edge nodes to (a) client equipment (e.g. routers)
	or (b) hand-off points from other OTN networks. ITU-T has		or (b) hand-off points from other OTN networks. ITU-T has
	standardized the Flexible OTN (FlexO) interfaces to support these		standardized the Flexible OTN (FlexO) interfaces to support these
	functions. Recommendation [ITU-T_G709.1] specifies a flexible		functions. For example, Recommendation [ITU-T_G709.1] specifies
	interoperable short-reach OTN interface over which an OTUCn (n		a flexible interoperable short-reach OTN interface over which an
	>=1) is transferred, using bonded FlexO interfaces which belong		OTUCn (n >=1) is transferred, using bonded FlexO interfaces which
	to a FlexO group. In its current form, Recommendation		belong to a FlexO group.
	[ITU-T_G709.1] is limited to the case of transporting OTUCn
	signals using n 100G Ethernet PHY(s). When the PHY(s) for the
	emerging set of Ethernet signals, e.g. 200GbE and 400GbE, become
	available, new recommendations can define the required
	adaptations.
	b. intra-domain interfaces: In these cases, the OTUCn is transported		b. intra-domain interfaces: In these cases, the OTUCn is transported
	using a proprietary (vendor specific) encapsulation, FEC etc. In		using a proprietary (vendor specific) encapsulation, FEC etc. It
	future, it may be possible to transport OTUCn for intra-domain		may also be possible to transport OTUCn for intra-domain links
	links using future variants of FlexO.		using FlexO.
	==================================================================		==================================================================
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| OTUCn signal |		| OTUCn signal |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| Inter+Domain | Intra+Domain | Intra+Domain |		| Inter+Domain | Intra+Domain | Intra+Domain |
	| Interface (IrDI)| Interface (IaDI)| Interface |		| Interface (IrDI)| Interface (IaDI)| Interface |
	| FlexO (G.709.1) | FlexO (G.709.x) | Proprietary |		| FlexO (G.709.1) | FlexO (G.709.x) | Proprietary |
	| | (Future) | Encap, FEC etc. |		| | (Future) | Encap, FEC etc. |
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 10 ¶
	==================================================================		==================================================================
	Figure 1: OTUCn transport possibilities		Figure 1: OTUCn transport possibilities
	3.2. ODUCn		3.2. ODUCn
	The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by		The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by
	the appropriate interleaving of content from n ODUC signal instances.		the appropriate interleaving of content from n ODUC signal instances.
	The ODUC frames have the same structure as a standard ODU -- in the		The ODUC frames have the same structure as a standard ODU -- in the
	sense that it has the same Overhead (OH) area, and the payload area		sense that it has the same Overhead area, and the payload area -- but
	-- but has a higher rate since its payload area can embed an ODU4		has a higher rate since its payload area can embed an ODU4 signal.
	signal.
	The ODUCn signals have a rate that is captured in Table 1.		The ODUCn signals have a rate that is captured in Table 1.
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	| ODU Type | ODU Bit Rate |		| ODU Type | ODU Bit Rate |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	| ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 |		| ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 |
	| | kbit/s |		| | kbit/s |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	Table 1: ODUCn rates		Table 1: ODUCn rates
	The ODUCn is a multiplex section ODU signal, and is mapped into an		The ODUCn is a multiplex section ODU signal, and is mapped into an
	OTUCn signal which provides the regenerator section layer. In some		OTUCn signal which provides the regenerator section layer. In some
	scenarios, the ODUCn, and OTUCn signals will be co-terminous, i.e.		scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e.
	they will have identical source/sink locations. [ITU-T_G709_2016]		they will have identical source/sink locations. [ITU-T_G709_2016]
	and [ITU-T_G872] allow for the ODUCn signal to pass through a digital		and [ITU-T_G872] allow for the ODUCn signal to pass through a digital
	regenerator node which will terminate the OTUCn layer, but will pass		regenerator node which will terminate the OTUCn layer, but will pass
	the regenerated (but otherwise untouched) ODUCn towards a different		the regenerated (but otherwise untouched) ODUCn towards a different
	OTUCn interface where a fresh OTUCn layer will be initiated (see		OTUCn interface where a fresh OTUCn layer will be initiated (see
	Figure 2). In this case, the ODUCn is carried by 3 OTUCn segments.		Figure 2). In this case, the ODUCn is carried by 3 OTUCn segments.
	Specifically, the OPUCn signal flows through these regenerators		Specifically, the OPUCn signal flows through these regenerators
	unchanged. That is, the set of client signals, their TPNs, trib-slot		unchanged. That is, the set of client signals, their TPNs, trib-slot
	allocation remains unchanged. Note however that the ODUCn Overhead		allocation remains unchanged. The ODUCn Overhead might be modified
	(OH) might be modified if TCM sub-layers are instantiated in order to		if TCM sub-layers are instantiated in order to monitor the
	monitor the performance of the repeater hops. In this sense, the		performance of the regenerator hops. In this sense, the ODUCn should
	ODUCn should not be seen as a general ODU which can be switched via		NOT be seen as a general ODU which can be switched via an ODUk cross-
	an ODUk cross-connect.		connect.
	==================================================================		==================================================================
	+--------+ +--------+ +--------+ +--------+		+--------+ +--------+
	| +-----------+ | | +----------+ |		| +-----------+ |
	| OTN |-----------| OTN | | OTN |----------| OTN |		| OTN |-----------| OTN |
	| DXC +-----------+ WXC +----------------+ WXC +----------+ DXC |		| DXC +-----------+ DXC +
	| | | 3R | | 3R | | |		| | | |
	+--------+ +--------+ +--------+ +--------+		+--------+ +--------+
	<--------------------------------ODUCn------------------------------>		<--------ODUCn------->
	<------------------> <-----------------------> <------------------>		<-------OTUCn------>
	OTUCn OTUCn OTUCn
			+--------+ +--------+ +--------+ +--------+
			| +--------+ | | +----------+ |
			| OTN |--------| OTN | | OTN |----------| OTN |
			| DXC +--------+ WXC +--------+ WXC +----------+ DXC |
			| | | 3R | | 3R | | |
			+--------+ +--------+ +--------+ +--------+
			<-------------------------ODUCn-------------------------->
			<---------------> <---------------> <------------------>
			OTUCn OTUCn OTUCn
	==================================================================		==================================================================
	Figure 2: ODUCn signal		Figure 2: ODUCn signal
	3.3. OTUCn-M		3.3. OTUCn-M
	The standard OTUCn signal has the same rate as that of the ODUCn		The standard OTUCn signal has the same rate as that of the ODUCn
	signal as captured in Table 1. This implies that the OTUCn signal		signal as captured in Table 1. This implies that the OTUCn signal
	can only be transported over wavelength groups which have a total		can only be transported over wavelength groups which have a total
	capacity of multiples of (approximately) 100G. Modern DSPs support a		capacity of multiples of (approximately) 100G. Modern DSPs support a
	variety of bit rates per wavelength, depending on the reach		variety of bit rates per wavelength, depending on the reach
	requirements for the optical link. In other words, it is possible to		requirements for the optical link. In other words, it is possible to
	extend the reach of an optical link (i.e. increase the physical		extend the reach of an optical link (i.e. increase the physical
	distance covered) by lowering the bitrate of the client signal that		distance covered) by lowering the bitrate of the client signal that
	is modulated onto the carrier(s). By the very nature of the OTUCn		is modulated onto the optical signals. By the very nature of the
	signal, it is constrained to rates which are multiples of		OTUCn signal, it is constrained to rates which are multiples of
	(approximately) 100G. If it so happens that the total rate of the		(approximately) 100G. If it happens that the total rate of the LO-
	LO-ODUs carried over the ODUCn is smaller than n X 100G, it is		ODUs carried over the ODUCn is smaller than n X 100G, it is possible
	possible to "crunch" the OTUCn to remove the unused capacity. With		to "crunch" the OTUCn to remove the unused capacity. With this in
	this in mind, ITU-T supports the notion of a reduced rate OTUCn		mind, ITU-T supports the notion of a reduced rate OTUCn signal,
	signal, termed the OTUCn-M. The OTUCn-M signal is derived from the		termed the OTUCn-M. The OTUCn-M signal is derived from the OTUCn
	OTUCn signal by retaining all the n instances of overhead (one per		signal by retaining all the n instances of overhead (one per OTUC
	OTUC slice) but only M tributary slots of capacity.		slice) but only M tributary slots of capacity.
	3.4. Time Slot Granularity		3.4. Time Slot Granularity
	[ITU-T_G709_2012] introduced the support for 1.25G granular tributary		[ITU-T_G709_2012] introduced the support for 1.25G granular tributary
	slots in OPU2, OPU3, and OPU4 signals. With the introduction of		slots in OPU2, OPU3, and OPU4 signals. With the introduction of
	higher rate signals, it is no longer practical for the optical		higher rate signals, it is not practical for the optical networks
	networks (and the datapath hardware) to support a very large number		(and the data plane hardware) to support a very large number of
	of flows at such a fine granularity. ITU-T has defined the OPUC with		connections at such a fine granularity. ITU-T has defined the OPUC
	a tributary slot granularity of 5G. This means that the ODUCn signal		with a tributary slot granularity of 5G. This means that the ODUCn
	has 20*n tributary slots (of 5Gbps capacity). It is worthwhile		signal has 20*n tributary slots (of 5Gbps capacity). It is
	considering that the range of tributary port number (TPN) is 10*n,		worthwhile considering that the range of tributary port number (TPN)
	and not 20*n which would allow for a different client signal to be		is 10*n instead of 20*n, which restricts the maximum client signals
	carried in each TS. As an example, it will not be possible to embed		that could be carried over one single ODUC1.
	15 5G ODUflex signals in a ODUC1.
	3.5. Structure of OPUCn MSI with Payload type 0x22		3.5. Structure of OPUCn MSI with Payload type 0x22
	As mentioned above, the OPUCn signal has 20*n 5G tributary slots.		As mentioned above, the OPUCn signal has 20*n 5G tributary slots.
	The OPUCn contains n PSI structures, one per OPUC instance. The PSI		The OPUCn contains n PSI structures, one per OPUC instance. The PSI
	structure consists of the Payload Type (of 0x22), followed by a		structure consists of the Payload Type (of 0x22), followed by a
	Reserved Field (1 byte), followed by the MSI. The OPUCn MSI field		Reserved Field (1 byte) and the MSI. The OPUCn MSI field has a fixed
	has a fixed length of 40*n bytes and indicates the availability of		length of 40*n bytes and indicates the availability of each TS. Two
	each TS. Two bytes are used for each of the 20*n tributary slots,		bytes are used for each of the 20*n tributary slots, and each such
	and each such information structure has the following format		information structure has the following format ([ITU-T_G709_2016]
	([ITU-T_G709_2016] G.709:Section 20.4.1):		G.709:Section 20.4.1):
	a. The TS availability bit 1 indicates if the tributary slot is		a. The TS availability bit indicates if the tributary slot is
	available or unavailable		available or unavailable
	b. The TS occupation bit 9 indicates if the tributary slot is		b. The TS occupation bit indicates if the tributary slot is
	allocated or unallocated		allocated or unallocated
	c. b.c. The tributary port # in bits 2 to 8 and 10 to 16 indicates		c. The tributary port bits indicates the port number of the client
	the port number of the client that is being carried in this		signal that is being carried in this specific TS. A flexible
	specific TS; a flexible assignment of tributary port to tributary		assignment of tributary port to tributary slots is possible.
	slots is possible. Numbering of tributary ports are is from 1 to		Numbering of tributary ports is from 1 to 10n.
	10n.
	3.6. Client Signal Mappings		3.6. Client Signal Mappings
	The approach taken by the ITU-T to map non-OTN client signals to the		The approach taken by the ITU-T to map non-OTN client signals to the
	appropriate ODU containers is as follows:		appropriate ODU containers is as follows:
	a. All client signals with rates less than 100G are mapped as		a. All client signals with rates less than 100G are mapped into ODU
	specified in [ITU-T_G709_2016]:Clause 17. These mappings are		container as specified in clause 17 of [ITU-T_G709_2016]. These
	identical to those specified in the earlier revision of G.709		mappings are identical to those specified in the earlier revision
	[ITU-T_G709_2012]. Thus, for example, the 1000BASE-X/10GBASE-R		of G.709 [ITU-T_G709_2012]. For example, the 1000BASE-
	signals are mapped to ODU0/ODU2e respectively (see Table 2 --		X/10GBASE-R signals are mapped to ODU0/ODU2e respectively (see
	based on Table 7-2 in [ITU-T_G709_2016])		Table 2 -- based on Table 7-2 in [ITU-T_G709_2016])
	b. Always map the new and emerging client signals to ODUflex signals		b. New emerging client signals are usually mapped into ODUflex
	of the appropriate rates (see Table 2 -- based on Table 7-2 in		signals of the appropriate rates (see Table 2 according to the
	[ITU-T_G709_2016])		Table 7-2 in [ITU-T_G709_2016])
	c. Drop support for ODU Virtual Concatenation. This simplifies the		c. ODU Virtual Concatenation is not supported any more. This
	network, and the supporting hardware since multiple different		simplifies the network, and the supporting hardware since
	mappings for the same client are no longer necessary. Note that		multiple different mappings for the same client are no longer
	legacy implementations that transported sub-100G clients using		necessary. Note that legacy implementations that transported
	ODU VCAT shall continue to be supported.		sub-100G clients using ODU VCAT shall continue to be supported.
	d. ODUflex signals are low-order signals only. If the ODUflex		d. ODUflex signals are low-order signals only. If the ODUflex
	entities have rates of 100G or less, they can be transported		entities have rates of 100G or less, they can be transported over
	using either an ODUk (k=1..4) or an ODUCn server layer. On the		either an ODUk (k=1..4) or an ODUCn. For ODUflex connections
	other hand, ODUflex connections with rates greater than 100G will		with rates greater than 100G, ODUCn is required.
	require the server layer to be ODUCn. The ODUCn signals must be
	adapted to an OTUCn signal. Figure 3 illstrates the hierarchy of
	the digital signals defined in [ITU-T_G709_2016].
	+----------------+--------------------------------------------------+		+----------------+--------------------------------------------------+
	| ODU Type | ODU Bit Rate |		| ODU Type | ODU Bit Rate |
	+----------------+--------------------------------------------------+		+----------------+--------------------------------------------------+
	| ODU0 | 1,244,160 Kbps |		| ODU0 | 1,244,160 Kbps |
	| ODU1 | 239/238 x 2,488,320 Kbps |		| ODU1 | 239/238 x 2,488,320 Kbps |
	| ODU2 | 239/237 x 9,953,280 Kbps |		| ODU2 | 239/237 x 9,953,280 Kbps |
	| ODU2e | 239/237 x 10,312,500 Kbps |		| ODU2e | 239/237 x 10,312,500 Kbps |
	| ODU3 | 239/236 x 39,813,120 Kbps |		| ODU3 | 239/236 x 39,813,120 Kbps |
	| ODU4 | 239/227 x 99,532,800 Kbps |		| ODU4 | 239/227 x 99,532,800 Kbps |
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	+------------+		+------------+
	==================================================================		==================================================================
	Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1)		Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1)
	4. Applicability and GMPLS Implications		4. Applicability and GMPLS Implications
	4.1. Applicability and Challenges		4.1. Applicability and Challenges
	Two typical scenarios are depicted in Appendix XIII of		This section analyzes the OTUCn deployment scenarios to identify
	[ITU-T_G709_2016], which are also introduced into this document to		potential extensions to GMPLS that would be needed. When OTUCn links
	help analyze the potential extension to GMPLS needed. Though these		are established between line ports of two different network elements,
	two scenarios are mainly introduced in G.709 to describe OTUCn sub		two scenarios are possible. These scenarios are modeled according to
	rates application, they can also be used to describe general OTUCn		those illustrated in Appendix XIII of [ITU-T_G709_2016]. Note that
	application. One thing that should be note is these two scenarios		while this Appendix illustrates OTUCn subrating possibilities, the
	are a little different from those described in [ITU-T_G709_2016], as		scenarios serve a more general purpose also. Two possible
	the figure in this section include the OTSi(G) in to facilitate the		realization of OTUCn realizations between nodes are:
	description of the challenge brought by [ITU-T_G709_2016].
	The first scenarios is depicted in Figure 4. This scenario deploys
	OTUCn/OTUCn-M between two line ports connecting two L1/L0 ODU cross
	connects (XC) within one optical transport network. One OTUCn is
	actually carried by one OTSi(G) or OTSiA.
	As defined in [ITU-T_G872], OTSiG is used to represent one or more
	OTSi as a group to carry a single client signal (e.g., OTUCn). The
	OTSiG may have non-associated overhead, the combination of the OTSiG
	and OTSiG-O is represented by the OTSiA management/control
	abstraction.
	In this scenario, it is clear that the OTUCn and ODUCn link can be		a. The first scenario (see Figure 4) deploys OTUCn/OTUCn-M between
	automatically established, after/together with the setup of OTSi(G)		two line ports connecting two L1/L0 ODU cross connects (XC)
	or OTSiA, as both OTUCn and ODUCn perform section layer only. One		within one optical transport network. As defined in
	client OTUCn signal is carried by one single huge OTSi signal or a		[ITU-T_G807], the OTUCn/OTUCn-M signal is transported using by
	group of OTSi. There is a 1:1 mapping relationship between OTUCn and		one OTSiG, which could be comprised of one or more OTSi. The
	OTSi(G) or OTSiA.		OTSiG may have non-associated overhead (denoted as OTSiG-O); the
			combination of the OTSiG and OTSiG-O is represented by the OTSiA
			management/control abstraction. There is a 1:1 mapping
			relationship between OTUCn and OTSiG or OTSiA. For example, a
			400G OTUC4 signal can be carried over a single OTSi signal with a
			400G capcity, or perhaps split into 4 100G digital information
			streams each of which is carried over a OTSi signal with a 100G
			capacity. In this scenario, it is clear that the OTUCn and ODUCn
			link can be automatically established, after/together with the
			setup of OTSiG or OTSiA, as both OTUCn and ODUCn perform section
			layer only. Once the ODUCn link is automatically established, it
			can be advertized as a TE-link and used for setting up ODUk/
			ODUflex connections.
	For example, one 400G OTUCn signal can be carried by one single 400G		b. The second scenario (see depicted in Figure 5) deploys OTUCn/
	OTSi signal or one 400G OTUCn signal can be split into 4 different		OTUCn-M between transponders which are in a different domain B,
	OTUC instances, with each instances carried by one OTSi. Those four		and are separated from the L1 ODU XCs in domain A and/or C. In
	OTSi function as a group to carry a single 400G OTUCn signal.		this scenario, the end-to-end ODUCn is actually supported by
			three different OTUCn or OTUCn-M segments, which are in turn
			carried by their respective OTSi(G) or OTSiA. In this example,
			the OTUCn links will be established automatically after/together
			with the setup of OTSi(G) or OTSiA. Note that until both
			transponder nodes in domain B have been configured, the ODUCn
			signal transmitted by node A doesn't reach node C. Until all the
			required configuration operations are completed, the ODUCn.STAT
			field will reflect the AIS (i.e. error) status. Once all the
			provisioning has been performed in domain B, and the links
			connecting the edge nodes to transponders in domain B are error
			free, the end to end ODUCn flows will be established. In this
			case, the receipt of a normal value for the ODUCn.STAT field can
			trigger the creation of the ODUCn link.
	==================================================================		==================================================================
	+--------+ +--------+		+--------+ +--------+
	| +---------------------+ |		| +---------------------+ |
	| OTN |---------------------| OTN |		| OTN |---------------------| OTN |
	| XC +---------------------+ XC |		| XC +---------------------+ XC |
	| | | |		| | | |
	+--------+ +--------+		+--------+ +--------+
	<---------- ODUk/ODUflex ----------->		<---------- ODUk/ODUflex ----------->
	<------------ ODUCn -------------->		<------------ ODUCn -------------->
	<------- OTUCn/OTUCn-M --------->		<------- OTUCn/OTUCn-M --------->
	<--------OTSi(G)/OTSiA--------->		<--------OTSi(G)/OTSiA--------->
	==================================================================		==================================================================
	Figure 4: Scenario A		Figure 4: Scenario A
	The second scenarios is depicted in Figure 4. This scenario deploys
	OTUCn/OTUCn-M between transponders which are in a different domain B,
	which are separated from the L1 ODU XCs in domain A and/or C. one
	end-to-end ODUCn is actually supported by three different OTUCn or
	OTUCn-M segments, which are in turn carried by OTSi(G) or OTSiA.
	In the second scenario, OTUCn links will be established automatically
	after/together with the setup of OTSi(G) or OTSiA, while there are
	still some doubts about how the ODUCn link is established. In
	principle, it could/should be possible but it is not yet clear in
	details how the ODUCn link can be automatically setup.
	==================================================================		==================================================================
	+--------------------------------------+		+----------------------------+
	A | B | A or C		A | B | A or C
	| | | |		| | | |
	+--------+ | +--------+ +--------+ | +--------+		+--------+ | +--------+ +--------+ | +--------+
	| +----------|-+ | | +-|--------+ |		| +----------|-+ | | +-|--------+ |
	| OTN |----------|-| Transp | | Transp |-|--------| OTN |		| OTN |----------|-| Transp | | Transp |-|--------| OTN |
	| XC +----------|-+ onder +----------------+ onder +-|--------+ XC |		| XC +----------|-+ onder +------+ onder +-|--------+ XC |
	| | | | | | | | | |		| | | | | | | | | |
	+--------+ | +--------+ +--------+ | +--------+		+--------+ | +--------+ +--------+ | +--------+
	| |		| |
	+--------------------------------------+		+----------------------------+
	<-----------------------------ODUk/ODUflex---------------------------->		<------------------------ODUk/ODUflex----------------------->
	<----------------------------- ODUCn ------------------------------->		<------------------------ ODUCn -------------------------->
	<-------OTUCn-------><-----OTUCn/OTUCn-M-----><-------OTUCn------->		<------OTUCn------><---OTUCn/OTUCn-M---><------OTUCn------>
	<--OTSi(G)/OTSiA--> <----OTSi(G)/OTSiA----> <--OTSi(G)/OTSiA-->		<-OTSi(G)/OTSiA-> <--OTSi(G)/OTSiA--> <-OTSi(G)/OTSiA->
	==================================================================		==================================================================
	Figure 5: Scenario B		Figure 5: Scenario B
	According to the above description, it can be concluded that some
	uncertainty about setup of ODUCn link still exist, and this
	uncertainty may have relationship with the progress in ITU-T. Based
	on the analysis, it is suggested that the scope of this draft should
	mainly focus on how to set up ODUk/ODUflex LSPs over ODUCn links, as
	also indicated in the figure above.
	4.2. GMPLS Implications and Applicability		4.2. GMPLS Implications and Applicability
	4.2.1. TE-Link Representation		4.2.1. TE-Link Representation
	Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with		Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with
	TE-Links in GMPLS. Similar to that, ODUCn links can also be		TE-Links in GMPLS. Similar to that, ODUCn links can also be
	represented as TE-Links, which can be seen in the figure below.		represented as TE-Links, which can be seen in the figure below.
	==================================================================		==================================================================
	3R 3R		+-----+ +-----+
	+--------+ +--------+ +--------+ +--------+		| | | |
	| | | | | | | |		| A |<-OTUCn Link->| B |
	| node A |<-OTUCn Link->| node B |<-OTUCn Link->| node C |<-OTUCn Link->| node D |		| | | |
	| | | | | | | |		+-----+ +-----+
	+--------+ +--------+ +--------+ +--------+		|<--- ODUCn Link -->|
	|<--------------------------- ODUCn Link -------------------------->|		|<---- TE-Link ---->|
	|<----------------------------- TE-Link --------------------------->|
			3R 3R
			+-----+ +-----+ +-----+ +-----+
			| | | | | | | |
			| A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D |
			| | | | | | | |
			+-----+ +-----+ +-----+ +-----+
			|<----------------------- ODUCn Link ------------------------>|
			|<------------------------ TE-Link -------------------------->|
	==================================================================		==================================================================
	Figure 6: telink		Figure 6: ODUCn TE-Links
	Two ends of a TE-Link is able to know whether the TE-Link is		Two endpoints of a TE-Link are configured with the supported resource
	supported by an ODUCn or an ODUk or an OTUk, as well as the resource		information, which may include whether the TE-Link is supported by an
	related information (e.g., slot granularity, number of tributary slot		ODUCn or an ODUk or an OTUk, as well as the link attribute
			information (e.g., slot granularity, number of tributary slot
	available).		available).
	4.2.2. Implications and Applicability for GMPLS Signalling		4.2.2. Implications and Applicability for GMPLS Signalling
	Once the ODUCn link is configured, the GMPLS mechanisms defined in		Once the ODUCn link is configured, the GMPLS mechanisms defined in
	RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes.		RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes.
	As the resource on the ODUCn link which can be seen by the client		As the resource on the ODUCn link which can be seen by the client
	ODUk/ODUflex is a serial of 5G slots, the label defined in RFC7139 is		ODUk/ODUflex is a set of 5G slots, the label defined in RFC7139 is
	able to accommodate the requirement of the setup of ODUk/ODUflex over		able to accommodate the requirement of the setup of ODUk/ODUflex over
	ODUCn link. The OTN-TDM GENERALIZED_LABEL object is used to indicate		ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is
	how the LO ODUj signal is multiplexed into the HO ODUk link. The LO		used to indicate how the LO ODUj signal is multiplexed into the HO
	ODUj Signal Type is indicated by Traffic Parameters, while the type		ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object
	of HO ODUk link is identified by the selected interface carried in		is used to indicate how the ODUk signal is multiplexed into the ODUCn
	the IF_ID RSVP_HOP object. IF_ID RSVP_HOP object provides a pointer		link. The ODUk Signal Type is indicated by Traffic Parameters. The
	to the interface associated with TE-Link and therefore the two nodes		IF_ID RSVP_HOP object provides a pointer to the interface associated
	terminating the TE-link know (by internal/local configuration) the		with TE-Link and therefore the two nodes terminating the TE-link know
	attributes of ODUCn TE-Link.		(by internal/local configuration) the attributes of the ODUCn TE
			Link.
	One thing should be note is the TPN used in RFC7139 and defined in		One thing should be note is the TPN used in RFC7139 and defined in
	G.709-2016 for ODUCn link. Since the TPN currently defined in G.709		G.709-2016 for ODUCn link. Since the TPN currently defined in G.709
	for ODUCn link has 14 bits, while this field in RFC7139 only has 12		for ODUCn link has 14 bits, while this field in RFC7139 only has 12
	bits, some extension work is needed, but this is not so urgent since		bits, some extension work is needed, but this is not so urgent since
	for today networks scenarios 12 bits are enough, as it can support a		for today networks scenarios 12 bits are enough, as it can support a
	single ODUCn link up to n=400, namely 40Tbit.		single ODUCn link up to n=400, namely 40Tbit.
	An example is given below to illustrate the label format defined in		An example is given below to illustrate the label format defined in
	RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G		RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G
	skipping to change at page 14, line 35 ¶		skipping to change at page 14, line 46 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0| Padding Bits(0) |		|0 0 0 0 0 0 0 0| Padding Bits(0) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	==================================================================		==================================================================
	Figure 7: Label format		Figure 7: Label format
	4.2.3. Implications and Applicability for GMPLS Routing		4.2.3. Implications and Applicability for GMPLS Routing
	For routing, we think that no extension to current mechanisms defined		For routing, it is deemed that no extension to current mechanisms
	in RFC7138 are needed. Because, once one ODUCn link is up, we need		defined in RFC7138 are needed. Because, once an ODUCn link is up,
	to advertise only the resources that can be used on this ODUCn link		the resources that need to be advertised are the resources that
	and the multiplexing hierarchy on this link. Considering ODUCn link		exposed by this ODUCn link and the multiplexing hierarchy on this
	is already configured, it's the ultimate hierarchy of this		link. Since the ODUCn link is the ultimate hierarchy of the ODU
	multiplexing, there is no need to explicitly extent the ODUCn signal		multiplexing, there is no need to explicitly define a new value to
	type in the routing.		represent the ODUCn signal type in the OSPF-TE routing protocol.
	The OSPF-TE extension defined in section 4 of RFC7138 can be used to		The OSPF-TE extension defined in section 4 of RFC7138 can be reused
	advertise the resource information on the ODUCn link to direct the		to advertise the resource information on the ODUCn link to help
	setup of ODUk/ODUflex.		finish the setup of ODUk/ODUflex.
	5. Acknowledgements		5. Acknowledgements
	6. Authors (Full List)		6. Authors (Full List)
	Qilei Wang (editor)		Qilei Wang (editor)
	ZTE		ZTE
	Nanjing, China		Nanjing, China
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 16 ¶
	Akshaya Nadahalli, Individual, nadahalli@gmail.com		Akshaya Nadahalli, Individual, nadahalli@gmail.com
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		9. Security Considerations
	None.		None.
	10. References		10. Normative References
	10.1. Normative References
	[ITU-T_G709.1]		[ITU-T_G709.1]
	ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;		ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
	2016", , 2016.		2016", , 2016.
	[ITU-T_G709_2012]		[ITU-T_G709_2012]
	ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;		ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
	02/2012", http://www.itu.int/rec/T-REC-		02/2012", http://www.itu.int/rec/T-REC-
	G..709-201202-S/en, February 2012.		G..709-201202-S/en, February 2012.
	[ITU-T_G709_2016]		[ITU-T_G709_2016]
	ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;		ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
	07/2016", http://www.itu.int/rec/T-REC-		07/2016", http://www.itu.int/rec/T-REC-
	G..709-201606-P/en, July 2016.		G..709-201606-P/en, July 2016.
			[ITU-T_G807]
			ITU-T, "ITU-T G.807: Generic functional architecture of
			the optical media network;
			2020", http://www.itu.int/rec/T-REC-G.872/en, February
			2020.
	[ITU-T_G872]		[ITU-T_G872]
	ITU-T, "ITU-T G.872: The Architecture of Optical Transport		ITU-T, "ITU-T G.872: The Architecture of Optical Transport
	Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en,		Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en,
	January 2017.		January 2017.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Extensions for G.709 Optical
	Transport Networks Control", RFC 4328,
	DOI 10.17487/RFC4328, January 2006,
	<https://www.rfc-editor.org/info/rfc4328>.
	[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and		[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
	J. Drake, "Traffic Engineering Extensions to OSPF for		J. Drake, "Traffic Engineering Extensions to OSPF for
	GMPLS Control of Evolving G.709 Optical Transport		GMPLS Control of Evolving G.709 Optical Transport
	Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,		Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
	<https://www.rfc-editor.org/info/rfc7138>.		<https://www.rfc-editor.org/info/rfc7138>.
	[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,		[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
	and K. Pithewan, "GMPLS Signaling Extensions for Control		and K. Pithewan, "GMPLS Signaling Extensions for Control
	of Evolving G.709 Optical Transport Networks", RFC 7139,		of Evolving G.709 Optical Transport Networks", RFC 7139,
	DOI 10.17487/RFC7139, March 2014,		DOI 10.17487/RFC7139, March 2014,
	<https://www.rfc-editor.org/info/rfc7139>.		<https://www.rfc-editor.org/info/rfc7139>.
	10.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	[I-D.izh-ccamp-flexe-fwk]		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Hussain, I., Valiveti, R., Pithewan, K., Wang, Q.,
	Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z.,
	zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q.
	Zhong, "GMPLS Routing and Signaling Framework for Flexible
	Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in
	progress), October 2016.
	Authors' Addresses		Authors' Addresses
	Qilei Wang (editor)		Qilei Wang (editor)
	ZTE		ZTE Corporation
	Nanjing		Nanjing
	CN		CN
	Email: wang.qilei@zte.com.cn		Email: wang.qilei@zte.com.cn
	Radha Valiveti (editor)		Radha Valiveti (editor)
	Infinera Corp		Infinera Corp
	Sunnyvale		Sunnyvale
	USA		USA
End of changes. 61 change blocks.
	252 lines changed or deleted		239 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/