Diff: rfc9376.original.xml

	rfc9376.original.xml	rfc9376.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
	raft-ietf-ccamp-gmpls-otn-b100g-applicability-15" category="info" ipr="trust2009	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
	02" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocIncl	info" consensus="true" docName="draft-ietf-ccamp-gmpls-otn-b100g-applicability-
	ude="true" version="3">	15" number="9376" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRef
		s="true" sortRefs="true" tocInclude="true" version="3">

	<!-- xml2rfc v2v3 conversion 3.12.5 -->	<!-- xml2rfc v2v3 conversion 3.12.5 -->
	<!-- Generated by id2xml 1.5.0 on 2022-05-06T01:42:23Z -->	<!-- Generated by id2xml 1.5.0 on 2022-05-06T01:42:23Z -->
	<front>	<front>

	<title abbrev="B100G Extensions">Applicability of GMPLS for Beyond 100G Opti
	cal Transport Network</title>	<title abbrev="Applicability of GMPLS beyond 100 Gbit/s OTN">Applicability o
	<seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-gmpls-otn-b100g-ap	f GMPLS for beyond 100 Gbit/s Optical Transport Network</title>
	plicability-15"/>	<seriesInfo name="RFC" value="9376"/>
	<author initials="Q." surname="Wang" fullname="Qilei Wang" role="editor">	<author initials="Q." surname="Wang" fullname="Qilei Wang" role="editor">
	<organization>ZTE Corporation</organization>	<organization>ZTE Corporation</organization>
	<address>	<address>
	<postal>	<postal>

	<street>Nanjing</street>	<city>Nanjing</city>
	<street>China</street>	<country>China</country>
	</postal>	</postal>
	<email>wang.qilei@zte.com.cn</email>	<email>wang.qilei@zte.com.cn</email>
	</address>	</address>
	</author>	</author>
	<author initials="R." surname="Valiveti" fullname="Radha Valiveti" role="edi tor">	<author initials="R." surname="Valiveti" fullname="Radha Valiveti" role="edi tor">
	<organization>Infinera Corp</organization>	<organization>Infinera Corp</organization>
	<address>	<address>
	<postal>	<postal>

	<street>Sunnyvale</street>	<city>Sunnyvale</city>
	<street>USA</street>	<region>CA</region>
		<country>United States of America</country>
	</postal>	</postal>
	<email>rvaliveti@infinera.com</email>	<email>rvaliveti@infinera.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="H." surname="Zheng" fullname="Haomian Zheng" role="editor" >	<author initials="H." surname="Zheng" fullname="Haomian Zheng" role="editor" >
	<organization>Huawei</organization>	<organization>Huawei</organization>
	<address>	<address>
	<postal>	<postal>

	<street>China</street>	<country>China</country>
	</postal>	</postal>
	<email>zhenghaomian@huawei.com</email>	<email>zhenghaomian@huawei.com</email>
	</address>	</address>
	</author>	</author>

	<author initials="H." surname="Helvoort" fullname="Huub van Helvoort">	<author initials="H." surname="van Helvoort" fullname="Huub van Helvoort">
	<organization>Hai Gaoming B.V</organization>	<organization>Hai Gaoming BV</organization>
	<address>	<address>
	<postal>	<postal>

	<street>Almere</street>	<city>Almere</city>
	<street>Netherlands</street>	<country>Netherlands</country>
	</postal>	</postal>
	<email>huubatwork@gmail.com</email>	<email>huubatwork@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="S." surname="Belotti" fullname="Sergio Belotti">	<author initials="S." surname="Belotti" fullname="Sergio Belotti">
	<organization>Nokia</organization>	<organization>Nokia</organization>
	<address>	<address>
	<email>sergio.belotti@nokia.com</email>	<email>sergio.belotti@nokia.com</email>
	</address>	</address>
	</author>	</author>

	<!--date year="2021" month="November" day="7"/-->	<date year="2023" month="March" />
	<workgroup>Internet Engineering Task Force</workgroup>	<area>rtg</area>
		<workgroup>ccamp</workgroup>
	<abstract>	<abstract>
	<t>	<t>

	This document examines the applicability of using existing GMPLS	This document examines the applicability of using existing GMPLS routing
	routing and signalling mechanisms to set up Optical Data Unit-k	and signaling mechanisms to set up Optical Data Unit-k (ODUk) Label
	(ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as	Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in
	defined in the	the 2020 version of ITU-T Recommendation G.709.</t>
	2020 version of G.709.</t>
	</abstract>	</abstract>
	</front>	</front>

	<middle>	<middle>
	<section anchor="sect-1" numbered="true" toc="default">	<section anchor="sect-1" numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>
	<t>	<t>
	The current GMPLS routing <xref target="RFC7138" format="default"/>	The current GMPLS routing <xref target="RFC7138" format="default"/>

	and signalling <xref target="RFC7139" format="default"/>	and signaling <xref target="RFC7139" format="default"/>
	extensions support the control of Optical Transport Network (OTN) signals and	extensions support the control of the Optical Transport Network (OTN) signals
	capabilities that	and capabilities that
	were defined in the 2012 version of G.709 <xref target="ITU-T_G709_2012" form	were defined in the 2012 version of ITU-T
	at="default"/>.</t>	Recommendation G.709 <xref target="ITU-T_G709_2012" format="default"/>.</t>
	<t>	<t>

	In 2016 a further version of G.709 was published: <xref target="ITU-T_G709_20	In 2016, a new version of ITU-T
	16" format="default"/>.	Recommendation G.709 was published: <xref target="ITU-T_G709_2016" format="de
	This version introduced higher rate Optical Transport Unit (OTU) and Optical	fault"/>.
	Data Unit (ODU) signals, termed OTUCn	This version introduced higher-rate Optical Transport Unit (OTU) and Optical
	and ODUCn respectively, which have a nominal rate of n x 100 Gbit/s.	Data Unit (ODU) signals, termed "OTUCn"
		and "ODUCn", respectively, which have a nominal rate of n*100 Gbit/s.
	According to the definition in <xref target="ITU-T_G709_2016" format="default "/>, OTUCn and ODUCn	According to the definition in <xref target="ITU-T_G709_2016" format="default "/>, OTUCn and ODUCn

	perform only the digital section layer role and ODUCn supports only ODUk clie nts.	perform only the digital section-layer role, and ODUCn supports only ODUk cli ents.
	This document focuses on the use of existing GMPLS mechanisms to set	This document focuses on the use of existing GMPLS mechanisms to set
	up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, indepen dently from how	up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, indepen dently from how
	these links have been set up.</t>	these links have been set up.</t>

	<t>
		<t>
	Because <xref target="ITU-T_G709_2020" format="default"/>	Because <xref target="ITU-T_G709_2020" format="default"/>
	does not introduce any new features to	does not introduce any new features to

	OTUCn and ODUCn compared to <xref target="ITU-T_G709_2016" format="default"/>	OTUCn and ODUCn compared to <xref target="ITU-T_G709_2016" format="default"/>
	, this document starts	, this document first presents an overview of the OTUCn and ODUCn signals in
	with <xref target="ITU-T_G709_2020" format="default"/>	<xref target="ITU-T_G709_2020" format="default"/>
	by first presenting an overview of the OTUCn	and then analyzes how the current GMPLS routing and signaling mechanisms can
	and ODUCn signals, and then analyzing how the current GMPLS routing	be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links.
	and signalling mechanisms can be utilized to set up ODUk (e.g.,
	ODUflex) LSPs over ODUCn links.
	</t>	</t>

	<t>	<t>

	This document assumes that the reader is familiar with OTN, GMPLS, and how	This document assumes that readers are familiar with OTN, GMPLS, and how
	GMPLS is applied in OTN networks. As such, this document doesn't provide	GMPLS is applied in OTN. As such, this document doesn't provide
	any background pertaining to OTN networks that included links with capacities	any background pertaining to OTN that include links with capacities
	of 100G or less; this background could be found in documents such as	of 100 Gbit/s or less; this background could be found in documents such as
	<xref target="RFC7062" format="default"/> and	<xref target="RFC7062" format="default"/> and
	<xref target="RFC7096" format="default"/>.	<xref target="RFC7096" format="default"/>.

	This document provides an overview of the dataplane primitives	This document provides an overview of the data plane primitives
	that enable links with capacities greater than 100G, and analyses the extensi	that enable links with capacities greater than 100 Gbit/s and analyzes the ex
	ons	tensions
	that would be required in the current GMPLS routing & signaling mechanism	that would be required in the current GMPLS routing and signaling mechanisms
	s	to support evolution in OTN.
	to support the evolution in OTN networks.
	</t>	</t>
	</section>	</section>

	<section anchor="sect-2" numbered="true" toc="default">	<section anchor="sect-2" numbered="true" toc="default">

	<name>OTN terminology used in this document</name>	<name>OTN Terminology Used in This Document</name>
	<ul spacing="normal">	<dl spacing="normal">
	<li>FlexO: Flexible OTN information structure. This information structure	<dt>FlexO:</dt>
	is usually with a specific bit rate and frame format, consisting	<dd>Flexible OTN information structure. This information structure usually
	of overhead	has a specific bitrate and frame format that consists of overhead and payload,
	and payload, which is used as a group for the transport of an OTU	which are used as a group for the transport of an OTUCn signal.
	Cn signal.</li>	</dd>
	<li>LSP: Label Switched Path. </li>	<dt>LSP:</dt>
	<li>ODU: Optical Data Unit. An ODU has the frame structure and overhead, as defi	<dd> Label Switched Path </dd>
	ned in	<dt>MSI:</dt>
		<dd>Multiplex Structure Indicator. This structure indicates the
		grouping of the tributary slots in an OPU payload area that
		realizes a client signal, which is multiplexed into an OPU. The
		individual clients multiplexed into the OPU payload area are
		distinguished by the Tributary Port Number (TPN).</dd>
		<dt>ODU:</dt>
		<dd>Optical Data Unit. An ODU has the frame structure and overhead, as defined i
		n
	Figure 12-1 of <xref target="ITU-T_G709_2020" format="default"/>.	Figure 12-1 of <xref target="ITU-T_G709_2020" format="default"/>.

	ODUs can be formed in two ways: a) by encapsulating a single non-OTN	ODUs can be formed in two ways: a) by encapsulating a single non-OTN
	client	client,
	(such as SONET/SDH, Ethernet) b) multiplexing lower-rate ODUs.	such as SONET/SDH (Synchronous Optical Network / Synchronous Digital
	In general, the ODU layer represents the path layer in OTN networks.	Hierarchy) or Ethernet, or b) by multiplexing lower-rate ODUs.
	The only	In general, the ODU layer represents the path layer in OTN. The only
	exception is the ODUCn signal (defined below) which is defined to be	exception is the ODUCn signal (defined below), which is defined to b
	a section	e a section-layer signal.
	layer signal.
	In the classification based on bitrates of the ODU signals,	In the classification based on bitrates of the ODU signals,

	ODUs are of two types: Fixed rate, and flexible rate. Flexible rate	ODUs are of two types: fixed rate and flexible rate. Flexible-rate
	ODU(s), called "ODUFlex" have a rate that is 239/238 times	ODUs, called "ODUflex", have a rate that is 239/238 times
	the bit rate of the client signal it encapsulates. </li>	the bitrate of the client signal they encapsulate. </dd>
	<li>ODUk: Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term O	<dt>ODUC:</dt>
	DUk references	<dd>Optical Data Unit-C. This signal has a bandwidth of approximately 100 Gbit/s
	to an ODU whose bit rate is fully specified by the index k. The bit	and
	rates of the	is of a slightly higher bitrate than the fixed rate ODU4 signal. This signal
	ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25G, 2.5	has the format defined in Figure 12-1 of <xref target="ITU-T_G709_2020"
	G, 10G,	format="default"/>. This signal represents the building block for
	10.3G, 40G, 100G respectively.</li>	constructing a higher-rate signal called "ODUCn" (defined below). </dd>
	<li>ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same frame st
	ructure	<dt>ODUCn:</dt>
	as a "generic" ODU, but with rate that is a fixed multiple of the bi	<dd>Optical Data Unit-Cn, where Cn indicates the bitrate of approximately n*100
	trate of the client signal it	Gbit/s.
	encapsulates. ITU-T defines specific ODUflex containers that are req	This frame structure consists of "n" interleaved frame and multiframe
	uired to transport
	specific clients such as 50GE, 200GE, 400GE, etc.</li>
	<li> ODUC: Optical Data Unit -C; this signal has a bandwidth of approximately 10
	0G,
	and is of a slightly higher bit rate than the fixed rate ODU4 signal.
	This signal has the format defined in
	Figure 12-1 of <xref target="ITU-T_G709_2020" format="default"/>.
	This signal represents the building block for constructing a higher
	rate signal called ODUCn (defined below). </li>
	<li>ODUCn: Optical Data Unit-Cn; Cn indicates the bit rate of approximately n*10
	0G.
	This frame structure consists of "n" interleaved, frame and multi-fra
	me
	synchronous instances of the ODUC signal, each of which has the forma t defined in	synchronous instances of the ODUC signal, each of which has the forma t defined in

	Figure 12-1 of <xref target="ITU-T_G709_2020" format="default"/>.</li	Figure 12-1 of <xref target="ITU-T_G709_2020" format="default"/>.</dd
	>	>
	<li>OPUC: Optical Payload Unit -C; with a payload of approximately 100G. This
	structure represents the payload area of the ODUC signal. </li>	<dt>ODUflex:</dt>
	<li>OPUCn: Optical Payload Unit-Cn. Where Cn indicates that the bit	<dd>Optical Data Unit - flexible rate. An ODUflex has the same frame structure
	rate is approximately n*100G. This structure represents the payload area	as a "generic" ODU but with a rate that is a fixed multiple of the b
	of the	itrate of the client signal it
	ODUCn signal.</li>	encapsulates. <xref target="ITU-T_G709_2020" format="default"/> defi
	<li>OTUC: Optical Transport Unit -C; with a bandwidth of approximately 100G.	nes specific ODUflex containers that are required to transport
		specific clients such as 50GE, 200GE, 400GE, etc.</dd>

		<dt>ODUk:</dt>
		<dd>Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term "ODUk"
		refers
		to an ODU whose bitrate is fully specified by the index k. The bitra
		tes of the
		ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25 Gbit/
		s, 2.5 Gbit/s, 10 Gbit/s,
		10.3 Gbit/s, 40 Gbit/s, and 100 Gbit/s, respectively.</dd>

		<dt>OPUC:</dt>
		<dd>Optical Payload Unit-C. This signal has a payload of approximately 100 Gbit/
		s. This
		structure represents the payload area of the ODUC signal. </dd>
		<dt>OPUCn:</dt>
		<dd>Optical Payload Unit-Cn, where Cn indicates that the bitrate is
		approximately n*100 Gbit/s. This structure represents the payload area of the OD
		UCn
		signal.</dd>
		<dt>OTN:</dt>
		<dd>Optical Transport Network</dd>
		<dt>OTUC:</dt>
		<dd>Optical Transport Unit-C. This signal has a bandwidth of approximately 100 G
		bit/s.
	This signal forms the building block of the OTUCn signal defined below,	This signal forms the building block of the OTUCn signal defined below,

	which has a bandwidth of approximately n*100G. </li>	which has a bandwidth of approximately n*100 Gbit/s. </dd>
	<li>OTUCn: Fully standardized Optical Transport Unit-Cn. This frame structure is
		<dt>OTUCn:</dt>
		<dd>Fully standardized Optical Transport Unit-Cn. This frame structure is
	realized by extending the ODUCn signal with the OTU layer overhead.	realized by extending the ODUCn signal with the OTU layer overhead.

	The structure of this signal is illustrated in Figure 11-1 of	The structure of this signal is illustrated in Figure 11-4 of
	<xref target="ITU-T_G709_2020" format="default"/>. Note that	<xref target="ITU-T_G709_2020" format="default"/>. Note that

	the term "fully standardized" is defined by ITU-T in	the term "fully standardized" is defined by ITU-T in Section 6.1.1 of
	<xref target="ITU-T_G709_2020" format="default"/>:Section 6.1.1.</li>	<xref target="ITU-T_G709_2020" format="default"/>.</dd>
	<li>OTUCn-M: This signal is an extension of the OTUCn signal	<dt>OTUCn-M:</dt>
	introduced above. This signal contains the same amount of	<dd>This signal is an extension of the OTUCn signal introduced above. This
	overhead as the OTUCn signal, but contains a reduced amount of	signal contains the same amount of overhead as the OTUCn signal but contains a
	payload area. Specifically, the payload area consists of M 5 Gbit/s	reduced amount of payload area. Specifically, the payload area consists of M
	tributary slots - where M is less than 20*n, which is the number	tributary slots (each 5 Gbit/s), where M is less than 20*n, which is the
	of tributary slots in the OTUCn signal. </li>	number of tributary slots in the OTUCn signal.
	<li>OTN: Optical Transport Network.</li>	</dd>
	<li>PSI: OPU Payload Structure Indicator. This is a 256-byte signal	<dt>PSI:</dt>
		<dd>Payload Structure Indicator. This is a 256-byte signal
	that describes the composition of the OPU signal. This field is	that describes the composition of the OPU signal. This field is

	a concatenation of the Payload type (PT) and the Multiplex	a concatenation of the payload type (PT) and the Multiplex
	Structure Indicator (MSI) defined below.</li>	Structure Indicator (MSI) defined below.</dd>
	<li>MSI: Multiplex Structure Indicator. This structure indicates the	<dt>TPN:</dt>
	grouping of the tributary slots in an OPU payload area that	<dd>Tributary Port Number. The tributary port number is used to
	realizes a client signal which is multiplexed into an OPU. The
	individual clients multiplexed into the OPU payload area are
	distinguished by the Tributary Port Number (TPN).</li>
	<li>TPN: Tributary Port Number. The tributary port number is used to
	indicate the port number of the client signal that is being	indicate the port number of the client signal that is being

	transported in one specific tributary slot. </li>	transported in one specific tributary slot. </dd>
	</ul>	</dl>

	<t>	<t>

	Detailed descriptions of these terms can be found in	Detailed descriptions for some of these terms can be found in <xref
	<xref target="ITU-T_G709_2020" format="default"/>.</t>	target="ITU-T_G709_2020" format="default"/>.</t>
	</section>	</section>

	<section anchor="sect-3" numbered="true" toc="default">	<section anchor="sect-3" numbered="true" toc="default">

	<name>Overview of the OTUCn/ODUCn in G.709</name>	<name>Overview of OTUCn/ODUCn in G.709</name>
	<t>	<t>

	This section provides an overview of OTUCn/ODUCn signals defined in	This section provides an overview of the OTUCn/ODUCn signals defined in
	<xref target="ITU-T_G709_2020" format="default"/>.	<xref target="ITU-T_G709_2020" format="default"/>.
	The text in this section is purely descriptive	The text in this section is purely descriptive

	and is not normative. For a full description of OTUCn/ODUCn signals	and is not normative. For a full description of OTUCn/ODUCn signals,
	please refer to <xref target="ITU-T_G709_2020" format="default"/>.	please refer to <xref target="ITU-T_G709_2020" format="default"/>.
	In the event of any discrepancy	In the event of any discrepancy
	between this text and <xref target="ITU-T_G709_2020" format="default"/>,	between this text and <xref target="ITU-T_G709_2020" format="default"/>,
	that other document is definitive.</t>	that other document is definitive.</t>
	<section anchor="sect-3.1" numbered="true" toc="default">	<section anchor="sect-3.1" numbered="true" toc="default">
	<name>OTUCn</name>	<name>OTUCn</name>
	<t>	<t>
	In order to carry client signals with rates greater than 100 Gbit/s,	In order to carry client signals with rates greater than 100 Gbit/s,
	<xref target="ITU-T_G709_2020" format="default"/>	<xref target="ITU-T_G709_2020" format="default"/>
	takes a general and scalable approach that	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*100 Gbit/s. The following are the key characteristics of
	the OTUCn signal:	the OTUCn signal:
	</t>	</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals	<li>The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals

	perform digital section roles only (see	perform digital section-layer roles only (see Section 6.1.1 of
	<xref target="ITU-T_G709_2020" format="default"/>:Section 6.1.1)	<xref target="ITU-T_G709_2020" format="default"/>)
	</li>	</li>

	<li>The OTUCn signals can be viewed as being formed by interleaving n	<li>The OTUCn signals are formed by interleaving n synchronous OTUC signals
	synchronous OTUC signals (which are labeled 1, 2, ..., n).</li>	(which are labeled 1, 2, ..., n).</li>
	<li>Each of the OTUC instances has the same overhead as the standard	<li>Each of the OTUC instances has the same overhead as the standard
	OTUk signal in <xref target="ITU-T_G709_2020" format="default"/>.	OTUk signal in <xref target="ITU-T_G709_2020" format="default"/>.

	Note that the OTUC signal doesn't include the FEC columns	Note that the OTUC signal doesn't include the Forward Error Correction (F
	illustrated in <xref target="ITU-T_G709_2020" format="default"/>:Figure 1	EC) columns
	1-1.	illustrated in Figure 11-1 of <xref target="ITU-T_G709_2020" format="defa
		ult"/>.
	The OTUC signal includes an ODUC.</li>	The OTUC signal includes an ODUC.</li>
	<li>The OTUC signal has a slightly higher rate compared to the OTU4	<li>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.</li>	area can carry an ODU4 signal.</li>

	<li> The combined signal OTUCn has n instances of OTUC overhead, and	<li> The combined signal OTUCn has n instances of OTUC overhead and
	n instances of ODUC overhead.</li>	n instances of ODUC overhead.</li>
	</ul>	</ul>
	<t>	<t>

	The OTUCn, ODUCn and OPUCn signal structures are presented in a	The OTUCn, ODUCn, and OPUCn signal structures are presented in a
	(physical) interface independent manner, by means of n OTUC, ODUC and	(physical) interface-independent manner, by means of n OTUC, ODUC, and
	OPUC instances that are marked #1 to #n.</t>	OPUC instances that are marked #1 to #n.</t>
	<t>	<t>
	OTUCn interfaces can be categorized as follows, based on the type of	OTUCn interfaces can be categorized as follows, based on the type of
	peer network element:</t>	peer network element:</t>

	<ul spacing="normal">	<dl spacing="normal">
	<li>inter-domain interfaces: These types of interfaces are used for	<dt>inter-domain interfaces:</dt><dd>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	or (b) hand-off points from other OTN. ITU-T
	Recommendation <xref target="ITU-T_G709.1" format="default"/>	Recommendation G709.1 <xref target="ITU-T_G709.1" format="default"/>
	specifies a flexible interoperable	specifies a flexible interoperable
	short-reach OTN interface over which an OTUCn (n >=1) is	short-reach OTN interface over which an OTUCn (n >=1) is
	transferred, using bonded Flexible OTN information structure (FlexO) inte	transferred, using bonded Flexible OTN information structure (FlexO) interf
	rfaces which belong to a	aces, which belong to a
	FlexO group.</li>	FlexO group.</dd>
	<li>intra-domain interfaces: In these cases, the OTUCn is transported	<dt>intra-domain interfaces:</dt><dd>In these cases, the OTUCn is transport
	using a proprietary (vendor specific) encapsulation, FEC etc. It	ed
	is also possible to transport OTUCn for intra-domain links using	using a proprietary (vendor-specific) encapsulation, FEC, etc. It
	FlexO.</li>	is also possible to transport OTUCn for intra-domain links using
	</ul>	FlexO.</dd>
		</dl>

	<section anchor="sect-3.1.1" numbered="true" toc="default">	<section anchor="sect-3.1.1" numbered="true" toc="default">
	<name>OTUCn-M</name>	<name>OTUCn-M</name>
	<t>	<t>

	The standard OTUCn signal has the same rate as that of the ODUCn	The standard OTUCn signal has the same rate as the ODUCn signal. This
	signal. This implies that the OTUCn signal can only be transported	implies that the OTUCn signal can only be transported over wavelength
	over wavelength groups which have a total capacity of multiples of	groups that have a total capacity of multiples of (approximately) 100 Gbit/s.
	(approximately) 100G. Modern optical interfaces support a variety of bit rat	Modern optical interfaces support a variety of bitrates per wavelength,
	es per	depending on the reach requirements for the optical path. If the total
	wavelength, depending on the reach requirements for the optical path.	rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller
	If the total rate of the ODUk LSPs planned to be carried over an	than n*100 Gbit/s, it is possible to "crunch" the OTUCn, and the unused
	ODUCn link is smaller than n*100G, it is possible to "crunch" the	tributary slots are thus not transmitted. <xref target="ITU-T_G709_2020"
	OTUCn not to transmit the unused tributary slots. ITU-T supports	format="default"/> supports the notion of a reduced-rate OTUCn signal,
	the notion of a reduced rate OTUCn signal, termed the OTUCn-M. The	termed "OTUCn-M". The OTUCn-M signal is derived from the OTUCn signal by
	OTUCn-M signal is derived from the OTUCn signal by retaining all the	retaining all the n instances of overhead (one per OTUC instance) but with
	n instances of overhead (one per OTUC instance) but with only M (M is	only M (M is less than 20*n) OPUCn tributary slots available to carry ODUk
	less than 20*n) OPUCn tributary slots available to carry ODUk LSPs.</t>	LSPs.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="sect-3.2" numbered="true" toc="default">	<section anchor="sect-3.2" numbered="true" toc="default">
	<name>ODUCn</name>	<name>ODUCn</name>


	<t>	<t>
	The ODUCn signal defined in <xref target="ITU-T_G709_2020" format="default"/>	The ODUCn signal defined in <xref target="ITU-T_G709_2020" format="default"/>
	can be viewed as being	can be viewed as being
	formed by the appropriate interleaving of content from n ODUC signal	formed by the appropriate interleaving of content from n ODUC signal

	instances. The ODUC frames have the same structure as a standard ODU	instances.
	in the sense that it has the same overhead and payload	The ODUC frames have the same structure as a standard ODU
	areas, but has a higher rate since its payload area can embed an	in the sense that the frames have the same overhead and payload
	ODU4 signal.</t>	areas but have a higher rate since their payload area can embed
	<t>	an ODU4 signal.
	The ODUCn is a multiplex section ODU signal, and is mapped into an	</t>
	OTUCn signal which provides the regenerator section layer. In some	<t>
	scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e.	The ODUCn is a multiplex section ODU signal and is mapped into an
		OTUCn signal, which provides the regenerator section layer. In some
		scenarios, the ODUCn and OTUCn signals will be coterminated, i.e.,
	they will have identical source/sink locations (see	they will have identical source/sink locations (see

	<xref target="ure-oducn-signal" format="default"/>). In this figure,	<xref target="ure-oducn-signal" format="default"/>). In <xref target="ure-odu cn-signal" format="default"/>,
	the term "OTN Switch" has the same meaning as that used in	the term "OTN Switch" has the same meaning as that used in

	<xref target="RFC7138" format="default"/>:Section 3.	<xref target="RFC7138" section="3" sectionFormat="of"/>.
	<xref target="ITU-T_G709_2020" format="default"/>	<xref target="ITU-T_G709_2020" format="default"/>
	allows for the ODUCn signal to pass through one or more digital regenerator	allows for the ODUCn signal to pass through one or more digital regenerator

	nodes (shown as Nodes B, C in <xref target="ure-oducn-signal-multihop" format	nodes (shown as nodes B and C in <xref target="ure-oducn-signal-multihop" for
	="default"/>)	mat="default"/>),
	which will terminate the OTUCn layer, but will pass the	which will terminate the OTUCn layer but will pass the
	regenerated (but otherwise untouched) ODUCn towards a different OTUCn	regenerated (but otherwise untouched) ODUCn towards a different OTUCn
	interface where a fresh OTUCn layer will be initiated.	interface where a fresh OTUCn layer will be initiated.

	This process is termed as "ODUCn regeneration" in	This process is termed as "ODUCn regeneration" in Section 7.1 of
	<xref target="ITU-T_G872" format="default"/>:Section 7.1.	<xref target="ITU-T_G872" format="default"/>.
	In this example, the ODUCn is carried by 3 OTUCn segments.	In this example, the ODUCn is carried by three OTUCn segments.
	</t>	</t>
	<t>	<t>
	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, tributary-slot	unchanged. That is, the set of client signals, their TPNs, and tributary-slo
	allocation remains unchanged.</t>	t
		allocations remains unchanged.</t>
	<figure anchor="ure-oducn-signal">	<figure anchor="ure-oducn-signal">

	<name>ODUCn signal</name>	<name>ODUCn Signal</name>
	<artwork name="" type="" align="center" alt=""><![CDATA[	<artwork name="" type="" align="center" alt=""><![CDATA[


	+--------+ +--------+	+--------+ +--------+
	\| +-----------+ \|	\| +-----------+ \|
	\| OTN \|-----------\| OTN \|	\| OTN \|-----------\| OTN \|
	\| Switch +-----------+ Switch \|	\| Switch +-----------+ Switch \|

	\| A \| \| B \|	\| A \| \| B \|
	\| +-----------+ \|	\| +-----------+ \|
	+--------+ +--------+	+--------+ +--------+
	<--------ODUCn------->	<--------ODUCn------->
	<-------OTUCn------>	<-------OTUCn------>


	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<figure anchor="ure-oducn-signal-multihop">	<figure anchor="ure-oducn-signal-multihop">

	<name>ODUCn signal - multihop</name>	<name>ODUCn Signal - Multi-Hop</name>
	<artwork name="" type="" align="center" alt=""><![CDATA[	<artwork name="" type="" align="center" alt=""><![CDATA[


	+---------+ +--------+ +--------+ +--------+	+---------+ +--------+ +--------+ +--------+
	\| +--------+ \| \| +----------+ \|	\| +--------+ \| \| +----------+ \|
	\| OTN \|--------\| OTN \| \| OTN \|----------\| OTN \|	\| OTN \|--------\| OTN \| \| OTN \|----------\| OTN \|
	\| Switch +--------+ Regen +--------+ Regen +----------+ Switch \|	\| Switch +--------+ Regen +--------+ Regen +----------+ Switch \|
	\| A \| \| B \| \| C \| \| D \|	\| A \| \| B \| \| C \| \| D \|
	\| +--------+ \| \| +----------+ \|	\| +--------+ \| \| +----------+ \|
	+---------+ +--------+ +--------+ +--------+	+---------+ +--------+ +--------+ +--------+

	<-------------------------ODUCn-------------------------->	<-------------------------ODUCn-------------------------->
	<---------------><-----------------><------------------>	<---------------><-----------------><------------------>

	skipping to change at line 350 ¶	skipping to change at line 379 ¶
	slots in OPU2, OPU3, and OPU4 signals. <xref target="ITU-T_G709_2020" format ="default"/>	slots in OPU2, OPU3, and OPU4 signals. <xref target="ITU-T_G709_2020" format ="default"/>
	defined the	defined the
	OPUC with a 5 Gbit/s tributary slot granularity. This means that the ODUCn	OPUC with a 5 Gbit/s tributary slot granularity. This means that the ODUCn
	signal has 20*n tributary slots (of 5 Gbit/s capacity). The range of	signal has 20*n tributary slots (of 5 Gbit/s capacity). The range of
	tributary port number (TPN) is 10n instead of 20n, which restricts	tributary port number (TPN) is 10n instead of 20n, which restricts
	the maximum client signals that could be carried over one single	the maximum client signals that could be carried over one single
	ODUC1.</t>	ODUC1.</t>
	</section>	</section>

	<section anchor="sect-3.4" numbered="true" toc="default">	<section anchor="sect-3.4" numbered="true" toc="default">

	<name>Structure of OPUCn MSI with Payload type 0x22</name>	<name>Structure of OPUCn MSI with Payload Type 0x22</name>
	<t>	<t>

	As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary slots (TSs).	As mentioned above, the OPUCn signal has 20*n tributary slots (TSs) (each 5
	The OPUCn MSI field has a fixed length of 40*n bytes and indicates	Gbit/s). The OPUCn MSI field has a fixed length of 40*n bytes and
	the availability and occupation of each TS. Two bytes are used for	indicates the availability and occupation of each TS. Two bytes are used
	each of the 20*n tributary slots, and each such information structure	for each of the 20*n tributary slots, and each such information structure
	has the following format	has the following format (see Section 20.4.1 of <xref
	(<xref target="ITU-T_G709_2020" format="default"/>:Section 20.4.1):</t>	target="ITU-T_G709_2020" format="default"/>):</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>The TS availability bit indicates if the tributary slot is	<li>The TS availability bit indicates if the tributary slot is

	available or unavailable</li>	available or unavailable.</li>
	<li>The TS occupation bit indicates if the tributary slot is	<li>The TS occupation bit indicates if the tributary slot is

	allocated or unallocated</li>	allocated or unallocated.</li>
	<li>The tributary port number (14 bits) of the client signal that is	<li>The tributary port number (14 bits) indicates the port number of
	being carried in this specific TS. A flexible assignment of	the client signal that is being carried in this specific TS. A
	tributary port to tributary slots is possible. Numbering of	flexible assignment of tributary port to tributary slots is possible.
	tributary ports is from 1 to 10*n.</li>	Numbering of tributary ports is from 1 to 10*n.
		</li>
	</ul>	</ul>
	<t>	<t>
	The concatenation of the OPUCn payload type (PT) and the MSI field is carried over	The concatenation of the OPUCn payload type (PT) and the MSI field is carried over

	the overhead byte designated as PSI in <xref target="ITU-T_G709_2020" format=" default"/>:Figure 15-6.	the overhead byte designated as PSI in Figure 15-6 of <xref target="ITU-T_G709 _2020" format="default"/>.
	</t>	</t>
	</section>	</section>
	<section anchor="sect-3.5" numbered="true" toc="default">	<section anchor="sect-3.5" numbered="true" toc="default">
	<name>Client Signal Mappings</name>	<name>Client Signal Mappings</name>
	<t>	<t>
	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:</t>	appropriate ODU containers is as follows:</t>
	<ul spacing="normal">	<ul spacing="normal">

	<li>All client signals are mapped into an ODUj, or ODUk (e.g., ODUflex) as	<li>All client signals are mapped into an ODUj or ODUk (e.g., ODUflex) as
	specified in clause 17 of <xref target="ITU-T_G709_2020" format="default"	specified in Section 17 of <xref target="ITU-T_G709_2020" format="default
	/>.</li>	"/>.</li>
	<li> The terms ODUj & ODUk are used in a multiplexing scenario, with	<li> The terms "ODUj" and "ODUk" are used in a multiplexing scenario, with
	ODUj being a low-order ODU which is multiplexed into ODUk, a high-order ODU.	ODUj being a low-order ODU that is multiplexed into ODUk, a high-order ODU.
	As <xref target="ure-digital-structure-of-otn-interfaces-from-g.709figure-6-1 "/> illustrates,	As <xref target="ure-digital-structure-of-otn-interfaces-from-g.709figure-6-1 "/> illustrates,

	the ODUCn is also a high-order ODU into which other ODUs can be multiplexed;	the ODUCn is also a high-order ODU into which other ODUs can be multiplexed.
	the ODUCn	The ODUCn
	itself cannot be multiplexed into any higher rate ODU signal; it is defined t	itself cannot be multiplexed into any higher-rate ODU signal; it is defined t
	o be a	o be a
	section level signal. </li>	section-level signal. </li>
	<li>ODUflex signals are low-order signals only. If the ODUflex	<li>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 100 Gbit/s 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.</li>	with rates greater than 100 Gbit/s, ODUCn is required.</li>
	<li>ODU Virtual Concatenation has been deprecated. This simplifies	<li>ODU Virtual Concatenation (VCAT) has been deprecated. This simplifies
	the network, and the supporting hardware since multiple different	the network and the supporting hardware since multiple different
	mappings for the same client are no longer necessary. Note that	mappings for the same client are no longer necessary. Note that

	legacy implementations that transported sub-100G clients using	legacy implementations that transported sub-100 Gbit/s clients using
	ODU VCAT shall continue to be supported.</li>	ODU VCAT shall continue to be supported.</li>

	</ul>	</ul>
	<figure anchor="ure-digital-structure-of-otn-interfaces-from-g.709figure-6-1">	<figure anchor="ure-digital-structure-of-otn-interfaces-from-g.709figure-6-1">

	<name>Digital Structure of OTN interfaces (from G.709:Figure 6-1)</name>	<name>Digital Structure of OTN Interfaces (from Figure 6-1 of <xref target="ITU- T_G709_2020" format="default"/>)</name>
	<artwork name="" type="" align="center" alt=""><![CDATA[	<artwork name="" type="" align="center" alt=""><![CDATA[

	Clients (e.g. SONET/SDH, Ethernet)	Clients (e.g., SONET/SDH and Ethernet)

	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	+---+---+---+----+ \| \| \|	+---+---+---+----+ \| \| \|
	\| OPUj \| \| \| \|	\| OPUj \| \| \| \|
	+----------------+ \| \| \|	+----------------+ \| \| \|
	\| ODUj \| \| \| \|	\| ODUj \| \| \| \|
	+----------------+----------------------+---+---+----------+	+----------------+----------------------+---+---+----------+
	\| \|	\| \|

	skipping to change at line 426 ¶	skipping to change at line 456 ¶
	+-------------------------+-----+--------------------------+	+-------------------------+-----+--------------------------+
	\| \| \| \|	\| \| \| \|
	\| OTUk, OTUk-SC, OTUk-V \| \| OPUCn \|	\| OTUk, OTUk-SC, OTUk-V \| \| OPUCn \|
	+-------------------------+ +--------------------------+	+-------------------------+ +--------------------------+
	\| \|	\| \|
	\| ODUCn \|	\| ODUCn \|
	+--------------------------+	+--------------------------+
	\| \|	\| \|
	\| OTUCn \|	\| OTUCn \|
	+--------------------------+	+--------------------------+


	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>

	<section anchor="sect-4" numbered="true" toc="default">	<section anchor="sect-4" numbered="true" toc="default">
	<name>GMPLS Implications and Applicability</name>	<name>GMPLS Implications and Applicability</name>


	<section anchor="sect-4.1" numbered="true" toc="default">	<section anchor="sect-4.1" numbered="true" toc="default">

	<name>TE-Link Representation</name>	<name>TE Link Representation</name>
	<t>	<t>

	Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with	<xref target="RFC7138" section="3" sectionFormat="of"/> describes how to repr
	TE-Links in GMPLS. In the same manner, OTUCn links can also be represented a	esent G.709 OTUk/ODUk with
	s	TE links in GMPLS. In the same manner, OTUCn links can also be represented a
	TE-links. <xref target="ure-oducn-te-links-1" format="default"/> below provi	s
	des an	TE links. <xref target="ure-oducn-te-links-1" format="default"/> provides an
	illustration of a one-hop OTUCn TE link.</t>	illustration of a one-hop OTUCn TE link.</t>


	<figure anchor="ure-oducn-te-links-1">	<figure anchor="ure-oducn-te-links-1">

	<name>OTUCn TE-Links</name>	<name>One-Hop OTUCn TE Link</name>
	<artwork name="" type="" align="center" alt=""><![CDATA[	<artwork name="" type="" align="center" alt=""><![CDATA[


	+----------+ +---------+	+----------+ +---------+
	\| OTN \| \| OTN \|	\| OTN \| \| OTN \|
	\| Switch +-------------------+ Switch \|	\| Switch +-------------------+ Switch \|
	\| A \| \| B \|	\| A \| \| B \|
	+----------+ +---------+	+----------+ +---------+

	\|<---------OTUCn Link---------->\|	\|<---------OTUCn Link---------->\|


	\|<---------TE-Link------------->\|	\|<---------TE Link------------->\|

	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>	<t>

	It is possible to create TE-links that span more than one hop by creating	It is possible to create TE links that span more than one hop by creating
	forward adjacencies (FA) between non-adjacent nodes	forward adjacencies (FAs) between non-adjacent nodes
	(see <xref target="ure-oducn-te-links-2" format="default"/>). In this	(see <xref target="ure-oducn-te-links-2" format="default"/>). In <xref target="u
	illustration, the nodes B and C are performing the ODUCn regeneration	re-oducn-te-links-2" format="default"/>,
	function described in <xref target="ITU-T_G872"/>:Section 7.1,	nodes B and C are performing the ODUCn regeneration
		function described in Section 7.1 of <xref target="ITU-T_G872"/>
	and are not electrically switching the ODUCn signal from one interface to anothe r.	and are not electrically switching the ODUCn signal from one interface to anothe r.

	As in the one-hop case, Multiple-hop TE-links advertise the ODU switching capabi lity.</t>	As in the one-hop case, multi-hop TE links advertise the ODU switching capabilit y.</t>

	<figure anchor="ure-oducn-te-links-2">	<figure anchor="ure-oducn-te-links-2">

	<name>Multiple-hop ODUCn TE-Link</name>	<name>Multi-Hop ODUCn TE Link</name>
	<artwork name="" type="" align="center" alt=""><![CDATA[	<artwork name="" type="" align="center" alt=""><![CDATA[


	+--------+ +--------+ +--------+ +---------+	+--------+ +--------+ +--------+ +---------+

	\| OTN \| \| OTN \| \| OTN \| \| OTN \|	\| OTN \| \| OTN \| \| OTN \| \| OTN \|
	\| Switch \|<------->\| regen \|<-------->\| regen \|<------->\| Switch \|	\| Switch \|<------->\| Regen \|<-------->\| Regen \|<------->\| Switch \|
	\| A \| OTUCn \| B \| OTUCn \| C \| OTUCn \| D \|	\| A \| OTUCn \| B \| OTUCn \| C \| OTUCn \| D \|
	+--------+ Link +--------+ Link +--------+ Link +---------+	+--------+ Link +--------+ Link +--------+ Link +---------+

	\|<-------------------- ODUCn Link -------------------->\|	\|<-------------------- ODUCn Link -------------------->\|


	\|<---------------------- TE-Link --------------------->\|	\|<---------------------- TE Link --------------------->\|

	]]></artwork>	]]></artwork>
	</figure>	</figure>
	<t>	<t>

	The two endpoints of a TE-Link are configured with the supported	The two endpoints of a TE link are configured with the supported
	resource information, which may include whether the TE-Link is	resource information (which may include whether the TE link is
	supported by an ODUCn or an ODUk or an OTUk, as well as the link	supported by an ODUCn, ODUk, or OTUk), as well as the link
	attribute information (e.g., slot granularity, list of available	attribute information (e.g., slot granularity and list of available
	tributary slot).</t>	tributary slot).</t>
	</section>	</section>
	<section anchor="sect-4.2" numbered="true" toc="default">	<section anchor="sect-4.2" numbered="true" toc="default">

	<name>Implications and Applicability for GMPLS Signalling</name>	<name>GMPLS Signaling</name>

	<t>	<t>

	Once the ODUCn TE-Link is configured, the GMPLS mechanisms defined in	Once the ODUCn TE link is configured, the GMPLS mechanisms defined in
	<xref target="RFC7139" format="default"/>	<xref target="RFC7139" format="default"/>
	can be reused to set up ODUk/ODUflex LSPs with no changes.	can be reused to set up ODUk/ODUflex LSPs with no changes.

	As the resource on the ODUCn link which can be seen by the client	As the resource on the ODUCn link that can be seen by the ODUk/ODUflex
	ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in <xref target="R	client signal is a set of 5 Gbit/s slots, the label defined in
	FC7139" format="default"/>	<xref target="RFC7139" format="default"/>
	is able to accommodate the requirement of the setup of ODUk/ODUflex over	is able to accommodate the requirement of the setup of an ODUk/ODUflex client
	ODUCn link. In <xref target="RFC7139" format="default"/>,	signal over an ODUCn link. In <xref target="RFC7139" format="default"/>, the
	the OTN-TDM GENERALIZED_LABEL object is	OTN-TDM GENERALIZED_LABEL object is used to indicate how the lower-order (LO)
	used to indicate how the lower order (LO) ODUj signal is multiplexed into the	ODUj signal is multiplexed into the higher-order (HO) ODUk link. In a similar
	higher order (HO)	manner, the OTN-TDM GENERALIZED_LABEL object is used to indicate how the ODUk
	ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object	signal is multiplexed into the ODUCn link. The ODUk signal type is indicated
	is used to indicate how the ODUk signal is multiplexed into the ODUCn	by Traffic Parameters. The IF_ID RSVP_HOP object provides a pointer to the
	link. The ODUk Signal Type is indicated by Traffic Parameters. The	interface associated with TE link; therefore, the two nodes terminating the
	IF_ID RSVP_HOP object provides a pointer to the interface associated	TE link know (by internal/local configuration) the attributes of the ODUCn TE
	with TE-Link and therefore the two nodes terminating the TE-link know	Link.</t>
	(by internal/local configuration) the attributes of the ODUCn TE
	Link.</t>
	<t>	<t>

	Since the TPN defined in <xref target="ITU-T_G709_2020" format="default"/>	The TPN defined in <xref target="ITU-T_G709_2020" format="default"/> (where i
		t is referred to as
		"tributary port #")
	for an ODUCn link has 14	for an ODUCn link has 14

	bits, while this field in <xref target="RFC7139" format="default"/>	bits while this field in <xref target="RFC7139" format="default"/>
	only has 12 bits, some extension work will eventually be needed.	only has 12 bits, so some extension work will eventually be needed.
	Given that a 12-bit TPN field can support ODUCn	Given that a 12-bit TPN field can support ODUCn

	links with up to n=400 (i.e. 40Tbit/s links), this need is not urgent.</t>	links with up to n=400 (i.e., 40 Tbit/s links), this need is not urgent.</t>

	<t>	<t>

	An example is given in <xref target="ure-label-format" format="default"/>	The example in <xref target="ure-label-format" format="default"/>
	to illustrate the label format	illustrates the label format defined in <xref target="RFC7139"
	defined in <xref target="RFC7139" format="default"/>	format="default"/> for multiplexing ODU4 onto ODUC10. One ODUC10 has 200
	for multiplexing ODU4 onto ODUC10. One ODUC10	slots (each 5 Gbit/s), and twenty of them are allocated to the ODU4. With
	has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4.	this label encoding, only 20 out of the 200 bits mask are non-zero, which
	With this label encoding, only 20 out of the 200 bits mask are non-zero, and	is very inefficient. The inefficiency grows for larger values of "n", and
	is very inefficient. The inefficiency grows for larger values of "n"	an optimized label format may be desirable. </t>
	and an optimized label format may be desirable. </t>
	<figure anchor="ure-label-format">	<figure anchor="ure-label-format">

	<name>Label format</name>	<name>Label Format</name>
	<artwork name="" type="" align="center" alt=""><![CDATA[	<artwork name="" type="" align="center" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| TPN = 3 \| Reserved \| Length = 200 \|	\| TPN = 3 \| Reserved \| Length = 200 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|0 1 1 0 1 0 1 0 0 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 1 0 1 0 1 0 0 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 0 0 0 0 0 0 0 0 0 0 1 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 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0\|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	skipping to change at line 551 ¶	skipping to change at line 581 ¶
	\|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) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	<section anchor="sect-4.3" numbered="true" toc="default">	<section anchor="sect-4.3" numbered="true" toc="default">

	<name>Implications and Applicability for GMPLS Routing</name>	<name>GMPLS Routing</name>

	<t>	<t>

	For routing, it is deemed that no extension to current mechanisms	For routing, it is deemed that no extension to the current mechanisms
	defined in <xref target="RFC7138" format="default"/>	defined in <xref target="RFC7138" format="default"/>

	is needed. Because, once an ODUCn link is up,	is needed.
	the resources that need to be advertised are the resources that	</t>
	are exposed by this ODUCn link and the multiplexing hierarchy on this
	link. Since the ODUCn link is the lowest layer of the ODU
	multiplexing hierarchy involving multiple ODU layers, and there is a 1:1 corr
	espondence
	with the OTUCn signal, there is no need to explicitly define a new
	value to represent the ODUCn signal type in the OSPF-TE routing
	protocol.</t>
	<t>	<t>

	The OSPF-TE extension defined in section 4 of <xref target="RFC7138" format="	The ODUCn link, which is the lowest layer of the ODU multiplexing hierarchy
	default"/>	involving multiple ODU layers, is assumed to have been already configured when
	can be reused	GMPLS is used to set up ODUk over ODUCn; therefore, the resources that need to
	to advertise the resource information on the ODUCn link to help	be advertised are the resources that are exposed by this ODUCn link and the
	finish the setup of ODUk/ODUflex.</t>	ODUk multiplexing hierarchy on it. The 5 Gbit/s OPUCn time slots do not need to
		be advertised, while the 1.25 Gbit/s and 2.5 Gbit/s OPUk time slots need to be
		advertised using the mechanisms already defined in <xref target="RFC7138"
		format="default"/>.
		</t>
		<t>
		Since there is a 1:1 correspondence between the ODUCn and the OTUCn signal,
		there is no need to explicitly define a new value to represent the ODUCn signal
		type in the OSPF-TE routing protocol.
		</t>
	</section>	</section>
	</section>	</section>


	<section anchor="sect-6" numbered="true" toc="default">
	<name>Authors (Full List)</name>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Qilei Wang (editor)</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	ZTE</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Nanjing, China</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Email: wang.qilei@zte.com.cn</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Radha Valiveti (editor)</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Infinera Corp</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Sunnyvale, CA, USA</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Email: rvaliveti@infinera.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Haomian Zheng (editor)</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Huawei</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	CN</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	EMail: zhenghaomian@huawei.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Huub van Helvoort</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Hai Gaoming B.V</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	EMail: huubatwork@gmail.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Sergio Belotti</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Nokia</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	EMail: sergio.belotti@nokia.com</dd>
	</dl>
	</section>
	<section anchor="sect-7" numbered="true" toc="default">
	<name>Contributors</name>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Iftekhar Hussain, Infinera Corp, Sunnyvale, CA, USA,
	IHussain@infinera.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Daniele Ceccarelli, Ericsson, daniele.ceccarelli@ericsson.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Fatai Zhang, Huawei,zhangfatai@huawei.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Italo Busi, Huawei,italo.busi@huawei.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Dieter Beller, Nokia, Dieter.Beller@nokia.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Zafar Ali, Cisco Systems, zali@cisco.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Daniel King, d.king@lancaster.ac.uk</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Manoj Kumar, Cisco Systems, manojk2@cisco.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Antonello Bonfanti, Cisco Systems, abonfant@cisco.com</dd>
	</dl>
	<dl newline="false" spacing="normal" indent="3">
	<dt/>
	<dd>
	Yuji Tochio, Fujitsu, tochio@fujitsu.com</dd>
	</dl>
	</section>
	<section anchor="sect-8" numbered="true" toc="default">	<section anchor="sect-8" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<t>	<t>

	This memo includes no request to IANA.</t>	This document has no IANA actions.
		</t>
	</section>	</section>
	<section anchor="sect-9" numbered="true" toc="default">	<section anchor="sect-9" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>	<t>

	This document analyzed the applicability of protocol extensions in	This document analyzes the applicability of protocol extensions in
	<xref target="RFC7138" format="default"/>	<xref target="RFC7138" format="default"/>

	and <xref target="RFC7139" format="default"/>	and <xref target="RFC7139" format="default"/> for use in the 2020 version of
	for use in the 2020 version of G.709 [ITU-T_G709_2020] and found	ITU-T Recommendation G.709 <xref target="ITU-T_G709_2020" format="default"/>
	that no new extensions are needed. Therefore, this document introduced no new	and finds that no new extensions are needed. Therefore, this document
	security considerations to the existing signaling and routing protocols beyond	introduces no new security considerations to the existing signaling and
	those already described in	routing protocols beyond those already described in
	<xref target="RFC7138" format="default"/>	<xref target="RFC7138" format="default"/>
	and <xref target="RFC7139" format="default"/>.	and <xref target="RFC7139" format="default"/>.

	Please refer to <xref target="RFC7138" format="default"/>	Please refer to <xref target="RFC7138" format="default"/>
	and <xref target="RFC7139" format="default"/>	and <xref target="RFC7139" format="default"/>
	for further details of the specific security measures. Additionally,	for further details of the specific security measures. Additionally,
	<xref target="RFC5920" format="default"/>	<xref target="RFC5920" format="default"/>
	addresses the security aspects that are relevant in the context of GMPLS.	addresses the security aspects that are relevant in the context of GMPLS.
	</t>	</t>
	</section>	</section>

	skipping to change at line 761 ¶	skipping to change at line 639 ¶
	</t>	</t>
	</section>	</section>

	</middle>	</middle>
	<back>	<back>

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>


	<reference anchor="ITU-T_G709_2020">	<reference anchor="ITU-T_G709_2020">
	<front>	<front>

	<title>ITU-T G.709: Optical Transport Network Interfaces; 06/2020</title>	<title>Interfaces for the optical transport network</title>
	<author>	<author>
	<organization>ITU-T</organization>	<organization>ITU-T</organization>
	</author>	</author>
	<date month="June" year="2020"/>	<date month="June" year="2020"/>
	</front>	</front>

		<seriesInfo name='ITU-T Recommendation' value='G.709' />
	</reference>	</reference>

	<reference anchor="RFC5920" target="https://www.rfc-editor.org/info/rfc5920" xml
	:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5920.
	<front>	xml"/>
	<title>Security Framework for MPLS and GMPLS Networks</title>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7138.
	<author initials="L." surname="Fang" fullname="L. Fang" role="editor">	xml"/>
	<organization/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7139.
	</author>	xml"/>
	<date year="2010" month="July"/>
	<abstract>
	<t>This document provides a security framework for Multiprotocol Label Switching
	(MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This do
	cument addresses the security aspects that are relevant in the context of MPLS a
	nd GMPLS. It describes the security threats, the related defensive techniques,
	and the mechanisms for detection and reporting. This document emphasizes RSVP-T
	E and LDP security considerations, as well as inter-AS and inter-provider securi
	ty considerations for building and maintaining MPLS and GMPLS networks across di
	fferent domains or different Service Providers. This document is not an Interne
	t Standards Track specification; it is published for informational purposes.</t
	>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5920"/>
	<seriesInfo name="DOI" value="10.17487/RFC5920"/>
	</reference>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7138.xml"
	/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7139.xml"
	/>

	</references>	</references>

	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="ITU-T_G709.1">	<reference anchor="ITU-T_G709.1">
	<front>	<front>

	<title>ITU-T G.709.1: Flexible OTN short-reach interface; 2018</title>	<title>Flexible OTN short-reach interfaces</title>
	<author>	<author>
	<organization>ITU-T</organization>	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2018"/>	<date month="June" year="2018"/>
	</front>	</front>

		<seriesInfo name='ITU-T Recommendation' value='G.709.1' />
	</reference>	</reference>

	<reference anchor="ITU-T_G709_2012">	<reference anchor="ITU-T_G709_2012">
	<front>	<front>

	<title>ITU-T G.709: Optical Transport Network Interfaces; 02/2012</title>	<title>Interfaces for the optical transport network</title>
	<author>	<author>
	<organization>ITU-T</organization>	<organization>ITU-T</organization>
	</author>	</author>
	<date month="February" year="2012"/>	<date month="February" year="2012"/>
	</front>	</front>

		<seriesInfo name='ITU-T Recommendation' value='G.709' />
	</reference>	</reference>


	<reference anchor="ITU-T_G709_2016">	<reference anchor="ITU-T_G709_2016">
	<front>	<front>

	<title>ITU-T G.709: Optical Transport Network Interfaces; 07/2016</title>	<title>Interfaces for the optical transport network</title>
	<author>	<author>
	<organization>ITU-T</organization>	<organization>ITU-T</organization>
	</author>	</author>

	<date month="July" year="2016"/>	<date month="June" year="2016"/>
	</front>	</front>

		<seriesInfo name='ITU-T Recommendation' value='G.709' />
	</reference>	</reference>

	<reference anchor="ITU-T_G872">	<reference anchor="ITU-T_G872">
	<front>	<front>

	<title>ITU-T G.872: Architecture of Optical Transport Networks; 12/2019</title>	<title>Architecture of optical transport networks</title>
	<author>	<author>
	<organization>ITU-T</organization>	<organization>ITU-T</organization>
	</author>	</author>
	<date month="December" year="2019"/>	<date month="December" year="2019"/>
	</front>	</front>

		<seriesInfo name='ITU-T Recommendation' value='G.872' />
	</reference>	</reference>


	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7062.xml"	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7062.
	/>	xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7096.xml"	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7096.
	/>	xml"/>

	</references>	</references>
	</references>	</references>

	<section anchor="appendix" numbered="true" toc="default">	<section anchor="appendix" numbered="true" toc="default">
	<name> Possible Future Work </name>	<name> Possible Future Work </name>
	<t>	<t>

	As noted in Section <xref target="sect-4.2" format="default"/>,	As noted in <xref target="sect-4.2" format="default"/>,
	the GMPLS TPN field in Section 6.1 of	the GMPLS TPN field defined in
	<xref target="RFC7139" format="default"/> is only 12 bits whereas	<xref target="RFC7139" section="6.1" sectionFormat="of"/> is only 12 bits, where
		as
	an ODUCn link could require up to 14 bits.	an ODUCn link could require up to 14 bits.
	Although the need is not urgent, future work could extend the TPN field	Although the need is not urgent, future work could extend the TPN field
	in GMPLS to use the Reserved bits immediately adjacent.	in GMPLS to use the Reserved bits immediately adjacent.

	This would need to be done in a backward compatible way. </t>	This would need to be done in a backward-compatible way. </t>

	<t>	<t>

	Section <xref target="sect-4.2" format="default"/> further notes that the curren t encoding of	<xref target="sect-4.2" format="default"/> further notes that the current encodi ng of
	GMPLS labels can be inefficient for larger values of n in ODUCn.	GMPLS labels can be inefficient for larger values of n in ODUCn.

	Future work might examine a more compact, yet generalized label encoding	Future work might examine a more compact, yet generalized, label encoding
	to address this issue should it be felt, after analysis of the operational	to address this issue should it be felt, after analysis of the operational
	aspects, that the current encoding is causing problems.	aspects, that the current encoding is causing problems.
	Introduction of a new label encoding would need to be done using a	Introduction of a new label encoding would need to be done using a

	new LSP Encoding Type / G-PID pairing to ensure correct interoperability.</t>	new pairing of LSP encoding type and Generalized Payload Identifier (G-PID) to e
		nsure correct interoperability.</t>

		</section>
		<section anchor="sect-7" numbered="false" toc="default">
		<name>Contributors</name>

		<contact fullname="Iftekhar Hussain">
		<organization>Infinera Corp</organization>
		<address>
		<postal>
		<city>Sunnyvale</city>
		<region>CA</region>
		<country>United States of America</country>
		</postal>
		<email>IHussain@infinera.com</email>
		</address>
		</contact>

		<contact fullname="Daniele Ceccarelli">
		<organization>Ericsson</organization>
		<address>
		<email>daniele.ceccarelli@ericsson.com</email>
		</address>
		</contact>

		<contact fullname="Rajan Rao">
		<organization>Infinera Corp</organization>
		<address>
		<postal>
		<city>Sunnyvale</city>
		<country>United States of America</country>
		</postal>
		<email>rrao@infinera.com</email>
		</address>
		</contact>

		<contact fullname="Fatai Zhang">
		<organization>Huawei</organization>
		<address>
		<email>zhangfatai@huawei.com</email>
		</address>
		</contact>

		<contact fullname="Italo Busi">
		<organization>Huawei</organization>
		<address>
		<email>italo.busi@huawei.com</email>
		</address>
		</contact>

		<contact fullname="Dieter Beller">
		<organization>Nokia</organization>
		<address>
		<email>Dieter.Beller@nokia.com</email>
		</address>
		</contact>

		<contact fullname="Yuanbin Zhang">
		<organization>ZTE</organization>
		<address>
		<postal>
		<city>Beijing</city>
		</postal>
		<email>zhang.yuanbin@zte.com.cn</email>
		</address>
		</contact>

		<contact fullname="Zafar Ali">
		<organization>Cisco Systems</organization>
		<address>
		<email>zali@cisco.com</email>
		</address>
		</contact>

		<contact fullname="Daniel King">
		<address>
		<email>d.king@lancaster.ac.uk</email>
		</address>
		</contact>

		<contact fullname="Manoj Kumar">
		<organization>Cisco Systems</organization>
		<address>
		<email>manojk2@cisco.com</email>
		</address>
		</contact>

		<contact fullname="Antonello Bonfanti">
		<organization>Cisco Systems</organization>
		<address>
		<email>abonfant@cisco.com</email>
		</address>
		</contact>

		<contact fullname="Yuji Tochio">
		<organization>Fujitsu</organization>
		<address>
		<email>tochio@fujitsu.com</email>
		</address>
		</contact>

	</section>	</section>

	</back>	</back>
	</rfc>	</rfc>

End of changes. 116 change blocks.
	518 lines changed or deleted	479 lines changed or added
This html diff was produced by rfcdiff 1.48.