Internet Engineering Task Force                             Q. Wang, Ed.
Internet-Draft                                           ZTE Corporation
Intended status: Informational                          R. Valiveti, Ed.
Expires: September 7, 2020 May 5, 2021                                       Infinera Corp
                                                           H. Zheng, Ed.
                                                                  Huawei
                                                             H. Helvoort
                                                         Hai Gaoming B.V
                                                              S. Belotti
                                                                   Nokia
                                                           March 6,
                                                        November 1, 2020

       Applicability of GMPLS for B100G Optical Transport Network
           draft-ietf-ccamp-gmpls-otn-b100g-applicability-02
           draft-ietf-ccamp-gmpls-otn-b100g-applicability-03

Abstract

   This document examines the applicability of using current existing
   GMPLS routing and signaling signalling mechanisms to set up ODUk/ODUflex ODUk (e.g.,
   ODUflex) LSP over ODUCn link, links, as a result of the introduction of OTU/ODU links with rates larger
   than 100G defined in the 2016 version of
   G.709.

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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 September 7, 2020. May 5, 2021.

Copyright Notice

   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  OTN terminology used in this document . . . . . . . . . . . .   3
   3.  Overview of B100G the OTUCn/ODUCn in G.709  . . . . . . . . . . . . . . . . .   4   3
     3.1.  OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  ODUCn . .   3
       3.1.1.  OTUCn-M . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  ODUCn .   6
     3.3.  OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.4.   6
     3.3.  Time Slot Granularity . . . . . . . . . . . . . . . . . .   8
     3.5.   7
     3.4.  Structure of OPUCn MSI with Payload type 0x22 . . . . . .   8
     3.6.   7
     3.5.  Client Signal Mappings  . . . . . . . . . . . . . . . . .   8
   4.  Applicability and  GMPLS Implications and Applicability  . . . . . . . . . . . .  10   9
     4.1.  Applicability and Challenges  TE-Link Representation  . . . . . . . . . . . . . .  10 . . .   9
     4.2.  Implications and Applicability for GMPLS Signalling . . .  10
     4.3.  Implications and Applicability for GMPLS Routing  . . . .  11
   5.  Acknowledgements  . . . . . . .  12
       4.2.1.  TE-Link Representation . . . . . . . . . . . . . . .  12
       4.2.2.  Implications and Applicability for GMPLS Signalling
   6.  Authors (Full List) .  13
       4.2.3.  Implications and Applicability for GMPLS Routing . .  14
   5.  Acknowledgements . . . . . . . . . . . . . . . . . .  12
   7.  Contributors  . . . .  15
   6.  Authors (Full List) . . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations .  15
   7.  Contributors . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . .  14
   10. References  . . . . . .  17
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   10.  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . .  17 . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18  14

1.  Introduction

   The current GMPLS routing [RFC7138] and signaling extensions signalling [RFC7139] only supports
   extensions support the control of OTN signals and capabilities that
   were defined in the 2012 version of G.709 [ITU-T_G709_2012].

   Since the publishment of the latest

   In 2016 a new version of G.709
   [ITU-T_G709_2016], which was published: [ITU-T_G709_2016].
   This version introduces support for new higher rate OTU and ODU signals, termed
   OTUCn and ODUCn (which respectively, which have a nominal rate of n x 100 Gbps),
   how
   Gbit/s.  According to applied GMPLS to ODUCn case should be taken into
   consideration.  As the definition in G.709 [ITU-T_G709_2016],
   OTUCn and ODUCn only perform only section layer role
   only according to the definition in G.709 [ITU-T_G709_2016], which
   means the OTUCn and ODUCn are supports
   only used to provide for ODUk clients.  This document focuses on the transfer
   of information between two adjacent upper layer cross-connects, i.e.,
   ODUk/ODUflex cross connects, it's not appropriate to apply GMPLS to
   OTUCn and ODUCn.  Therefore, this document mainly focuses on the use use of existing
   GMPLS mechanisms to set up ODUk/ODUflex ODUk (e.g., ODUflex) LSP over an existing ODUCn
   link. links,
   independently from how these links have been set up
   This document first presents an overview of the changes OTUCn and ODUCn signals
   introduced in [ITU-T_G709_2016] to motivate the present topic and then analyzes analyses how the current GMPLS
   routing and signalling mechanisms can be utilized to setup ODUk/ODUflex connections ODUk
   (e.g., ODUflex) LSPs over ODUCn links.  In order to make
   the description in this document clear, how to set up ODUCn link is
   also mentioned.

