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

<!DOCTYPE rfc [
<!ENTITY nbsp    "&#160;">
<!ENTITY zwsp   "&#8203;">
<!ENTITY nbhy   "&#8209;">
<!ENTITY wj     "&#8288;">
]>

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

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

    <title abbrev="B100G Extensions">Applicability abbrev="Applicability of GMPLS beyond 100 Gbit/s OTN">Applicability of GMPLS for Beyond 100G beyond 100 Gbit/s Optical Transport Network</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-gmpls-otn-b100g-applicability-15"/> name="RFC" value="9376"/>
    <author initials="Q." surname="Wang" fullname="Qilei Wang" role="editor">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>Nanjing</street>
          <street>China</street>
          <city>Nanjing</city>
          <country>China</country>
      </postal>
        <email>wang.qilei@zte.com.cn</email>
      </address>
    </author>
    <author initials="R." surname="Valiveti" fullname="Radha Valiveti" role="editor">
      <organization>Infinera Corp</organization>
      <address>
        <postal>
          <street>Sunnyvale</street>
          <street>USA</street>
          <city>Sunnyvale</city>
	  <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>rvaliveti@infinera.com</email>
      </address>
    </author>
    <author initials="H." surname="Zheng" fullname="Haomian Zheng" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>China</street>
          <country>China</country>
        </postal>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Helvoort" surname="van Helvoort" fullname="Huub van Helvoort">
      <organization>Hai Gaoming B.V</organization> BV</organization>
      <address>
        <postal>
          <street>Almere</street>
          <street>Netherlands</street>
          <city>Almere</city>
          <country>Netherlands</country>
        </postal>
        <email>huubatwork@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Belotti" fullname="Sergio Belotti">
      <organization>Nokia</organization>
      <address>
        <email>sergio.belotti@nokia.com</email>
      </address>
    </author>
    <!--date year="2021" month="November" day="7"/-->
    <workgroup>Internet Engineering Task Force</workgroup>
    <date year="2023" month="March" />
    <area>rtg</area>
    <workgroup>ccamp</workgroup>
    <abstract>
      <t>
   This document examines the applicability of using existing GMPLS routing
   and signalling signaling mechanisms to set up Optical Data Unit-k (ODUk) Label
   Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in
   the 2020 version of ITU-T Recommendation G.709.</t>
    </abstract>
  </front>

  <middle>
  <section anchor="sect-1" numbered="true" toc="default">
    <name>Introduction</name>
   <t>
   The current GMPLS routing <xref target="RFC7138" format="default"/>
   and signalling signaling <xref target="RFC7139" format="default"/>
   extensions support the control of the Optical Transport Network (OTN) signals and capabilities that
   were defined in the 2012 version of ITU-T
   Recommendation G.709 <xref target="ITU-T_G709_2012" format="default"/>.</t>
  <t>
   In 2016 2016, a further new version of ITU-T
   Recommendation G.709 was published: <xref target="ITU-T_G709_2016" format="default"/>.
   This version introduced higher rate higher-rate Optical Transport Unit (OTU) and Optical Data Unit (ODU) signals, termed OTUCn "OTUCn"
   and ODUCn "ODUCn", respectively, which have a nominal rate of n x 100 n*100 Gbit/s.
   According to the definition in <xref target="ITU-T_G709_2016" format="default"/>, OTUCn and ODUCn
   perform only the digital section layer role section-layer role, and ODUCn supports only ODUk clients.
   This document focuses on the use of existing GMPLS mechanisms to set
   up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, independently from how
   these links have been set up.</t>

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

<t>
   This document assumes that the reader is readers are familiar with OTN, GMPLS, and how
   GMPLS is applied in OTN networks. OTN. As such, this document doesn't provide
   any background pertaining to OTN networks that included include links with capacities
   of 100G 100 Gbit/s or less;  this background could be found in documents such as
   <xref target="RFC7062" format="default"/> and
   <xref target="RFC7096" format="default"/>.
   This document provides an overview of the dataplane data plane primitives
   that enable links with capacities greater than 100G, 100 Gbit/s and analyses analyzes the extensions
   that would be required in the current GMPLS routing &amp; and signaling mechanisms
   to support the evolution in OTN networks. OTN.
