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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<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 &amp; 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 &gt;=1) is short-reach OTN interface over which an OTUCn (n &gt;=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 10*n instead of 20*n, which restricts tributary port number (TPN) is 10*n instead of 20*n, 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 &amp; 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.