draft-ietf-ccamp-gmpls-otn-b100g-applicability-02.txt		draft-ietf-ccamp-gmpls-otn-b100g-applicability-03.txt
	Internet Engineering Task Force Q. Wang, Ed.		Internet Engineering Task Force Q. Wang, Ed.
	Internet-Draft ZTE Corporation		Internet-Draft ZTE Corporation
	Intended status: Informational R. Valiveti, Ed.		Intended status: Informational R. Valiveti, Ed.
	Expires: September 7, 2020 Infinera Corp		Expires: May 5, 2021 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
	March 6, 2020		November 1, 2020
	Applicability of GMPLS for B100G Optical Transport Network		Applicability of GMPLS for B100G Optical Transport Network
	draft-ietf-ccamp-gmpls-otn-b100g-applicability-02		draft-ietf-ccamp-gmpls-otn-b100g-applicability-03
	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 signalling mechanisms to set up ODUk (e.g.,
	as a result of the introduction of OTU/ODU links with rates larger		ODUflex) LSP over ODUCn links, as defined in the 2016 version of
	than 100G in the 2016 version of G.709.		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 September 7, 2020.		This Internet-Draft will expire on May 5, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	2. OTN terminology used in this document . . . . . . . . . . . . 3		2. OTN terminology used in this document . . . . . . . . . . . . 3
	3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4		3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 3
	3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Time Slot Granularity . . . . . . . . . . . . . . . . . . 7
	3.4. Time Slot Granularity . . . . . . . . . . . . . . . . . . 8		3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 7
	3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8		3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 8
	3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 8		4. GMPLS Implications and Applicability . . . . . . . . . . . . 9
	4. Applicability and GMPLS Implications . . . . . . . . . . . . 10		4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 9
	4.1. Applicability and Challenges . . . . . . . . . . . . . . 10		4.2. Implications and Applicability for GMPLS Signalling . . . 10
	4.2. GMPLS Implications and Applicability . . . . . . . . . . 12		4.3. Implications and Applicability for GMPLS Routing . . . . 11
	4.2.1. TE-Link Representation . . . . . . . . . . . . . . . 12		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.2. Implications and Applicability for GMPLS Signalling . 13		6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 12
	4.2.3. Implications and Applicability for GMPLS Routing . . 14		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 15		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	10. Normative References . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The current GMPLS routing [RFC7138] and signaling extensions		The current GMPLS routing [RFC7138] and signalling [RFC7139]
	[RFC7139] only supports the control of OTN signals and capabilities		extensions support the control of OTN signals and capabilities that
	that were defined in the 2012 version of G.709 [ITU-T_G709_2012].		were defined in the 2012 version of G.709 [ITU-T_G709_2012].
	Since the publishment of the latest 2016 version of G.709
	[ITU-T_G709_2016], which introduces support for new higher rate ODU
	signals, termed ODUCn (which have a nominal rate of n x 100 Gbps),
	how to applied GMPLS to ODUCn case should be taken into
	consideration. As OTUCn and ODUCn only perform section layer role
	only according to the definition in G.709 [ITU-T_G709_2016], which
	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 first presents an overview of the changes introduced in
	[ITU-T_G709_2016] to motivate the present topic and then analyzes how
	the current GMPLS routing and signalling mechanisms can be utilized
	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
	For the purposes of the B100G control plane discussion, the OTN		In 2016 a new version of G.709 was published: [ITU-T_G709_2016].
	should be considered as a combination of ODU and OTSi layers. Note		This version introduces new higher rate OTU and ODU signals, termed
	that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for		OTUCn and ODUCn respectively, which have a nominal rate of n x 100
	B100G entities, and leaving it intact only for maintaining continuity		Gbit/s. According to the definition in G.709 [ITU-T_G709_2016],
	in the description of the signals with bandwidth upto 100G.		OTUCn and ODUCn perform only section layer role and ODUCn supports
			only ODUk clients. This document focuses on the use of existing
			GMPLS mechanisms to set up ODUk (e.g., ODUflex) LSP over ODUCn links,
			independently from how these links have been set up
			This document presents an overview of the OTUCn and ODUCn signals
			introduced in [ITU-T_G709_2016] and analyses how the current GMPLS
			routing and signalling mechanisms can be utilized to setup ODUk
			(e.g., ODUflex) LSPs over ODUCn links.
	This document only focuses on the control of the ODU layer. The		Note: after discussion, the authors did not see any impact of 2020
	control of the OTSi layer is out of scope of this document. But in		version of G.709 on this draft.
	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. 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. Where Cn = number of n-bit
			client data entities.
	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
	payload area. Specifically the payload area consists of M 5G		payload area. Specifically, the payload area consists of M 5G
	tributary slots (where M is strictly less than 20*n).		tributary slots (where M is strictly less than 20*n).
	e. PSI: OPU Payload structure Indicator. This is a multi-frame		e. PSI: OPU Payload Structure Indicator. This is a 256-byte signal
	message and describes the composition of the OPU signal. This		that describes the composition of the OPU signal. This field is
	field is a concatenation of the Payload type (PT) and the		a concatenation of the Payload type (PT) and the Multiplex
	Multiplex Structrure Indicator (MSI) defined below.		Structure 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 that
	a client signal that is multiplexed into an OPU. The individual		realizes a client signal which is multiplexed into an OPU. The
	clients multiplexed into the OPU payload area are distinguished		individual clients multiplexed into the OPU payload area are
	by the Tributary Port number (TPN).		distinguished by the Tributary Port number (TPN).
	g. GMP: Generic Mapping Procedure.
	h. OTSiG: The set of OTSi that supports a single digital client.
	i. OTSiA: The OTSiG together with the non-associated overhead
	(OTSiG-O).
	Detailed description of these terms can be found in [ITU-T_G709_2016]		Detailed description of these terms can be found in
	and [ITU-T_G807].		[ITU-T_G709_2016].
	3. Overview of B100G in G.709		3. Overview of the OTUCn/ODUCn in G.709
	This section provides an overview of new features in		This section provides an overview of OTUCn/ODUCn signals defined 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 100 Gbit/s,
	[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. The new OTU		decouples the rates of OTU signals from the client rate. The new OTU
	signal is called OTUCn, and this signal is defined to have a rate of		signal is called OTUCn, and this signal is defined to have a rate of
	(approximately) n*100G. The following are the key characteristics of		(approximately) n*100G. The following are the key 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)
	skipping to change at page 6, line 5 ¶		skipping to change at page 5, line 25 ¶
	| 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. |
	+--------------------------------------------------------+		+--------------------------------------------------------+
	==================================================================		==================================================================
	Figure 1: OTUCn transport possibilities		Figure 1: OTUCn transport possibilities
			3.1.1. OTUCn-M
			The standard OTUCn signal has the same rate as that of the ODUCn
			signal as shown in Table 1. This implies that the OTUCn signal can
			only be transported over wavelength groups which have a total
			capacity of multiples of (approximately) 100G. Modern DSPs support a
			variety of bit rates per wavelength, depending on the reach
			requirements for the optical path. In other words, it is possible to
			extend the reach of an optical path (i.e. increase the physical
			distance covered) by lowering the bitrate of the digital signal that
			is modulated onto the optical signals. If the total rate of the ODUk
			LSPs planned to be carried over an ODUCn link is smaller than n*100G,
			it is possible to "crunch" the OTUCn not to transmit some of unused
			timeslots. With this in mind, ITU-T supports the notion of a reduced
			rate OTUCn signal, termed the OTUCn-M. The OTUCn-M signal is derived
			from the OTUCn signal by retaining all the n instances of overhead
			(one per OTUC slice) but with only M (M is less than 20*n) OPUCn
			tributary slots available to carry ODUk LSPs.
			As the "crunching" algorithm is not standardized, knowing the value
			of M is not enough to decide the timeslot availability.
	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 area, and the payload area -- but		sense that it has the same Overhead area, and the payload area -- but
	has a higher rate since its payload area can embed an ODU4 signal.		has a higher rate since its payload area can embed an ODU4 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-terminated, 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		allows for the ODUCn signal to pass through a digital regenerator
	regenerator node which will terminate the OTUCn layer, but will pass		node which will terminate the OTUCn layer, but will pass the
	the regenerated (but otherwise untouched) ODUCn towards a different		regenerated (but otherwise untouched) ODUCn towards a different OTUCn
	OTUCn interface where a fresh OTUCn layer will be initiated (see		interface where a fresh OTUCn layer will be initiated (see Figure 2).
	Figure 2). In this case, the ODUCn is carried by 3 OTUCn segments.		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. The ODUCn Overhead might be modified		allocation remains unchanged. The ODUCn Overhead might be modified
	if TCM sub-layers are instantiated in order to monitor the		if TCM sub-layers are instantiated in order to monitor the
	performance of the regenerator hops. In this sense, the ODUCn should		performance of the regenerator hops. In this sense, the ODUCn should
	NOT be seen as a general ODU which can be switched via an ODUk cross-		NOT be seen as a general ODU which can be switched via an ODUk cross-
	connect.		connect.
	==================================================================		==================================================================
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 30 ¶
	| | | 3R | | 3R | | |		| | | 3R | | 3R | | |
	+--------+ +--------+ +--------+ +--------+		+--------+ +--------+ +--------+ +--------+
	<-------------------------ODUCn-------------------------->		<-------------------------ODUCn-------------------------->
	<---------------> <---------------> <------------------>		<---------------> <---------------> <------------------>
	OTUCn OTUCn OTUCn		OTUCn OTUCn OTUCn
	==================================================================		==================================================================
	Figure 2: ODUCn signal		Figure 2: ODUCn signal
	3.3. OTUCn-M		3.3. Time Slot Granularity
	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
	can only be transported over wavelength groups which have a total
	capacity of multiples of (approximately) 100G. Modern DSPs support a
	variety of bit rates per wavelength, depending on the reach
	requirements for the optical link. In other words, it is possible to
	extend the reach of an optical link (i.e. increase the physical
	distance covered) by lowering the bitrate of the client signal that
	is modulated onto the optical signals. By the very nature of the
	OTUCn signal, it is constrained to rates which are multiples of
	(approximately) 100G. If it happens that the total rate of the LO-
	ODUs carried over the ODUCn is smaller than n X 100G, it is possible
	to "crunch" the OTUCn to remove the unused capacity. With this in
	mind, ITU-T supports the notion of a reduced rate OTUCn signal,
	termed the OTUCn-M. The OTUCn-M signal is derived from the OTUCn
	signal by retaining all the n instances of overhead (one per OTUC
	slice) but only M tributary slots of capacity.
	3.4. Time Slot Granularity
	[ITU-T_G709_2012] introduced the support for 1.25G granular tributary		[ITU-T_G709_2012] has introduced the support for 1.25G granular
	slots in OPU2, OPU3, and OPU4 signals. With the introduction of		tributary slots in OPU2, OPU3, and OPU4 signals. With the
	higher rate signals, it is not practical for the optical networks		introduction of higher rate signals, it is not practical for the
	(and the data plane hardware) to support a very large number of		optical networks (and the data plane hardware) to support a very
	connections at such a fine granularity. ITU-T has defined the OPUC		large number of connections at such a fine granularity. [ITU-
	with a tributary slot granularity of 5G. This means that the ODUCn		T_G709_2012] has defined the OPUC with a 5G tributary slot
	signal has 20*n tributary slots (of 5Gbps capacity). It is		granularity. This means that the ODUCn signal has 20*n tributary
	worthwhile considering that the range of tributary port number (TPN)		slots (of 5 Gbit/s capacity). It is worthwhile considering that the
	is 10*n instead of 20*n, which restricts the maximum client signals		range of tributary port number (TPN) is 10*n instead of 20*n, which
	that could be carried over one single ODUC1.		restricts the maximum client signals that could be carried over one
			single ODUC1.
	3.5. Structure of OPUCn MSI with Payload type 0x22		3.4. 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 MSI field has a fixed length of 40*n bytes and indicates
	structure consists of the Payload Type (of 0x22), followed by a		the availability and occupation of each TS. Two bytes are used for
	Reserved Field (1 byte) and the MSI. The OPUCn MSI field has a fixed		each of the 20*n tributary slots, and each such information structure
	length of 40*n bytes and indicates the availability of each TS. Two		has the following format ([ITU-T_G709_2016] G.709:Section 20.4.1):
	bytes are used for each of the 20*n tributary slots, and each such
	information structure has the following format ([ITU-T_G709_2016]
	G.709:Section 20.4.1):
	a. The TS availability bit 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 indicates if the tributary slot is		b. The TS occupation bit indicates if the tributary slot is
	allocated or unallocated		allocated or unallocated
	c. The tributary port bits indicates the port number of the client		c. The tributary port number (14 bits) of the client signal that is
	signal that is being carried in this specific TS. A flexible		being carried in this specific TS. A flexible assignment of
	assignment of tributary port to tributary slots is possible.		tributary port to tributary slots is possible. Numbering of
	Numbering of tributary ports is from 1 to 10n.		tributary ports is from 1 to 10*n.
	3.6. Client Signal Mappings		3.5. 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 into ODU		a. All client signals are mapped into an ODUk (e.g., ODUflex) as
	container as specified in clause 17 of [ITU-T_G709_2016]. These		specified in clause 17 of [ITU-T_G709_2016].
	mappings are identical to those specified in the earlier revision
	of G.709 [ITU-T_G709_2012]. For example, the 1000BASE-
	X/10GBASE-R signals are mapped to ODU0/ODU2e respectively (see
	Table 2 -- based on Table 7-2 in [ITU-T_G709_2016])
	b. New emerging client signals are usually mapped into ODUflex
	signals of the appropriate rates (see Table 2 according to the
	Table 7-2 in [ITU-T_G709_2016])
	c. ODU Virtual Concatenation is not supported any more. This		b. ODU Virtual Concatenation has been deprecated. This simplifies
	simplifies the network, and the supporting hardware since		the network, and the supporting hardware since multiple different
	multiple different mappings for the same client are no longer		mappings for the same client are no longer necessary. Note that
	necessary. Note that legacy implementations that transported		legacy implementations that transported sub-100G clients using
	sub-100G clients using ODU VCAT shall continue to be supported.		ODU VCAT shall continue to be supported.
	d. ODUflex signals are low-order signals only. If the ODUflex		c. ODUflex signals are low-order signals only. If the ODUflex
	entities have rates of 100G or less, they can be transported over		entities have rates of 100G or less, they can be transported over
	either an ODUk (k=1..4) or an ODUCn. For ODUflex connections		either an ODUk (k=1..4) or an ODUCn. For ODUflex connections
	with rates greater than 100G, ODUCn is required.		with rates greater than 100G, ODUCn is required.
	+----------------+--------------------------------------------------+
	| ODU Type | ODU Bit Rate |
	+----------------+--------------------------------------------------+
	| ODU0 | 1,244,160 Kbps |
	| ODU1 | 239/238 x 2,488,320 Kbps |
	| ODU2 | 239/237 x 9,953,280 Kbps |
	| ODU2e | 239/237 x 10,312,500 Kbps |
	| ODU3 | 239/236 x 39,813,120 Kbps |
	| ODU4 | 239/227 x 99,532,800 Kbps |
	| ODUflex for | 239/238 x Client signal Bit rate |
	| CBR client | |
	| signals | |
	| ODUflex for | Configured bit rate |
	| GFP-F mapped | |
	| packet traffic | |
	| ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= |
	| IMP mapped | 1 |
	| packet traffic | |
	| ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is |
	| FlexE aware | total number of available tributary slots among |
	| transport | all PHYs which have been crunched and combined. |
	+----------------+--------------------------------------------------+
	Note that this table doesn't include ODUCn -- since it cannot be
	generated by mapping a non-OTN signal. An ODUCn is always formed by
	multiplexing multiple LO-ODUs.
	Table 2: Types and rates of ODUs usable for client mappings
	==================================================================		==================================================================
	Clients (e.g. SONET/SDH, Ethernet)		Clients (e.g. SONET/SDH, Ethernet)
	+ + +		+ + +
	| | |		| | |
	+------------------+-------+------+------------------------+		+------------------+-------+------+------------------------+
	| OPUk |		| OPUk |
	+----------------------------------------------------------+		+----------------------------------------------------------+
	| ODUk |		| ODUk |
	+-----------------------+---------------------------+------+		+-----------------------+---------------------------+------+
	skipping to change at page 10, line 30 ¶		skipping to change at page 9, line 30 ¶
	+----------+-----------------------+		+----------+-----------------------+
	| OTLk.n | | ODUCn |		| OTLk.n | | ODUCn |
	+----------+ +------------+		+----------+ +------------+
	| OTUCn |		| OTUCn |
	+------------+		+------------+
	==================================================================		==================================================================
	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. GMPLS Implications and Applicability
	4.1. Applicability and Challenges
	This section analyzes the OTUCn deployment scenarios to identify
	potential extensions to GMPLS that would be needed. When OTUCn links
	are established between line ports of two different network elements,
	two scenarios are possible. These scenarios are modeled according to
	those illustrated in Appendix XIII of [ITU-T_G709_2016]. Note that
	while this Appendix illustrates OTUCn subrating possibilities, the
	scenarios serve a more general purpose also. Two possible
	realization of OTUCn realizations between nodes are:
	a. The first scenario (see Figure 4) deploys OTUCn/OTUCn-M between
	two line ports connecting two L1/L0 ODU cross connects (XC)
	within one optical transport network. As defined in
	[ITU-T_G807], the OTUCn/OTUCn-M signal is transported using by
	one OTSiG, which could be comprised of one or more OTSi. The
	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.
	b. The second scenario (see depicted in Figure 5) deploys OTUCn/
	OTUCn-M between transponders which are in a different domain B,
	and are separated from the L1 ODU XCs in domain A and/or C. In
	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 |
	| XC +---------------------+ XC |
	| | | |
	+--------+ +--------+
	<---------- ODUk/ODUflex ----------->
	<------------ ODUCn -------------->
	<------- OTUCn/OTUCn-M --------->
	<--------OTSi(G)/OTSiA--------->
	==================================================================
	Figure 4: Scenario A
	==================================================================
	+----------------------------+
	A | B | A or C
	| | | |
	+--------+ | +--------+ +--------+ | +--------+
	| +----------|-+ | | +-|--------+ |
	| OTN |----------|-| Transp | | Transp |-|--------| OTN |
	| XC +----------|-+ onder +------+ onder +-|--------+ XC |
	| | | | | | | | | |
	+--------+ | +--------+ +--------+ | +--------+
	| |
	+----------------------------+
	<------------------------ODUk/ODUflex----------------------->
	<------------------------ ODUCn -------------------------->
	<------OTUCn------><---OTUCn/OTUCn-M---><------OTUCn------>
	<-OTSi(G)/OTSiA-> <--OTSi(G)/OTSiA--> <-OTSi(G)/OTSiA->
	==================================================================
	Figure 5: Scenario B
	4.2. GMPLS Implications and Applicability
	4.2.1. TE-Link Representation		4.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.
	==================================================================		==================================================================
	+-----+ +-----+		+-----+ +-----+
	| | | |		| | | |
	| A |<-OTUCn Link->| B |		| A |<-OTUCn Link->| B |
	skipping to change at page 13, line 26 ¶		skipping to change at page 10, line 26 ¶
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	| | | | | | | |		| | | | | | | |
	| A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D |		| A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D |
	| | | | | | | |		| | | | | | | |
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	|<----------------------- ODUCn Link ------------------------>|		|<----------------------- ODUCn Link ------------------------>|
	|<------------------------ TE-Link -------------------------->|		|<------------------------ TE-Link -------------------------->|
	==================================================================		==================================================================
	Figure 6: ODUCn TE-Links		Figure 4: ODUCn TE-Links
	Two endpoints of a TE-Link are configured with the supported resource		Two endpoints of a TE-Link are configured with the supported resource
	information, which may include whether the TE-Link is supported by an		information, which may include whether the TE-Link is supported by an
	ODUCn or an ODUk or an OTUk, as well as the link attribute		ODUCn or an ODUk or an OTUk, as well as the link attribute
	information (e.g., slot granularity, number of tributary slot		information (e.g., slot granularity, list of available tributary
	available).		slot).
	4.2.2. Implications and Applicability for GMPLS Signalling		4.2. Implications and Applicability for GMPLS Signalling
	Once the ODUCn link is configured, the GMPLS mechanisms defined in		Once the ODUCn TE-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 set 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. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is		ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is
	used to indicate how the LO ODUj signal is multiplexed into the HO		used to indicate how the LO ODUj signal is multiplexed into the HO
	ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object		ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object
	is used to indicate how the ODUk signal is multiplexed into the ODUCn		is used to indicate how the ODUk signal is multiplexed into the ODUCn
	link. The ODUk Signal Type is indicated by Traffic Parameters. The		link. The ODUk Signal Type is indicated by Traffic Parameters. The
	IF_ID RSVP_HOP object provides a pointer to the interface associated		IF_ID RSVP_HOP object provides a pointer to the interface associated
	with TE-Link and therefore the two nodes terminating the TE-link know		with TE-Link and therefore the two nodes terminating the TE-link know
	(by internal/local configuration) the attributes of the ODUCn TE		(by internal/local configuration) the attributes of the ODUCn TE
	Link.		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 40 Tbit/s.
	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
	slots, and twenty of them are allocated to the ODU4. Along with the		slots, and twenty of them are allocated to the ODU4. Along with the
	increase of "n", the label may become lengthy, an optimized label		increase of "n", the label may become lengthy, an optimized label
	format may be needed.		format may be needed.
	==================================================================		==================================================================
	0 1 2 3		0 1 2 3
	skipping to change at page 14, line 42 ¶		skipping to change at page 11, line 42 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0|		|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0|		|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|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 5: Label format
	4.2.3. Implications and Applicability for GMPLS Routing		4.3. Implications and Applicability for GMPLS Routing
	For routing, it is deemed that no extension to current mechanisms		For routing, it is deemed that no extension to current mechanisms
	defined in RFC7138 are needed. Because, once an ODUCn link is up,		defined in RFC7138 are needed. Because, once an ODUCn link is up,
	the resources that need to be advertised are the resources that		the resources that need to be advertised are the resources that
	exposed by this ODUCn link and the multiplexing hierarchy on this		exposed by this ODUCn link and the multiplexing hierarchy on this
	link. Since the ODUCn link is the ultimate hierarchy of the ODU		link. Since the ODUCn link is the ultimate hierarchy of the ODU
	multiplexing, there is no need to explicitly define a new value to		multiplexing, there is no need to explicitly define a new value to
	represent the ODUCn signal type in the OSPF-TE routing protocol.		represent the ODUCn signal type in the OSPF-TE routing protocol.
	The OSPF-TE extension defined in section 4 of RFC7138 can be reused		The OSPF-TE extension defined in section 4 of RFC7138 can be reused
	skipping to change at page 16, line 34 ¶		skipping to change at page 13, line 34 ¶
	Email: daniele.ceccarelli@ericsson.com		Email: daniele.ceccarelli@ericsson.com
	7. Contributors		7. Contributors
	Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com		Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com
	Fatai Zhang, Huawei,zhangfatai@huawei.com		Fatai Zhang, Huawei,zhangfatai@huawei.com
	Italo Busi, Huawei,italo.busi@huawei.com		Italo Busi, Huawei,italo.busi@huawei.com
	Zheyu Fan, Individual, zheyu2008@gmail.com
	Dieter Beller, Nokia, Dieter.Beller@nokia.com		Dieter Beller, Nokia, Dieter.Beller@nokia.com
	Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn		Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn
	Zafar Ali, Cisco Systems, zali@cisco.com		Zafar Ali, Cisco Systems, zali@cisco.com
	Daniel King, d.king@lancaster.ac.uk		Daniel King, d.king@lancaster.ac.uk
	Manoj Kumar, Cisco Systems, manojk2@cisco.com		Manoj Kumar, Cisco Systems, manojk2@cisco.com
	Antonello Bonfanti, Cisco Systems, abonfant@cisco.com
	Akshaya Nadahalli, Individual, nadahalli@gmail.com		Antonello Bonfanti, Cisco Systems, abonfant@cisco.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. Normative References		10. References
	[ITU-T_G709.1]		10.1. Normative References
	ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
	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, "ITU-T G.872: The Architecture of Optical Transport
	Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en,
	January 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		10.2. Informative References
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		[ITU-T_G709.1]
			ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
			2016", , 2016.
	Authors' Addresses		Authors' Addresses
	Qilei Wang (editor)		Qilei Wang (editor)
	ZTE Corporation		ZTE Corporation
	Nanjing		Nanjing
	CN		China
	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
	Email: rvaliveti@infinera.com		Email: rvaliveti@infinera.com
	Haomian Zheng (editor)		Haomian Zheng (editor)
	Huawei		Huawei
	CN		China
	Email: zhenghaomian@huawei.com		Email: zhenghaomian@huawei.com
	Huub van Helvoort		Huub van Helvoort
	Hai Gaoming B.V		Hai Gaoming B.V
			Almere
			Netherlands
	Email: huubatwork@gmail.com		Email: huubatwork@gmail.com
	Sergio Belotti		Sergio Belotti
	Nokia		Nokia
	Email: sergio.belotti@nokia.com		Email: sergio.belotti@nokia.com
End of changes. 53 change blocks.
	310 lines changed or deleted		141 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/