</t>
</section>

<section anchor="sect-2" numbered="true" toc="default">
<name>OTN terminology used Terminology Used in this document</name>
<ul This Document</name>
<dl spacing="normal">
<li>FlexO: Flexible
<dt>FlexO:</dt>
<dd>Flexible OTN information structure. This information structure
		is usually with
has a specific bit rate bitrate and frame format, consisting format that consists of overhead and payload,
which is are used as a group for the transport of an OTUCn signal.</li>
<li>LSP: signal.
</dd>
<dt>LSP:</dt>
<dd> Label Switched Path. </li>
<li>ODU: Optical Path </dd>
<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 in
            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 client
            (such client,
            such as SONET/SDH, Ethernet) SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) or Ethernet, or b) by multiplexing lower-rate ODUs.
            In general, the ODU layer represents the path layer in OTN networks. OTN. The only
            exception is the ODUCn signal (defined below) below), which is defined to be a section
            layer section-layer signal.
            In the classification based on bitrates of the ODU signals,
            ODUs are of two types: Fixed rate, fixed rate and flexible rate. Flexible rate
            ODU(s), Flexible-rate
            ODUs, called "ODUFlex" "ODUflex", have a rate that is 239/238 times
            the bit rate of the client signal it encapsulates. </li>
<li>ODUk: Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term ODUk references
            to an ODU whose bit rate is fully specified by the index k. The bit rates of the
            ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25G, 2.5G, 10G,
            10.3G, 40G, 100G respectively.</li>
<li>ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same frame structure
            as a "generic" ODU, but with rate that is a fixed multiple of the bitrate of the client signal it
            encapsulates. ITU-T defines specific ODUflex containers that are required to transport
            specific clients such as 50GE, 200GE, 400GE, etc.</li>
<li> ODUC: Optical they encapsulate. </dd>
<dt>ODUC:</dt>
<dd>Optical Data Unit -C; this Unit-C. This signal has a bandwidth of approximately 100G, 100 Gbit/s and
is of a slightly higher bit rate bitrate 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 higher-rate signal called ODUCn "ODUCn" (defined below). </li>
<li>ODUCn: Optical </dd>

<dt>ODUCn:</dt>
<dd>Optical Data Unit-Cn; Unit-Cn, where Cn indicates the bit rate bitrate of approximately n*100G. n*100 Gbit/s.
           This frame structure consists of "n" interleaved, interleaved frame and multi-frame multiframe
           synchronous instances of the ODUC signal, each of which has the format defined in
           Figure 12-1 of <xref target="ITU-T_G709_2020" format="default"/>.</li>
<li>OPUC: Optical Payload format="default"/>.</dd>

<dt>ODUflex:</dt>
<dd>Optical Data Unit -C; - flexible rate. An ODUflex has the same frame structure
            as a "generic" ODU but with a rate that is a fixed multiple of the bitrate of the client signal it
            encapsulates. <xref target="ITU-T_G709_2020" format="default"/> defines 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 bitrates 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 100G. 100 Gbit/s. This
     structure represents the payload area of the ODUC signal. </li>
<li>OPUCn: Optical </dd>
<dt>OPUCn:</dt>
<dd>Optical Payload Unit-Cn.  Where Unit-Cn, where Cn indicates that the bit
       rate bitrate is
approximately n*100G. n*100 Gbit/s. This structure represents the payload area of the ODUCn signal.</li>
<li>OTUC: Optical
signal.</dd>
<dt>OTN:</dt>
<dd>Optical Transport Unit -C; with Network</dd>
<dt>OTUC:</dt>
<dd>Optical Transport Unit-C. This signal has a bandwidth of approximately 100G. 100 Gbit/s.
    This signal forms the building block of the OTUCn signal defined below,
    which has a bandwidth of approximately n*100G. </li>