1.1.  Scope

   For the purposes of the B100G control plane

   Note: after discussion, the OTN
   should be considered as a combination of ODU and OTSi layers.  Note
   that [ITU-T_G709_2016] is deprecating the use authors did not see any impact of the term "OCh" for
   B100G entities, and leaving it intact only for maintaining continuity
   in the description 2020
   version of the signals with bandwidth upto 100G.

   This document only focuses G.709 on the control of the ODU layer.  The
   control of the OTSi layer is out of scope of this document.  But in
   order to facilitate the description of the challenges brought by
   [ITU-T_G709_2016] to B100G GMPLS routing and signalling, some general
   description about OTSi is included in section 4 of this document. draft.

2.  OTN terminology used in this document

   a.  OPUCn: Optical Payload Unit -Cn. - Cn.  Where Cn = number of n-bit
       client data entities.

   b.  ODUCn: Optical Data Unit - Cn.

   c.  OTUCn: Fully standardized Optical Transport Unit - Cn.

   d.  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  Specifically, the payload area consists of M 5G
       tributary slots (where M is strictly less than 20*n).

   e.  PSI: OPU Payload structure Structure Indicator.  This is a multi-frame
       message and 256-byte signal
       that describes the composition of the OPU signal.  This field is
       a concatenation of the Payload type (PT) and the Multiplex Structrure
       Structure Indicator (MSI) defined below.

   f.  MSI: Multiplex Structure Indicator.  This structure indicates the
       grouping of the tributary slots in an OPU payload area to realize that
       realizes a client signal that which is multiplexed into an OPU.  The
       individual clients multiplexed into the OPU payload area are
       distinguished by the Tributary Port number (TPN).

   g.  GMP: Generic Mapping Procedure.

   h.  OTSiG: The set of OTSi that supports a single digital client.

   i.  OTSiA: The OTSiG together with the non-associated overhead
       (OTSiG-O).

   Detailed description of these terms can be found in [ITU-T_G709_2016]
   and [ITU-T_G807].
   [ITU-T_G709_2016].

3.  Overview of B100G the OTUCn/ODUCn in G.709

   This section provides an overview of new features OTUCn/ODUCn signals defined in
   [ITU-T_G709_2016].

3.1.  OTUCn

   In order to carry client signals with rates greater than 100Gbps, 100 Gbit/s,
   [ITU-T_G709_2016] 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*100G.  The following are the key characteristics of
   the OTUCn signal:

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

   b.  The OTUCn signals can be viewed as being formed by interleaving n
       OTUC signals (which are labeled 1, 2, ..., n), each of which has
       the format of a standard OTUk signal without the FEC columns (per
       [ITU-T_G709_2016]Figure 7-1).  The ODUCn have a similar
       structure, i.e. they can be seen as being formed by interleaving
       n instances of ODUC signals (respectively).  The OTUC signal
       contains the ODUC signals, just as in the case of fixed rate OTUs
       defined in G.709 [ITU-T_G709_2016].

   c.  Each of the OTUC "slices" have the same overhead as the standard
       OTUk signal in G.709 [ITU-T_G709_2016].  The combined signal
       OTUCn has n instances of OTUC overhead, ODUC overhead.

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

   As explained above, within G.709 [ITU-T_G709_2016], 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.  Specifically, the definition of the OTUCn
   signal does not cover aspects such as FEC, modulation formats, etc.
   These details are defined as part of the adaptation of the OTUCn
   layer to the optical layer(s).  The specific interleaving of
   OTUC/ODUC/OPUC signals onto the optical signals is interface specific
   and specified for OTN interfaces with standardized application codes
   in the interface specific recommendations (G.709.x).

   OTUCn interfaces can be categorized as follows, based on the type of
   peer network element (see Figure 1):

   a.  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 networks.  ITU-T has
       standardized the Flexible OTN (FlexO) interfaces to support these
       functions.  For example, Recommendation [ITU-T_G709.1] specifies
       a flexible interoperable short-reach OTN interface over which an
       OTUCn (n >=1) is transferred, using bonded FlexO interfaces which
       belong to a FlexO group.

   b.  intra-domain interfaces: In these cases, the OTUCn is transported
       using a proprietary (vendor specific) encapsulation, FEC etc.  It
       may also be possible to transport OTUCn for intra-domain links
       using FlexO.

    ==================================================================

          +--------------------------------------------------------+
          |                 OTUCn signal                           |
          +--------------------------------------------------------+
          |  Inter+Domain    |  Intra+Domain    |  Intra+Domain    |
          |  Interface (IrDI)|  Interface (IaDI)|  Interface       |
          |  FlexO (G.709.1) |  FlexO (G.709.x) |  Proprietary     |
          |                  |  (Future)        |  Encap, FEC etc. |
          +--------------------------------------------------------+

    ==================================================================

                  Figure 1: OTUCn transport possibilities

