doc: Add RFC documents

1 files changed, 730 insertions, 0 deletions

diff --git a/doc/rfc/rfc9376.txt b/doc/rfc/rfc9376.txt
new file mode 100644
index 0000000..996ef4c
--- /dev/null
+++ b/doc/rfc/rfc9376.txt
@@ -0,0 +1,730 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      Q. Wang, Ed.
+Request for Comments: 9376                               ZTE Corporation
+Category: Informational                                 R. Valiveti, Ed.
+ISSN: 2070-1721                                            Infinera Corp
+                                                           H. Zheng, Ed.
+                                                                  Huawei
+                                                         H. van Helvoort
+                                                          Hai Gaoming BV
+                                                              S. Belotti
+                                                                   Nokia
+                                                              March 2023
+
+
+ Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network
+
+Abstract
+
+   This document examines the applicability of using existing GMPLS
+   routing and 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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9376.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  OTN Terminology Used in This Document
+   3.  Overview of OTUCn/ODUCn in G.709
+     3.1.  OTUCn
+       3.1.1.  OTUCn-M
+     3.2.  ODUCn
+     3.3.  Tributary Slot Granularity
+     3.4.  Structure of OPUCn MSI with Payload Type 0x22
+     3.5.  Client Signal Mappings
+   4.  GMPLS Implications and Applicability
+     4.1.  TE Link Representation
+     4.2.  GMPLS Signaling
+     4.3.  GMPLS Routing
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Possible Future Work
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   The current GMPLS routing [RFC7138] and signaling [RFC7139]
+   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 [ITU-T_G709_2012].
+
+   In 2016, a new version of ITU-T Recommendation G.709 was published:
+   [ITU-T_G709_2016].  This version introduced higher-rate Optical
+   Transport Unit (OTU) and Optical Data Unit (ODU) signals, termed
+   "OTUCn" and "ODUCn", respectively, which have a nominal rate of n*100
+   Gbit/s.  According to the definition in [ITU-T_G709_2016], OTUCn and
+   ODUCn perform only the digital 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.
+
+   Because [ITU-T_G709_2020] does not introduce any new features to
+   OTUCn and ODUCn compared to [ITU-T_G709_2016], this document first
+   presents an overview of the OTUCn and ODUCn signals in
+   [ITU-T_G709_2020] and then analyzes how the current GMPLS routing and
+   signaling mechanisms can be utilized to set up ODUk (e.g., ODUflex)
+   LSPs over ODUCn links.
+
+   This document assumes that readers are familiar with OTN, GMPLS, and
+   how GMPLS is applied in OTN.  As such, this document doesn't provide
+   any background pertaining to OTN that include links with capacities
+   of 100 Gbit/s or less; this background could be found in documents
+   such as [RFC7062] and [RFC7096].  This document provides an overview
+   of the data plane primitives that enable links with capacities
+   greater than 100 Gbit/s and analyzes the extensions that would be
+   required in the current GMPLS routing and signaling mechanisms to
+   support evolution in OTN.
+
+2.  OTN Terminology Used in This Document
+
+   FlexO:  Flexible OTN information structure.  This information
+      structure usually has a specific bitrate and frame format that
+      consists of overhead and payload, which are used as a group for
+      the transport of an OTUCn signal.
+
+   LSP:  Label Switched Path
+
+   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).
+
+   ODU:  Optical Data Unit.  An ODU has the frame structure and
+      overhead, as defined in Figure 12-1 of [ITU-T_G709_2020].  ODUs
+      can be formed in two ways: a) by encapsulating a single non-OTN
+      client, such as 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.  The only exception is the ODUCn signal (defined
+      below), which is defined to be a section-layer signal.  In the
+      classification based on bitrates of the ODU signals, ODUs are of
+      two types: fixed rate and flexible rate.  Flexible-rate ODUs,
+      called "ODUflex", have a rate that is 239/238 times the bitrate of
+      the client signal they encapsulate.
+
+   ODUC:  Optical Data Unit-C.  This signal has a bandwidth of
+      approximately 100 Gbit/s and is of a slightly higher bitrate than
+      the fixed rate ODU4 signal.  This signal has the format defined in
+      Figure 12-1 of [ITU-T_G709_2020].  This signal represents the
+      building block for constructing a higher-rate signal called
+      "ODUCn" (defined below).
+
+   ODUCn:  Optical Data Unit-Cn, where Cn indicates the bitrate of
+      approximately n*100 Gbit/s.  This frame structure consists of "n"
+      interleaved frame and multiframe synchronous instances of the ODUC
+      signal, each of which has the format defined in Figure 12-1 of
+      [ITU-T_G709_2020].
+
+   ODUflex:  Optical Data Unit - 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.
+      [ITU-T_G709_2020] defines specific ODUflex containers that are
+      required to transport specific clients such as 50GE, 200GE, 400GE,
+      etc.
+
+   ODUk:  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.
+
+   OPUC:  Optical Payload Unit-C.  This signal has a payload of
+      approximately 100 Gbit/s.  This structure represents the payload
+      area of the ODUC signal.
+
+   OPUCn:  Optical Payload Unit-Cn, where Cn indicates that the bitrate
+      is approximately n*100 Gbit/s.  This structure represents the
+      payload area of the ODUCn signal.
+
+   OTN:  Optical Transport Network
+
+   OTUC:  Optical Transport Unit-C.  This signal has a bandwidth of
+      approximately 100 Gbit/s.  This signal forms the building block of
+      the OTUCn signal defined below, which has a bandwidth of
+      approximately n*100 Gbit/s.
+
+   OTUCn:  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-4 of [ITU-T_G709_2020].  Note that the term "fully
+      standardized" is defined by ITU-T in Section 6.1.1 of
+      [ITU-T_G709_2020].
+
+   OTUCn-M:  This signal is an extension of the OTUCn signal introduced
+      above.  This signal contains the same amount of overhead as the
+      OTUCn signal but contains a reduced amount of payload area.
+      Specifically, the payload area consists of M tributary slots (each
+      5 Gbit/s), where M is less than 20*n, which is the number of
+      tributary slots in the OTUCn signal.
+
+   PSI:  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 type (PT) and the Multiplex Structure
+      Indicator (MSI) defined below.
+
+   TPN:  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.
+
+   Detailed descriptions for some of these terms can be found in
+   [ITU-T_G709_2020].
+
+3.  Overview of OTUCn/ODUCn in G.709
+
+   This section provides an overview of the OTUCn/ODUCn signals defined
+   in [ITU-T_G709_2020].  The text in this section is purely descriptive
+   and is not normative.  For a full description of OTUCn/ODUCn signals,
+   please refer to [ITU-T_G709_2020].  In the event of any discrepancy
+   between this text and [ITU-T_G709_2020], that other document is
+   definitive.
+
+3.1.  OTUCn
+
+   In order to carry client signals with rates greater than 100 Gbit/s,
+   [ITU-T_G709_2020] takes a general and scalable approach that
+   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 (approximately) n*100 Gbit/s.  The following are the key
+   characteristics of the OTUCn signal:
+
+   *  The OTUCn signal contains one ODUCn.  The OTUCn and ODUCn signals
+      perform digital section-layer roles only (see Section 6.1.1 of
+      [ITU-T_G709_2020])
+
+   *  The OTUCn signals are formed by interleaving n synchronous OTUC
+      signals (which are labeled 1, 2, ..., n).
+
+   *  Each of the OTUC instances has the same overhead as the standard
+      OTUk signal in [ITU-T_G709_2020].  Note that the OTUC signal
+      doesn't include the Forward Error Correction (FEC) columns
+      illustrated in Figure 11-1 of [ITU-T_G709_2020].  The OTUC signal
+      includes an ODUC.
+
+   *  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.
+
+   *  The combined signal OTUCn has n instances of OTUC overhead and n
+      instances of ODUC overhead.
+
+   The OTUCn, ODUCn, and OPUCn signal structures are presented in a
+   (physical) interface-independent manner, by means of n OTUC, ODUC,
+   and OPUC instances that are marked #1 to #n.
+
+   OTUCn interfaces can be categorized as follows, based on the type of
+   peer network element:
+
+   inter-domain interfaces:  These types of interfaces are used for
+      connecting OTN edge nodes to (a) client equipment (e.g., routers)
+      or (b) hand-off points from other OTN.  ITU-T Recommendation
+      G709.1 [ITU-T_G709.1] specifies a flexible interoperable short-
+      reach OTN interface over which an OTUCn (n >=1) is transferred,
+      using bonded Flexible OTN information structure (FlexO)
+      interfaces, which belong to a FlexO group.
+
+   intra-domain interfaces:  In these cases, the OTUCn is transported
+      using a proprietary (vendor-specific) encapsulation, FEC, etc.  It
+      is also possible to transport OTUCn for intra-domain links using
+      FlexO.
+
+3.1.1.  OTUCn-M
+
+   The standard OTUCn signal has the same rate as the ODUCn signal.
+   This implies that the OTUCn signal can only be transported over
+   wavelength groups that have a total capacity of multiples of
+   (approximately) 100 Gbit/s.  Modern optical interfaces support a
+   variety of 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*100
+   Gbit/s, it is possible to "crunch" the OTUCn, and the unused
+   tributary slots are thus not transmitted.  [ITU-T_G709_2020] supports
+   the notion of a reduced-rate OTUCn signal, termed "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.
+
+3.2.  ODUCn
+
+   The ODUCn signal defined in [ITU-T_G709_2020] 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 the frames have the same overhead and payload areas
+   but have a higher rate since their payload area can embed an ODU4
+   signal.
+
+   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 Figure 1).  In
+   Figure 1, the term "OTN Switch" has the same meaning as that used in
+   Section 3 of [RFC7138].  [ITU-T_G709_2020] allows for the ODUCn
+   signal to pass through one or more digital regenerator nodes (shown
+   as nodes B and C in Figure 2), which will terminate the OTUCn 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 [ITU-T_G872].  In this example, the ODUCn is carried
+   by three OTUCn segments.
+
+   Specifically, the OPUCn signal flows through these regenerators
+   unchanged.  That is, the set of client signals, their TPNs, and
+   tributary-slot allocations remains unchanged.
+
+                      +--------+           +--------+
+                      |        +-----------+        |
+                      | OTN    |-----------| OTN    |
+                      | Switch +-----------+ Switch |
+                      | A      |           | B      |
+                      |        +-----------+        |
+                      +--------+           +--------+
+                          <--------ODUCn------->
+                           <-------OTUCn------>
+
+                           Figure 1: ODUCn Signal
+
+    +---------+        +--------+        +--------+          +--------+
+    |         +--------+        |        |        +----------+        |
+    | OTN     |--------| OTN    |        | OTN    |----------| OTN    |
+    | Switch  +--------+ Regen  +--------+ Regen  +----------+ Switch |
+    | A       |        | B      |        | C      |          | D      |
+    |         +--------+        |        |        +----------+        |
+    +---------+        +--------+        +--------+          +--------+
+
+        <-------------------------ODUCn-------------------------->
+         <---------------><-----------------><------------------>
+              OTUCn              OTUCn               OTUCn
+
+                     Figure 2: ODUCn Signal - Multi-Hop
+
+3.3.  Tributary Slot Granularity
+
+   [ITU-T_G709_2012] introduced the support for 1.25 Gbit/s granular
+   tributary slots in OPU2, OPU3, and OPU4 signals.  [ITU-T_G709_2020]
+   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.
+
+3.4.  Structure of OPUCn MSI with Payload Type 0x22
+
+   As mentioned above, the OPUCn signal has 20*n tributary slots (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 (see Section 20.4.1 of
+   [ITU-T_G709_2020]):
+
+   *  The TS availability bit indicates if the tributary slot is
+      available or unavailable.
+
+   *  The TS occupation bit indicates if the tributary slot is allocated
+      or unallocated.
+
+   *  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.
+
+   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
+   [ITU-T_G709_2020].
+
+3.5.  Client Signal Mappings
+
+   The approach taken by the ITU-T to map non-OTN client signals to the
+   appropriate ODU containers is as follows:
+
+   *  All client signals are mapped into an ODUj or ODUk (e.g., ODUflex)
+      as specified in Section 17 of [ITU-T_G709_2020].
+
+   *  The terms "ODUj" and "ODUk" are used in a multiplexing scenario,
+      with ODUj being a low-order ODU that is multiplexed into ODUk, a
+      high-order ODU.  As Figure 3 illustrates, the ODUCn is also a
+      high-order ODU into which other ODUs can be multiplexed.  The
+      ODUCn itself cannot be multiplexed into any higher-rate ODU
+      signal; it is defined to be a section-level signal.
+
+   *  ODUflex signals are low-order signals only.  If the ODUflex
+      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
+      with rates greater than 100 Gbit/s, ODUCn is required.
+
+   *  ODU Virtual Concatenation (VCAT) has been deprecated.  This
+      simplifies the network and the supporting hardware since multiple
+      different mappings for the same client are no longer necessary.
+      Note that legacy implementations that transported sub-100 Gbit/s
+      clients using ODU VCAT shall continue to be supported.
+
+               Clients (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           |
+                                       +--------------------------+
+
+     Figure 3: Digital Structure of OTN Interfaces (from Figure 6-1 of
+                             [ITU-T_G709_2020])
+
+4.  GMPLS Implications and Applicability
+
+4.1.  TE Link Representation
+
+   Section 3 of [RFC7138] describes how to represent G.709 OTUk/ODUk
+   with TE links in GMPLS.  In the same manner, OTUCn links can also be
+   represented as TE links.  Figure 4 provides an illustration of a one-
+   hop OTUCn TE link.
+
+                 +----------+                   +---------+
+                 |  OTN     |                   |  OTN    |
+                 |  Switch  +-------------------+  Switch |
+                 |  A       |                   |  B      |
+                 +----------+                   +---------+
+
+                     |<---------OTUCn Link---------->|
+
+                     |<---------TE Link------------->|
+
+                      Figure 4: One-Hop OTUCn TE Link
+
+   It is possible to create TE links that span more than one hop by
+   creating forward adjacencies (FAs) between non-adjacent nodes (see
+   Figure 5).  In Figure 5, nodes B and C are performing the ODUCn
+   regeneration function described in Section 7.1 of [ITU-T_G872] and
+   are not electrically switching the ODUCn signal from one interface to
+   another.  As in the one-hop case, multi-hop TE links advertise the
+   ODU switching capability.
+
+   +--------+         +--------+          +--------+         +---------+
+   | OTN    |         |  OTN   |          |  OTN   |         |  OTN    |
+   | Switch |<------->|  Regen |<-------->|  Regen |<------->|  Switch |
+   | A      |  OTUCn  |  B     |   OTUCn  |  C     |  OTUCn  |  D      |
+   +--------+  Link   +--------+   Link   +--------+  Link   +---------+
+
+          |<-------------------- ODUCn Link -------------------->|
+
+          |<---------------------- TE Link --------------------->|
+
+                     Figure 5: Multi-Hop ODUCn TE Link
+
+   The two endpoints of a TE link are configured with the supported
+   resource information (which may include whether the TE link is
+   supported by an ODUCn, ODUk, or OTUk), as well as the link attribute
+   information (e.g., slot granularity and list of available tributary
+   slot).
+
+4.2.  GMPLS Signaling
+
+   Once the ODUCn TE link is configured, the GMPLS mechanisms defined in
+   [RFC7139] can be reused to set up ODUk/ODUflex LSPs with no changes.
+   As the resource on the ODUCn link that can be seen by the ODUk/
+   ODUflex client signal is a set of 5 Gbit/s slots, the label defined
+   in [RFC7139] is able to accommodate the requirement of the setup of
+   an ODUk/ODUflex client signal over an ODUCn link.  In [RFC7139], the
+   OTN-TDM GENERALIZED_LABEL object is used to indicate how the lower-
+   order (LO) ODUj signal is multiplexed into the 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 is indicated by Traffic Parameters.  The
+   IF_ID RSVP_HOP object provides a pointer to the interface associated
+   with TE link; therefore, the two nodes terminating the TE link know
+   (by internal/local configuration) the attributes of the ODUCn TE
+   Link.
+
+   The TPN defined in [ITU-T_G709_2020] (where it is referred to as
+   "tributary port #") for an ODUCn link has 14 bits while this field in
+   [RFC7139] 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., 40 Tbit/s links), this need is not urgent.
+
+   The example in Figure 6 illustrates the label format defined in
+   [RFC7139] for multiplexing ODU4 onto ODUC10.  One ODUC10 has 200
+   slots (each 5 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, which is very inefficient.  The inefficiency grows for larger
+   values of "n", and an optimized label format may be desirable.
+
+       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)                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Figure 6: Label Format
+
+4.3.  GMPLS Routing
+
+   For routing, it is deemed that no extension to the current mechanisms
+   defined in [RFC7138] is needed.
+
+   The ODUCn 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 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 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 [RFC7138].
+
+   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.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   This document analyzes the applicability of protocol extensions in
+   [RFC7138] and [RFC7139] for use in the 2020 version of ITU-T
+   Recommendation G.709 [ITU-T_G709_2020] and finds that no new
+   extensions are needed.  Therefore, this document introduces no new
+   security considerations to the existing signaling and routing
+   protocols beyond those already described in [RFC7138] and [RFC7139].
+   Please refer to [RFC7138] and [RFC7139] for further details of the
+   specific security measures.  Additionally, [RFC5920] addresses the
+   security aspects that are relevant in the context of GMPLS.
+
+7.  References
+
+7.1.  Normative References
+
+   [ITU-T_G709_2020]
+              ITU-T, "Interfaces for the optical transport network",
+              ITU-T Recommendation G.709, June 2020.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+              <https://www.rfc-editor.org/info/rfc5920>.
+
+   [RFC7138]  Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
+              J. Drake, "Traffic Engineering Extensions to OSPF for
+              GMPLS Control of Evolving G.709 Optical Transport
+              Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
+              <https://www.rfc-editor.org/info/rfc7138>.
+
+   [RFC7139]  Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
+              and K. Pithewan, "GMPLS Signaling Extensions for Control
+              of Evolving G.709 Optical Transport Networks", RFC 7139,
+              DOI 10.17487/RFC7139, March 2014,
+              <https://www.rfc-editor.org/info/rfc7139>.
+
+7.2.  Informative References
+
+   [ITU-T_G709.1]
+              ITU-T, "Flexible OTN short-reach interfaces", ITU-T
+              Recommendation G.709.1, June 2018.
+
+   [ITU-T_G709_2012]
+              ITU-T, "Interfaces for the optical transport network",
+              ITU-T Recommendation G.709, February 2012.
+
+   [ITU-T_G709_2016]
+              ITU-T, "Interfaces for the optical transport network",
+              ITU-T Recommendation G.709, June 2016.
+
+   [ITU-T_G872]
+              ITU-T, "Architecture of optical transport networks", ITU-T
+              Recommendation G.872, December 2019.
+
+   [RFC7062]  Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
+              Ceccarelli, "Framework for GMPLS and PCE Control of G.709
+              Optical Transport Networks", RFC 7062,
+              DOI 10.17487/RFC7062, November 2013,
+              <https://www.rfc-editor.org/info/rfc7062>.
+
+   [RFC7096]  Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed.,
+              Caviglia, D., Zhang, F., and D. Li, "Evaluation of
+              Existing GMPLS Encoding against G.709v3 Optical Transport
+              Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January
+              2014, <https://www.rfc-editor.org/info/rfc7096>.
+
+Appendix A.  Possible Future Work
+
+   As noted in Section 4.2, the GMPLS TPN field defined in Section 6.1
+   of [RFC7139] is only 12 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 way.
+
+   Section 4.2 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, 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 pairing of LSP encoding type and Generalized Payload Identifier
+   (G-PID) to ensure correct interoperability.
+
+Contributors
+
+   Iftekhar Hussain
+   Infinera Corp
+   Sunnyvale, CA
+   United States of America
+   Email: IHussain@infinera.com
+
+
+   Daniele Ceccarelli
+   Ericsson
+   Email: daniele.ceccarelli@ericsson.com
+
+
+   Rajan Rao
+   Infinera Corp
+   Sunnyvale,
+   United States of America
+   Email: rrao@infinera.com
+
+
+   Fatai Zhang
+   Huawei
+   Email: zhangfatai@huawei.com
+
+
+   Italo Busi
+   Huawei
+   Email: italo.busi@huawei.com
+
+
+   Dieter Beller
+   Nokia
+   Email: Dieter.Beller@nokia.com
+
+
+   Yuanbin Zhang
+   ZTE
+   Beijing
+   Email: zhang.yuanbin@zte.com.cn
+
+
+   Zafar Ali
+   Cisco Systems
+   Email: zali@cisco.com
+
+
+   Daniel King
+   Email: d.king@lancaster.ac.uk
+
+
+   Manoj Kumar
+   Cisco Systems
+   Email: manojk2@cisco.com
+
+
+   Antonello Bonfanti
+   Cisco Systems
+   Email: abonfant@cisco.com
+
+
+   Yuji Tochio
+   Fujitsu
+   Email: tochio@fujitsu.com
+
+
+Authors' Addresses
+
+   Qilei Wang (editor)
+   ZTE Corporation
+   Nanjing
+   China
+   Email: wang.qilei@zte.com.cn
+
+
+   Radha Valiveti (editor)
+   Infinera Corp
+   Sunnyvale, CA
+   United States of America
+   Email: rvaliveti@infinera.com
+
+
+   Haomian Zheng (editor)
+   Huawei
+   China
+   Email: zhenghaomian@huawei.com
+
+
+   Huub van Helvoort
+   Hai Gaoming BV
+   Almere
+   Netherlands
+   Email: huubatwork@gmail.com
+
+
+   Sergio Belotti
+   Nokia
+   Email: sergio.belotti@nokia.com