<li>OTUCn: Fully n*100 Gbit/s. </dd>

<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.
           The structure of this signal is illustrated in Figure 11-1 11-4 of
           <xref target="ITU-T_G709_2020" format="default"/>. Note that
           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>
<li>OTUCn-M: This format="default"/>.</dd>
<dt>OTUCn-M:</dt>
<dd>This signal is an extension of the OTUCn signal introduced above.  This
signal contains the same amount of overhead as the OTUCn signal, signal but contains a
reduced amount of payload area.  Specifically, the payload area consists of M 5 Gbit/s
tributary slots - (each 5 Gbit/s), where M is less than 20*n, which is the
number of tributary slots in the OTUCn signal. </li>
<li>OTN: Optical Transport Network.</li>
<li>PSI: OPU Payload
</dd>
<dt>PSI:</dt>
<dd>Payload Structure Indicator.  This is a 256-byte signal
       that describes the composition of the OPU signal.  This field is
       a concatenation of the Payload payload type (PT) and the Multiplex
       Structure Indicator (MSI) defined below.</li>
<li>MSI: 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).</li>
<li>TPN: Tributary below.</dd>
<dt>TPN:</dt>
<dd>Tributary Port Number. The tributary port number is used to
		indicate the port number of the client signal that is being
		transported in one specific tributary slot. </li>
</ul> </dd>
</dl>

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

<section anchor="sect-3" numbered="true" toc="default">
<name>Overview of the OTUCn/ODUCn in G.709</name>
<t>
   This section provides an overview of the OTUCn/ODUCn signals defined in
<xref target="ITU-T_G709_2020" format="default"/>.
   The text in this section is purely descriptive
   and is not normative.  For a full description of OTUCn/ODUCn signals signals,
   please refer to <xref target="ITU-T_G709_2020" format="default"/>.
   In the event of any discrepancy
   between this text and <xref target="ITU-T_G709_2020" format="default"/>,
   that other document is definitive.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<name>OTUCn</name>
<t>
   In order to carry client signals with rates greater than 100 Gbit/s,
<xref target="ITU-T_G709_2020" format="default"/>
  takes a general and scalable approach that
   decouples the rates of OTU signals from the client rate.  The new OTU
   signal is called OTUCn, "OTUCn", and this signal is defined to have a rate of
   (approximately) n*100G. n*100 Gbit/s.  The following are the key characteristics of
   the OTUCn signal:
</t>
<ul spacing="normal">
<li>The OTUCn signal contains one ODUCn.  The OTUCn and ODUCn signals
       perform digital section section-layer roles only (see Section 6.1.1 of
<xref target="ITU-T_G709_2020" format="default"/>:Section 6.1.1) format="default"/>)
</li>
<li>The OTUCn signals can be viewed as being are formed by interleaving n synchronous OTUC signals
(which are labeled 1, 2, ..., n).</li>
<li>Each of the OTUC instances has the same overhead as the standard
       OTUk signal in <xref target="ITU-T_G709_2020" format="default"/>.
       Note that the OTUC signal doesn't include the FEC Forward Error Correction (FEC) columns
       illustrated in Figure 11-1 of <xref target="ITU-T_G709_2020" format="default"/>:Figure 11-1. format="default"/>.
       The OTUC signal includes an ODUC.</li>
<li>The OTUC signal has a slightly higher rate compared to the OTU4
       signal (without FEC); this is to ensure that the OPUC payload
       area can carry an ODU4 signal.</li>
<li> The combined signal OTUCn has n instances of OTUC overhead, overhead and
       n instances of ODUC overhead.</li>
</ul>
<t>
   The OTUCn, ODUCn ODUCn, and OPUCn signal structures are presented in a
   (physical) interface independent interface-independent manner, by means of n OTUC, ODUC ODUC, and
   OPUC instances that are marked #1 to #n.</t>
