Internet Engineering Task Force (IETF)                      Q. Wang, Ed.
Internet-Draft
Request for Comments: 9376                               ZTE Corporation
Intended status:
Category: Informational                                 R. Valiveti, Ed.
Expires: 22 May 2023
ISSN: 2070-1721                                            Infinera Corp
                                                           H. Zheng, Ed.
                                                                  Huawei
                                                         H. van Helvoort
                                                          Hai Gaoming B.V BV
                                                              S. Belotti
                                                                   Nokia
                                                        18 November 2022
                                                              March 2023

 Applicability of GMPLS for Beyond 100G beyond 100 Gbit/s Optical Transport Network
           draft-ietf-ccamp-gmpls-otn-b100g-applicability-15

Abstract

   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.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 May 2023.
   https://www.rfc-editor.org/info/rfc9376.

Copyright Notice

   Copyright (c) 2022 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)
   (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
   2.  OTN terminology used Terminology Used in this document . . . . . . . . . . . .   3 This Document
   3.  Overview of the OTUCn/ODUCn in G.709  . . . . . . . . . . . .   5
     3.1.  OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  OTUCn-M . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Tributary Slot Granularity  . . . . . . . . . . . . . . .   8
     3.4.  Structure of OPUCn MSI with Payload type Type 0x22 . . . . . .   8
     3.5.  Client Signal Mappings  . . . . . . . . . . . . . . . . .   9
   4.  GMPLS Implications and Applicability  . . . . . . . . . . . .  10
     4.1.  TE-Link  TE Link Representation  . . . . . . . . . . . . . . . . .  10
     4.2.  Implications and Applicability for  GMPLS Signalling . . .  11 Signaling
     4.3.  Implications and Applicability for  GMPLS Routing  . . . .  12
   5.  Authors (Full List) . . . . . . . . . . . . . . . . . . . . .  13
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Possible Future Work . . . . . . . . . . . . . . . .  16
   Contributors
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The current GMPLS routing [RFC7138] and signalling 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 2016, a further new version of ITU-T Recommendation G.709 was published:
   [ITU-T_G709_2016].  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 [ITU-T_G709_2016], 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.

   Because [ITU-T_G709_2020] does not introduce any new features to
   OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts
   with [ITU-T_G709_2020] by first presenting
   presents an overview of the OTUCn and ODUCn signals, signals in
   [ITU-T_G709_2020] 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.

   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 [RFC7062] and [RFC7096].  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 & and signaling mechanisms to
   support the evolution in OTN networks. OTN.

2.  OTN terminology used Terminology Used in this document

   * This Document

   FlexO:  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.

   *

   LSP:  Label Switched Path.

   * 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
      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.

   *  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.

   *  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.

   * they encapsulate.

   ODUC:  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 [ITU-T_G709_2020].  This signal represents the
      building block for constructing a higher rate higher-rate signal called ODUCn
      "ODUCn" (defined below).

   *

   ODUCn:  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
      [ITU-T_G709_2020].

   *  OPUC:

   ODUflex:  Optical Payload 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.
      [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
      100G. 100 Gbit/s.  This structure represents the payload
      area of the ODUC signal.

   *

   OPUCn:  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.

   *

   OTN:  Optical Transport Network

   OTUC:  Optical Transport Unit -C; with 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.

   * 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-1 11-4 of [ITU-T_G709_2020].  Note that the term "fully
      standardized" is defined by ITU-T in
      [ITU-T_G709_2020]:Section 6.1.1.

   * 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, 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.

   *  OTN: Optical Transport Network.

   *

   PSI: OPU  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.

   *  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).

   *

   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 the 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 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, "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:

   *  The OTUCn signal contains one ODUCn.  The OTUCn and ODUCn signals
      perform digital section section-layer roles only (see
      [ITU-T_G709_2020]:Section 6.1.1) Section 6.1.1 of
      [ITU-T_G709_2020])

   *  The OTUCn signals can be viewed as being 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 FEC Forward Error Correction (FEC) columns
      illustrated in
      [ITU-T_G709_2020]:Figure 11-1. 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, overhead and n
      instances of ODUC overhead.

   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.

   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. (e.g., routers)
      or (b) hand-off points from other OTN networks. OTN.  ITU-T Recommendation
      G709.1 [ITU-T_G709.1] specifies a flexible interoperable
      short-reach short-
      reach OTN interface over which an OTUCn (n >=1) is transferred,
      using bonded Flexible OTN information structure (FlexO) interfaces
      interfaces, which belong to a FlexO group.

   *

   intra-domain interfaces:  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.

3.1.1.  OTUCn-M

   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.  [ITU-T_G709_2020] 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.

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 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.

   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 Figure 1).  In
   this figure,
   Figure 1, the term "OTN Switch" has the same meaning as that used in [RFC7138]:Section 3.
   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, nodes B and C in Figure 2) 2), 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
   [ITU-T_G872]:Section 7.1.
   Section 7.1 of [ITU-T_G872].  In this example, the ODUCn is carried
   by 3 three OTUCn segments.

   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.

                      +--------+           +--------+
                      |        +-----------+        |
                      | OTN    |-----------| OTN    |
                      | Switch +-----------+ Switch |
                      | A      |           | B      |
                      |        +-----------+        |
                      +--------+           +--------+
                          <--------ODUCn------->
                           <-------OTUCn------>

                           Figure 1: ODUCn signal Signal

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

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

                     Figure 2: ODUCn signal Signal - multihop 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 Type 0x22

   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
   ([ITU-T_G709_2020]:Section 20.4.1): (see Section 20.4.1 of
   [ITU-T_G709_2020]):

   *  The TS availability bit indicates if the tributary slot is
      available or unavailable unavailable.

   *  The TS occupation bit indicates if the tributary slot is allocated
      or unallocated 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
   [ITU-T_G709_2020]:Figure 15-6. 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, ODUj or ODUk (e.g., ODUflex)
      as specified in clause Section 17 of [ITU-T_G709_2020].

   *  The terms ODUj & 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
      high-order ODU.  As Figure 3 illustrates, the ODUCn is also a high-
      order
      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.

   *  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.

   *  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.

               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           |
                                       +--------------------------+

     Figure 3: Digital Structure of OTN interfaces Interfaces (from G.709:Figure 6-1) Figure 6-1 of
                             [ITU-T_G709_2020])