3.2.  ODUCn

3.1.1.  OTUCn-M

   The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by
   the appropriate interleaving of content from n ODUC standard OTUCn signal instances.
   The ODUC frames have has the same structure rate as a standard ODU -- in the
   sense that it has the same Overhead area, and of the payload area -- but
   has a higher rate since its payload area can embed an ODU4 signal.

   The ODUCn signals have a rate that is captured
   signal as shown in Table 1.

   +----------+--------------------------------------------------------+
   | ODU Type |                      ODU  This implies that the OTUCn signal can
   only be transported over wavelength groups which have a total
   capacity of multiples of (approximately) 100G.  Modern DSPs support a
   variety of bit rates per wavelength, depending on the reach
   requirements for the optical path.  In other words, it is possible to
   extend the reach of an optical path (i.e. increase the physical
   distance covered) by lowering the bitrate of the digital signal that
   is modulated onto the optical signals.  If the total rate of the ODUk
   LSPs planned to be carried over an ODUCn link is smaller than n*100G,
   it is possible to "crunch" the OTUCn not to transmit some of unused
   timeslots.  With this in mind, ITU-T supports the notion of a reduced
   rate OTUCn signal, termed the OTUCn-M.  The OTUCn-M signal is derived
   from the OTUCn signal by retaining all the n instances of overhead
   (one per OTUC slice) but with only M (M is less than 20*n) OPUCn
   tributary slots available to carry ODUk LSPs.

   As the "crunching" algorithm is not standardized, knowing the value
   of M is not enough to decide the timeslot availability.

3.2.  ODUCn

   The ODUCn signal [ITU-T_G709_2016] 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 same Overhead area, and the payload area -- but
   has a higher rate since its payload area can embed an ODU4 signal.

   The ODUCn signals have a rate that is captured in Table 1.

   +----------+--------------------------------------------------------+
   | ODU Type |                      ODU Bit Rate                      |
   +----------+--------------------------------------------------------+
   |  ODUCn   | n x 239/226 x 99,532,800 kbit/s Kbit/s = n x 105,258,138.053  |
   |          |                         kbit/s                         Kbit/s                         |
   +----------+--------------------------------------------------------+

                           Table 1: ODUCn rates

   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 co-terminated, i.e.
   they will have identical source/sink locations.  [ITU-T_G709_2016]
   and [ITU-T_G872] allow
   allows for the ODUCn signal to pass through a digital regenerator
   node 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 (see Figure 2).
   In this case, the ODUCn is carried by 3 OTUCn segments.

   Specifically, the OPUCn signal flows through these regenerators
   unchanged.  That is, the set of client signals, their TPNs, trib-slot
   allocation remains unchanged.  The ODUCn Overhead might be modified
   if TCM sub-layers are instantiated in order to monitor the
   performance of the regenerator hops.  In this sense, the ODUCn should
   NOT be seen as a general ODU which can be switched via an ODUk cross-
   connect.

   ==================================================================

    +--------+           +--------+
    |        +-----------+        |
    | OTN    |-----------| OTN    |
    | DXC    +-----------+ DXC    +
    |        |           |        |
    +--------+           +--------+
        <--------ODUCn------->
         <-------OTUCn------>

    +--------+        +--------+        +--------+          +--------+
    |        +--------+        |        |        +----------+        |
    | OTN    |--------| OTN    |        | OTN    |----------| OTN    |
    | DXC    +--------+ WXC    +--------+ WXC    +----------+ DXC    |
    |        |        | 3R     |        | 3R     |          |        |
    +--------+        +--------+        +--------+          +--------+
        <-------------------------ODUCn-------------------------->
         <---------------> <---------------> <------------------>
              OTUCn              OTUCn               OTUCn

   ==================================================================

                          Figure 2: ODUCn signal