<t>
   OTUCn interfaces can be categorized as follows, based on the type of
   peer network element:</t>
<ul
   <dl spacing="normal">
<li>inter-domain interfaces: These
     <dt>inter-domain interfaces:</dt><dd>These types of interfaces are used for
     connecting OTN edge nodes to (a) client equipment (e.g. (e.g., routers)
     or (b) hand-off points from other OTN networks. OTN.  ITU-T
     Recommendation G709.1 <xref target="ITU-T_G709.1" format="default"/>
     specifies a flexible interoperable
     short-reach OTN interface over which an OTUCn (n &gt;=1) is
     transferred, using bonded Flexible OTN information structure (FlexO) interfaces interfaces, which belong to a
     FlexO group.</li>
<li>intra-domain interfaces: In group.</dd>
     <dt>intra-domain interfaces:</dt><dd>In these cases, the OTUCn is transported
     using a proprietary (vendor specific) (vendor-specific) encapsulation, FEC FEC, etc.  It
     is also possible to transport OTUCn for intra-domain links using
       FlexO.</li>
</ul>
     FlexO.</dd>
   </dl>

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

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

<t>
   The ODUCn signal defined in <xref target="ITU-T_G709_2020" format="default"/>
   can be viewed as being
   formed by the appropriate interleaving of content from n ODUC signal
   instances.
   The ODUC frames have the same structure as a standard ODU
   in the sense that it has the frames have the same overhead and payload
   areas,
   areas but has have a higher rate since its their payload area can embed
   an ODU4 signal.</t> signal.
</t>
   <t>
   The ODUCn is a multiplex section ODU signal, signal and is mapped into an
   OTUCn signal signal, which provides the regenerator section layer.  In some
   scenarios, the ODUCn, ODUCn and OTUCn signals will be co-terminated, i.e. coterminated, i.e.,
   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"/>,
   the term "OTN Switch" has the same meaning as that used in
   <xref target="RFC7138" format="default"/>:Section 3. section="3" sectionFormat="of"/>.
   <xref target="ITU-T_G709_2020" format="default"/>
   allows for the ODUCn signal to pass through one or more digital regenerator
   nodes (shown as Nodes B, nodes B and C in <xref target="ure-oducn-signal-multihop" format="default"/>) format="default"/>),
   which will terminate the OTUCn layer, layer but will pass the
   regenerated (but otherwise untouched) ODUCn towards a different OTUCn
   interface where a fresh OTUCn layer will be initiated.
   This process is termed as "ODUCn regeneration" in Section 7.1 of
   <xref target="ITU-T_G872" format="default"/>:Section 7.1. format="default"/>.
   In this example, the ODUCn is carried by 3 three OTUCn segments.
   </t>
<t>
   Specifically, the OPUCn signal flows through these regenerators
   unchanged.  That is, the set of client signals, their TPNs, and tributary-slot
   allocation
   allocations remains unchanged.</t>
<figure anchor="ure-oducn-signal">
<name>ODUCn signal</name> Signal</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
 +--------+           +--------+
 |        +-----------+        |
 | OTN    |-----------| OTN    |
 | Switch +-----------+ Switch |
 | A      |           | B      |
 |        +-----------+        |
 +--------+           +--------+
     <--------ODUCn------->
      <-------OTUCn------>
]]></artwork>
</figure>

<figure anchor="ure-oducn-signal-multihop">
<name>ODUCn signal Signal - multihop</name> Multi-Hop</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
 +---------+        +--------+        +--------+          +--------+
 |         +--------+        |        |        +----------+        |
 | OTN     |--------| OTN    |        | OTN    |----------| OTN    |
 | Switch  +--------+ Regen  +--------+ Regen  +----------+ Switch |
 | A       |        | B      |        | C      |          | D      |
 |         +--------+        |        |        +----------+        |
 +---------+        +--------+        +--------+          +--------+

     <-------------------------ODUCn-------------------------->
      <---------------><-----------------><------------------>
           OTUCn              OTUCn               OTUCn
]]></artwork>
</figure>