4.  GMPLS Implications and Applicability

4.1.  TE-Link  TE Link Representation

   Section 3 of RFC7138 [RFC7138] 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.  Figure 4 below provides an illustration of a one-hop one-
   hop OTUCn TE link.

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

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

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

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

                      Figure 4: One-Hop OTUCn TE-Links TE Link

   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
   Figure 5).  In this illustration, the Figure 5, nodes B and C are performing the ODUCn
   regeneration function described in
   [ITU-T_G872]:Section 7.1, 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,
   Multiple-hop TE-links multi-hop TE links advertise the
   ODU switching capability.

   +--------+         +--------+          +--------+         +---------+
   | 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 --------------------->|

                     Figure 5: Multiple-hop Multi-Hop ODUCn TE-Link TE Link

   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).

4.2.  Implications and Applicability for  GMPLS Signalling Signaling

   Once the ODUCn TE-Link 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 which that can be seen by the ODUk/
   ODUflex client
   ODUk/ODUflex 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 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.

   Since the

   The TPN defined in [ITU-T_G709_2020] (where it is referred to as
   "tributary port #") for an ODUCn link has 14
   bits, 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. 40Tbit/s (i.e., 40 Tbit/s links), this need is not urgent.

   An

   The example is given in Figure 6 to illustrate illustrates the label format defined in
   [RFC7139] 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.

       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 Format

4.3.  Implications and Applicability for  GMPLS Routing

   For routing, it is deemed that no extension to the current mechanisms
   defined in [RFC7138] is needed.  Because, once an

   The ODUCn link link, which is up, 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 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 [RFC7138].

   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.

   The OSPF-TE extension defined in section 4 of [RFC7138] can be reused
   to advertise the resource information on the ODUCn link to help
   finish the setup of ODUk/ODUflex.

5.  Authors (Full List)

      Qilei Wang (editor)

      ZTE

      Nanjing, China

      Email: wang.qilei@zte.com.cn

      Radha Valiveti (editor)

      Infinera Corp

      Sunnyvale, CA, USA

      Email: rvaliveti@infinera.com

      Haomian Zheng (editor)

      Huawei

      CN

      EMail: zhenghaomian@huawei.com

      Huub van Helvoort

      Hai Gaoming B.V

      EMail: huubatwork@gmail.com

      Sergio Belotti

      Nokia

      EMail: sergio.belotti@nokia.com

6.  Contributors

      Iftekhar Hussain, Infinera Corp, Sunnyvale, CA, USA,
      IHussain@infinera.com

      Daniele Ceccarelli, Ericsson, daniele.ceccarelli@ericsson.com

      Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com

      Fatai Zhang, Huawei,zhangfatai@huawei.com
      Italo Busi, Huawei,italo.busi@huawei.com

      Dieter Beller, Nokia, Dieter.Beller@nokia.com

      Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn

      Zafar Ali, Cisco Systems, zali@cisco.com

      Daniel King, d.king@lancaster.ac.uk

      Manoj Kumar, Cisco Systems, manojk2@cisco.com

      Antonello Bonfanti, Cisco Systems, abonfant@cisco.com

      Yuji Tochio, Fujitsu, tochio@fujitsu.com

7.  IANA Considerations

   This memo includes document has no request to IANA.

8. IANA actions.

6.  Security Considerations

   This document analyzed 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] [ITU-T_G709_2020] 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 [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.

9.

7.  References

9.1.

7.1.  Normative References

   [ITU-T_G709_2020]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              06/2020", "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>.

9.2.

7.2.  Informative References

   [ITU-T_G709.1]
              ITU-T, "ITU-T G.709.1: Flexible "Flexible OTN short-reach interface;
              2018", interfaces", ITU-T
              Recommendation G.709.1, June 2018.

   [ITU-T_G709_2012]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              02/2012", "Interfaces for the optical transport network",
              ITU-T Recommendation G.709, February 2012.

   [ITU-T_G709_2016]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              07/2016", July "Interfaces for the optical transport network",
              ITU-T Recommendation G.709, June 2016.

   [ITU-T_G872]
              ITU-T, "ITU-T G.872: Architecture "Architecture of Optical Transport
              Networks; 12/2019", 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 Section 4.2, the GMPLS TPN field defined in Section 6.1
   of [RFC7139] 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.

   Section 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 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.

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
   USA
   Sunnyvale, CA
   United States of America
   Email: rvaliveti@infinera.com

   Haomian Zheng (editor)
   Huawei
   China
   Email: zhenghaomian@huawei.com

   Huub van Helvoort
   Hai Gaoming B.V BV
   Almere
   Netherlands
   Email: huubatwork@gmail.com

   Sergio Belotti
   Nokia
   Email: sergio.belotti@nokia.com