3.3.  OTUCn-M

   The standard OTUCn signal has the same rate as that of the ODUCn
   signal as captured in Table 1.  This implies that the OTUCn signal
   can only be transported over wavelength groups which have a total
   capacity of multiples of (approximately) 100G.  Modern DSPs support a
   variety of bit rates per wavelength, depending on the reach
   requirements for the optical link.  In other words, it is possible to
   extend the reach of an optical link (i.e. increase the physical
   distance covered) by lowering the bitrate of the client signal that
   is modulated onto the optical signals.  By the very nature of the
   OTUCn signal, it is constrained to rates which are multiples of
   (approximately) 100G.  If it happens that the total rate of the LO-
   ODUs carried over the ODUCn is smaller than n X 100G, it is possible
   to "crunch" the OTUCn to remove the unused capacity.  With this in
   mind, ITU-T supports the notion of a reduced rate OTUCn signal,
   termed the OTUCn-M.  The OTUCn-M signal is derived from the OTUCn
   signal by retaining all the n instances of overhead (one per OTUC
   slice) but only M tributary slots of capacity.

3.4.  Time Slot Granularity

   [ITU-T_G709_2012] has introduced the support for 1.25G granular
   tributary slots in OPU2, OPU3, and OPU4 signals.  With the
   introduction of higher rate signals, it is not practical for the
   optical networks (and the data plane hardware) to support a very
   large number of connections at such a fine granularity.  ITU-T  [ITU-
   T_G709_2012] has defined the OPUC with a 5G tributary slot granularity of 5G.
   granularity.  This means that the ODUCn signal has 20*n tributary
   slots (of 5Gbps 5 Gbit/s capacity).  It is worthwhile considering that 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.5.

3.4.  Structure of OPUCn MSI with Payload type 0x22

   As mentioned above, the OPUCn signal has 20*n 5G tributary slots.
   The OPUCn contains n PSI structures, one per OPUC instance.  The PSI
   structure consists of the Payload Type (of 0x22), followed by a
   Reserved Field (1 byte) and the MSI.  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_2016] G.709:Section 20.4.1):

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

   b.  The TS occupation bit indicates if the tributary slot is
       allocated or unallocated

   c.  The tributary port bits indicates the port number (14 bits) 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 10n.