</section>
<section anchor="sect-3.3" numbered="true" toc="default">
<name>Tributary Slot Granularity</name>
<t>
<xref target="ITU-T_G709_2012" format="default"/>
 introduced the support for 1.25 Gbit/s granular tributary
   slots in OPU2, OPU3, and OPU4 signals.  <xref target="ITU-T_G709_2020" format="default"/>
 defined the
   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
   tributary port number (TPN) is 10*n instead of 20*n, which restricts
   the maximum client signals that could be carried over one single
   ODUC1.</t>
</section>

<section anchor="sect-3.4" numbered="true" toc="default">
<name>Structure of OPUCn MSI with Payload type Type 0x22</name>
<t>
   As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary slots (TSs). (TSs) (each 5
   Gbit/s).  The OPUCn MSI field has a fixed length of 40*n bytes and
   indicates the availability and occupation of each TS.  Two bytes are used
   for each of the 20*n tributary slots, and each such information structure
   has the following format
   (<xref (see Section 20.4.1 of <xref
   target="ITU-T_G709_2020" format="default"/>:Section 20.4.1):</t> format="default"/>):</t>
<ul spacing="normal">
<li>The TS availability bit indicates if the tributary slot is
       available or unavailable</li> unavailable.</li>
<li>The TS occupation bit indicates if the tributary slot is
       allocated or unallocated</li> unallocated.</li>
       <li>The tributary port number (14 bits) indicates the port number of
       the client signal that is being carried in this specific TS.  A
       flexible assignment of tributary port to tributary slots is possible.
       Numbering of tributary ports is from 1 to 10*n.</li> 10*n.
       </li>
</ul>
<t>
  The concatenation of the OPUCn payload type (PT) and the MSI field is carried over
  the overhead byte designated as PSI in Figure 15-6 of <xref target="ITU-T_G709_2020" format="default"/>:Figure 15-6. format="default"/>.
</t>
</section>
<section anchor="sect-3.5" numbered="true" toc="default">
<name>Client Signal Mappings</name>
<t>
   The approach taken by the ITU-T to map non-OTN client signals to the
   appropriate ODU containers is as follows:</t>
<ul spacing="normal">
<li>All client signals are mapped into an ODUj, ODUj or ODUk (e.g., ODUflex) as
       specified in clause Section 17 of <xref target="ITU-T_G709_2020" format="default"/>.</li>
<li> The terms ODUj &amp; ODUk "ODUj" and "ODUk" are used in a multiplexing scenario, with
   ODUj being a low-order ODU which that is multiplexed into ODUk, a high-order ODU.
   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 multiplexed. The ODUCn
   itself cannot be multiplexed into any higher rate higher-rate ODU signal; it is defined to be a
   section level
   section-level signal. </li>
<li>ODUflex signals are low-order signals only.  If the ODUflex
       entities have rates of 100G 100 Gbit/s or less, they can be transported over
       either an ODUk (k=1..4) or an ODUCn.  For ODUflex connections
       with rates greater than 100G, 100 Gbit/s, ODUCn is required.</li>
<li>ODU Virtual Concatenation (VCAT) has been deprecated.  This simplifies
       the network, network and the supporting hardware since multiple different
       mappings for the same client are no longer necessary.  Note that
       legacy implementations that transported sub-100G sub-100 Gbit/s clients using
       ODU VCAT shall continue to be supported.</li>