3.6. 10*n.

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:

   a.  All client signals with rates less than 100G are mapped into ODU
       container as specified in clause 17 of [ITU-T_G709_2016].  These
       mappings are identical to those specified in the earlier revision
       of G.709 [ITU-T_G709_2012].  For example, the 1000BASE-
       X/10GBASE-R signals are mapped to ODU0/ODU2e respectively (see
       Table 2 -- based on Table 7-2 in [ITU-T_G709_2016])

   b.  New emerging client signals are usually mapped into ODUflex
       signals of the appropriate rates (see Table 2 according to the
       Table 7-2 in [ITU-T_G709_2016])

   c.  ODU Virtual Concatenation is not supported any more.  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-100G clients using ODU VCAT shall continue to be supported.

   d.  ODUflex signals are low-order signals only.  If the ODUflex
       entities have rates of 100G or less, they can be transported over
       either an ODUk (k=1..4) or an ODUCn.  For ODUflex connections
       with rates greater than 100G, ODUCn is required.

   +----------------+--------------------------------------------------+
   |    ODU Type    |                   ODU Bit Rate                   |
   +----------------+--------------------------------------------------+
   |      ODU0      |                  1,244,160 Kbps                  |
   |      ODU1      |             239/238 x 2,488,320 Kbps             |
   |      ODU2      |             239/237 x 9,953,280 Kbps             |
   |     ODU2e      |            239/237 x 10,312,500 Kbps             |
   |      ODU3      |            239/236 x 39,813,120 Kbps             |
   |      ODU4      |            239/227 x 99,532,800 Kbps             |
   |  ODUflex for   |         239/238 x Client signal Bit rate         |
   |   CBR client   |                                                  |
   |    signals     |                                                  |
   |  ODUflex for   |               Configured bit rate                |
   |  GFP-F mapped  |                                                  |
   | packet traffic |                                                  |
   |  ODUflex for   | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >=  |
   |   IMP mapped   |                        1                         |
   | packet traffic |                                                  |
   |  ODUflex for   | 103 125 000 x 240/238 x n/20 kbit/s, where n is  |
   |  FlexE aware   | total number of available tributary slots among  |
   |   transport    | all PHYs which have been crunched and combined.  |
   +----------------+--------------------------------------------------+

     Note that this table doesn't include ODUCn -- since it cannot be
   generated by mapping a non-OTN signal.  An ODUCn is always formed by
                      multiplexing multiple LO-ODUs.

        Table 2: Types and rates of ODUs usable for client mappings

    ==================================================================

                     Clients (e.g. SONET/SDH, Ethernet)
                          +       +      +
                          |       |      |
       +------------------+-------+------+------------------------+
       |                     OPUk                                 |
       +----------------------------------------------------------+
       |                     ODUk                                 |
       +-----------------------+---------------------------+------+
       | OTUk, OTUk.V, OTUkV   |          OPUk             |      |
       +----------+----------------------------------------+      |
       | OTLk.n   |            |          ODUk             |      |
       +----------+            +---------------------+-----+      |
                               | OTUk, OTUk.V, OTUkV |   OPUCn    |
                               +----------+-----------------------+
                               | OTLk.n   |          |   ODUCn    |
                               +----------+          +------------+
                                                     |   OTUCn    |
                                                     +------------+

    ==================================================================

   Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1)

4.  Applicability and GMPLS Implications