</ul>
<figure anchor="ure-digital-structure-of-otn-interfaces-from-g.709figure-6-1">
<name>Digital Structure of OTN interfaces Interfaces (from G.709:Figure 6-1)</name> Figure 6-1 of <xref target="ITU-T_G709_2020" format="default"/>)</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
        Clients (e.g. SONET/SDH, (e.g., SONET/SDH and Ethernet)

    |   |   |                           |   |   |
    |   |   |                           |   |   |
    |   |   |                           |   |   |
+---+---+---+----+                      |   |   |
|      OPUj      |                      |   |   |
+----------------+                      |   |   |
|      ODUj      |                      |   |   |
+----------------+----------------------+---+---+----------+
|                                                          |
|                       OPUk                               |
+----------------------------------------------------------+
|                                                          |
|                       ODUk       k in {0,1,2,2e,3,4,flex}|
+-------------------------+-----+--------------------------+
|                         |     |                          |
| OTUk, OTUk-SC, OTUk-V   |     |          OPUCn           |
+-------------------------+     +--------------------------+
                                |                          |
                                |          ODUCn           |
                                +--------------------------+
                                |                          |
                                |          OTUCn           |
                                +--------------------------+
]]></artwork>
</figure>
</section>
</section>

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

<section anchor="sect-4.1" numbered="true" toc="default">
<name>TE-Link
<name>TE Link Representation</name>
<t>
   Section 3 of RFC7138
   <xref target="RFC7138" section="3" sectionFormat="of"/> describes how to represent G.709 OTUk/ODUk with
   TE-Links
   TE links in GMPLS.  In the same manner, OTUCn links can also be represented as
   TE-links.
   TE links.  <xref target="ure-oducn-te-links-1" format="default"/> below provides an
   illustration of a one-hop OTUCn TE link.</t>

<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[
  +----------+                   +---------+
  |  OTN     |                   |  OTN    |
  |  Switch  +-------------------+  Switch |
  |  A       |                   |  B      |
  +----------+                   +---------+

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

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

      |<---------TE Link------------->|
]]></artwork>
</figure>

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

<figure anchor="ure-oducn-te-links-2">
<name>Multiple-hop
<name>Multi-Hop ODUCn TE-Link</name> TE Link</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+--------+         +--------+          +--------+         +---------+
| OTN    |         |  OTN   |          |  OTN   |         |  OTN    |
| Switch |<------->|  regen  Regen |<-------->|  regen  Regen |<------->|  Switch |
| A      |  OTUCn  |  B     |   OTUCn  |  C     |  OTUCn  |  D      |
+--------+  Link   +--------+   Link   +--------+  Link   +---------+

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

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

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

<t>
   Since the
   The TPN defined in <xref target="ITU-T_G709_2020" format="default"/> (where it is referred to as
   "tributary port #")
   for an ODUCn link has 14
   bits,
   bits while this field in <xref target="RFC7139" format="default"/>
   only has 12 bits, so some extension work will eventually be needed.
   Given that a 12-bit TPN field can support ODUCn
   links with up to n=400 (i.e. 40Tbit/s (i.e., 40 Tbit/s links), this need is not urgent.</t>

<t>
   An
   The example is given in <xref target="ure-label-format" format="default"/>
   to illustrate
   illustrates the label format defined in <xref target="RFC7139"
   format="default"/> for multiplexing ODU4 onto ODUC10.  One ODUC10 has 200
   slots (each 5 Gbit/s slots, Gbit/s), and twenty of them are allocated to the ODU4.  With
   this label encoding, only 20 out of the 200 bits mask are non-zero, and which
   is very inefficient.  The inefficiency grows for larger values of "n" "n", and
   an optimized label format may be desirable. </t>
<figure anchor="ure-label-format">
<name>Label format</name> Format</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       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 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 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 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 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 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 0 0 0|               Padding Bits(0)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section anchor="sect-4.3" numbered="true" toc="default">
<name>Implications and Applicability for GMPLS
<name>GMPLS Routing</name>

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

<t>
The ODUCn link link, which is the lowest layer of the ODU multiplexing hierarchy
involving multiple ODU layers, is assumed to have been already configured when
GMPLS is up, used to set up ODUk over ODUCn; therefore, the resources that need to
be advertised are the resources that are exposed by this ODUCn link and the
ODUk multiplexing hierarchy on this
   link.  Since the ODUCn link is the lowest layer of it. The 5 Gbit/s OPUCn time slots do not need to
be advertised, while the ODU
   multiplexing hierarchy involving multiple ODU layers, 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
   with 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>
<t>
   The OSPF-TE extension defined in section 4 of <xref target="RFC7138" format="default"/>
   can be reused
   to advertise the resource information on the ODUCn link to help
   finish the setup of ODUk/ODUflex.</t>
</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> protocol.
</t>
</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">
<name>IANA Considerations</name>
<t>
This memo includes document has no request to IANA.</t> IANA actions.
</t>
</section>
<section anchor="sect-9" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
This document analyzed analyzes the applicability of protocol extensions in
<xref target="RFC7138" format="default"/>
and <xref target="RFC7139" format="default"/> for use in the 2020 version of
ITU-T Recommendation G.709 [ITU-T_G709_2020] <xref target="ITU-T_G709_2020" format="default"/>
and found finds that no new extensions are needed.  Therefore, this document introduced
introduces no new security considerations to the existing signaling and
routing protocols beyond those already described in
<xref target="RFC7138" format="default"/>
 and <xref target="RFC7139" format="default"/>.

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

</middle>
<back>

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

<reference anchor="ITU-T_G709_2020">
<front>
<title>ITU-T G.709: Optical Transport Network Interfaces; 06/2020</title>
<title>Interfaces for the optical transport network</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="June" year="2020"/>
</front>
</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">
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author initials="L." surname="Fang" fullname="L. Fang" role="editor">
<organization/>
</author>
<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 document addresses the security aspects that are relevant in the context of MPLS and GMPLS.  It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting.  This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5920"/>
<seriesInfo name="DOI" value="10.17487/RFC5920"/> name='ITU-T Recommendation' value='G.709' />
</reference>

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

</references>

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

<reference anchor="ITU-T_G709.1">
<front>
<title>ITU-T G.709.1: Flexible
<title>Flexible OTN short-reach interface; 2018</title> interfaces</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="June" year="2018"/>
</front>
<seriesInfo name='ITU-T Recommendation' value='G.709.1' />
</reference>

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

<reference anchor="ITU-T_G709_2016">
<front>
<title>ITU-T G.709: Optical Transport Network Interfaces; 07/2016</title>
<title>Interfaces for the optical transport network</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="July" month="June" year="2016"/>
</front>
<seriesInfo name='ITU-T Recommendation' value='G.709' />
</reference>

<reference anchor="ITU-T_G872">
<front>
<title>ITU-T G.872: Architecture
<title>Architecture of Optical Transport Networks; 12/2019</title> optical transport networks</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="December" year="2019"/>
</front>
<seriesInfo name='ITU-T Recommendation' value='G.872' />
</reference>

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

</references>
</references>

<section anchor="appendix" numbered="true" toc="default">
<name> Possible Future Work </name>
<t>
As noted in Section <xref target="sect-4.2" format="default"/>,
the GMPLS TPN field defined in Section 6.1 of
<xref target="RFC7139" format="default"/> section="6.1" sectionFormat="of"/> is only 12 bits bits, whereas
an ODUCn link could require up to 14 bits.
Although the need is not urgent, future work could extend the TPN field
in GMPLS to use the Reserved bits immediately adjacent.
This would need to be done in a backward compatible backward-compatible way. </t>

<t>
Section
<xref target="sect-4.2" format="default"/> further notes that the current encoding of
GMPLS labels can be inefficient for larger values of n in ODUCn.
Future work might examine a more compact, yet generalized generalized, label encoding
to address this issue should it be felt, after analysis of the operational
aspects, that the current encoding is causing problems.
Introduction of a new label encoding would need to be done using a
new LSP Encoding Type / G-PID pairing of LSP encoding type and Generalized Payload Identifier (G-PID) to ensure 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>

</back>
</rfc>