4.1.  Applicability and Challenges

   This section analyzes the OTUCn deployment scenarios to identify
   potential extensions to GMPLS that would be needed.  When OTUCn links
   are established between line ports of two different network elements,
   two scenarios are possible.  These scenarios are modeled according to
   those illustrated in Appendix XIII of [ITU-T_G709_2016].  Note that
   while this Appendix illustrates OTUCn subrating possibilities, the
   scenarios serve a more general purpose also.  Two possible
   realization of OTUCn realizations between nodes are:

   a.  The first scenario (see Figure 4) deploys OTUCn/OTUCn-M between
       two line ports connecting two L1/L0 ODU cross connects (XC)
       within one optical transport network.  As defined in
       [ITU-T_G807], the OTUCn/OTUCn-M signal is transported using by
       one OTSiG, which could be comprised of one or more OTSi.  The
       OTSiG may have non-associated overhead (denoted as OTSiG-O); the
       combination of the OTSiG and OTSiG-O is represented by the OTSiA
       management/control abstraction.  There is a 1:1 mapping
       relationship between OTUCn and OTSiG or OTSiA.  For example, a
       400G OTUC4 signal can be carried over a single OTSi signal with a
       400G capcity, or perhaps split into 4 100G digital information
       streams each of which is carried over a OTSi signal with a 100G
       capacity.  In this scenario, it is clear that the OTUCn and ODUCn
       link can be automatically established, after/together with the
       setup of OTSiG or OTSiA, as both OTUCn and ODUCn perform section
       layer only.  Once the ODUCn link is automatically established, it
       can be advertized as a TE-link and used for setting up ODUk/
       ODUflex connections.

   b.  The second scenario (see depicted in Figure 5) deploys OTUCn/
       OTUCn-M between transponders which are in a different domain B,
       and are separated from the L1 ODU XCs in domain A and/or C.  In
       this scenario, the end-to-end ODUCn is actually supported by
       three different OTUCn or OTUCn-M segments, which are in turn
       carried by their respective OTSi(G) or OTSiA.  In this example,
       the OTUCn links will be established automatically after/together
       with the setup of OTSi(G) or OTSiA.  Note that until both
       transponder nodes in domain B have been configured, the ODUCn
       signal transmitted by node A doesn't reach node C.  Until all the
       required configuration operations are completed, the ODUCn.STAT
       field will reflect the AIS (i.e. error) status.  Once all the
       provisioning ODUk (e.g., ODUflex) as
       specified in clause 17 of [ITU-T_G709_2016].

   b.  ODU Virtual Concatenation has been performed in domain B, deprecated.  This simplifies
       the network, and the links
       connecting supporting hardware since multiple different
       mappings for the edge nodes to transponders in domain B same client are error
       free, the end no longer necessary.  Note that
       legacy implementations that transported sub-100G clients using
       ODU VCAT shall continue to end ODUCn flows will be established.  In this
       case, supported.

   c.  ODUflex signals are low-order signals only.  If the receipt ODUflex
       entities have rates of a normal value for the ODUCn.STAT field 100G or less, they can
       trigger the creation of the ODUCn link.

   ==================================================================

                 +--------+                     +--------+
                 |        +---------------------+        |
                 | OTN    |---------------------| OTN    |
                 |  XC    +---------------------+  XC    |
                 |        |                     |        |
                 +--------+                     +--------+
                   <---------- ODUk/ODUflex ----------->
                    <------------ be transported over
       either an ODUk (k=1..4) or an ODUCn.  For ODUflex connections
       with rates greater than 100G, ODUCn -------------->
                     <------- OTUCn/OTUCn-M --------->
                      <--------OTSi(G)/OTSiA--------->

   ==================================================================

                           Figure 4: Scenario A is required.

    ==================================================================

                       +----------------------------+
        A              |             B              |          A or C
        |              |                            |

                     Clients (e.g. SONET/SDH, Ethernet)
                          +       +      +
                          |
   +--------+       | +--------+      +--------+      |        +--------+
       +------------------+-------+------+------------------------+
       |        +----------|-+                     OPUk                                 |
       +----------------------------------------------------------+
       |        +-|--------+                     ODUk                                 |
       +-----------------------+---------------------------+------+
       | OTN    |----------|-| Transp OTUk, OTUk.V, OTUkV   |          OPUk             | Transp |-|--------| OTN      |
       +----------+----------------------------------------+      |  XC    +----------|-+ onder  +------+ onder  +-|--------+  XC
       | OTLk.n   |            |          ODUk             |      |
       +----------+            +---------------------+-----+      |
                               | OTUk, OTUk.V, OTUkV |   OPUCn    |
                               +----------+-----------------------+
                               | OTLk.n   |
   +--------+          | +--------+      +--------+   ODUCn    |        +--------+
                               +----------+          +------------+
                                                     |   OTUCn    |
                       +----------------------------+

        <------------------------ODUk/ODUflex----------------------->
         <------------------------ ODUCn -------------------------->
          <------OTUCn------><---OTUCn/OTUCn-M---><------OTUCn------>
           <-OTSi(G)/OTSiA->  <--OTSi(G)/OTSiA-->  <-OTSi(G)/OTSiA->
                                                     +------------+

    ==================================================================

   Figure 5: Scenario B

4.2. 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1)

4.  GMPLS Implications and Applicability

4.2.1.

4.1.  TE-Link Representation

   Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with
   TE-Links in GMPLS.  Similar to that, ODUCn links can also be
   represented as TE-Links, which can be seen in the figure below.

   ==================================================================

  +-----+              +-----+
  |     |              |     |
  |  A  |<-OTUCn Link->|  B  |
  |     |              |     |
  +-----+              +-----+
     |<--- ODUCn Link -->|
     |<---- TE-Link ---->|

                         3R                    3R
  +-----+              +-----+              +-----+              +-----+
  |     |              |     |              |     |              |     |
  |  A  |<-OTUCn Link->|  B  |<-OTUCn Link->|  C  |<-OTUCn Link->|  D  |
  |     |              |     |              |     |              |     |
  +-----+              +-----+              +-----+              +-----+
      |<----------------------- ODUCn Link ------------------------>|
      |<------------------------ TE-Link -------------------------->|

   ==================================================================

                         Figure 6: 4: ODUCn TE-Links

   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 or an ODUk or an OTUk, as well as the link attribute
   information (e.g., slot granularity, number list of available tributary slot
   available).

4.2.2.
   slot).

4.2.  Implications and Applicability for GMPLS Signalling

   Once the ODUCn link TE-Link is configured, the GMPLS mechanisms defined in
   RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes.
   As the resource on the ODUCn link which can be seen by the client
   ODUk/ODUflex is a set of 5G slots, the label defined in RFC7139 is
   able to accommodate the requirement of the setup of ODUk/ODUflex over
   ODUCn link.  In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is
   used to indicate how the LO ODUj signal is multiplexed into the 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 and therefore the two nodes terminating the TE-link know
   (by internal/local configuration) the attributes of the ODUCn TE
   Link.

   One thing should be note is the TPN used in RFC7139 and defined in
   G.709-2016 for ODUCn link.  Since the TPN currently defined in G.709
   for ODUCn link has 14 bits, while this field in RFC7139 only has 12
   bits, some extension work is needed, but this is not so urgent since
   for today networks scenarios 12 bits are enough, as it can support a
   single ODUCn link up to n=400, namely 40Tbit. 40 Tbit/s.

   An example is given below to illustrate the label format defined in
   RFC7139 for multiplexing ODU4 onto ODUC10.  One ODUC10 has 200 5G
   slots, and twenty of them are allocated to the ODU4.  Along with the
   increase of "n", the label may become lengthy, an optimized label
   format may be needed.

   ==================================================================

      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 7: 5: Label format

4.2.3.

4.3.  Implications and Applicability for GMPLS Routing

   For routing, it is deemed that no extension to current mechanisms
   defined in RFC7138 are needed.  Because, once an ODUCn link is up,
   the resources that need to be advertised are the resources that
   exposed by this ODUCn link and the multiplexing hierarchy on this
   link.  Since the ODUCn link is the ultimate hierarchy of the ODU
   multiplexing, 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.  Acknowledgements

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

      Iftekhar Hussain

      Infinera Corp

      Sunnyvale, CA, USA

      Email: IHussain@infinera.com

      Daniele Ceccarelli

      Ericsson

      Email: daniele.ceccarelli@ericsson.com

7.  Contributors

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

      Fatai Zhang, Huawei,zhangfatai@huawei.com

      Italo Busi, Huawei,italo.busi@huawei.com

      Zheyu Fan, Individual, zheyu2008@gmail.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

      Akshaya Nadahalli, Individual, nadahalli@gmail.com

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   None.

10.  References

10.1.  Normative References

   [ITU-T_G709.1]
              ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
              2016",  , 2016.

   [ITU-T_G709_2012]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              02/2012",  http://www.itu.int/rec/T-REC-
              G..709-201202-S/en, February 2012.

   [ITU-T_G709_2016]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              07/2016",  http://www.itu.int/rec/T-REC-
              G..709-201606-P/en, July 2016.

   [ITU-T_G807]
              ITU-T, "ITU-T G.807: Generic functional architecture of
              the optical media network;
              2020",  http://www.itu.int/rec/T-REC-G.872/en, February
              2020.

   [ITU-T_G872]
              ITU-T, "ITU-T G.872: The Architecture of Optical Transport
              Networks; 2017",  http://www.itu.int/rec/T-REC-G.872/en,
              January 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [ITU-T_G709.1]
              ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
              2016",  , 2016.

Authors' Addresses

   Qilei Wang (editor)
   ZTE Corporation
   Nanjing
   CN
   China

   Email: wang.qilei@zte.com.cn
   Radha Valiveti (editor)
   Infinera Corp
   Sunnyvale
   USA

   Email: rvaliveti@infinera.com

   Haomian Zheng (editor)
   Huawei
   CN
   China

   Email: zhenghaomian@huawei.com

   Huub van Helvoort
   Hai Gaoming B.V
   Almere
   Netherlands

   Email: huubatwork@gmail.com

   Sergio Belotti
   Nokia

   Email: sergio.belotti@nokia.com