Applicability of GMPLS for Beyond 100G Optical Transport Network
draft-ietf-ccamp-gmpls-otn-b100g-applicability-09

Internet Engineering Task Force                             Q. Wang, Ed.
Internet-Draft                                           ZTE Corporation
Intended status: Informational                          R. Valiveti, Ed.
Expires: 9 November 2022                                   Infinera Corp
                                                           H. Zheng, Ed.
                                                                  Huawei
                                                             H. Helvoort
                                                         Hai Gaoming B.V
                                                              S. Belotti
                                                                   Nokia
                                                              8 May 2022

    Applicability of GMPLS for Beyond 100G Optical Transport Network
           draft-ietf-ccamp-gmpls-otn-b100g-applicability-09

Abstract

   This document examines the applicability of using existing GMPLS
   routing and signalling 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 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 9 November 2022.

Copyright Notice

   Copyright (c) 2022 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.

Wang, et al.             Expires 9 November 2022                [Page 1]
Internet-Draft              B100G Extensions                    May 2022

   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 in this document . . . . . . . . . . . .   3
   3.  Overview of the OTUCn/ODUCn in G.709  . . . . . . . . . . . .   4
     3.1.  OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  OTUCn-M . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Tributary Slot Granularity  . . . . . . . . . . . . . . .   6
     3.4.  Structure of OPUCn MSI with Payload type 0x22 . . . . . .   7
     3.5.  Client Signal Mappings  . . . . . . . . . . . . . . . . .   7
   4.  GMPLS Implications and Applicability  . . . . . . . . . . . .   8
     4.1.  TE-Link Representation  . . . . . . . . . . . . . . . . .   8
     4.2.  Implications and Applicability for GMPLS Signalling . . .   9
     4.3.  Implications and Applicability for GMPLS Routing  . . . .  10
   5.  Authors (Full List) . . . . . . . . . . . . . . . . . . . . .  10
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The current GMPLS routing [RFC7138] and signalling [RFC7139]
   extensions support the control of Optical Transport Network (OTN)
   signals and capabilities that were defined in the 2012 version of
   G.709 [ITU-T_G709_2012].

   In 2016 a further version of 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 x 100 Gbit/s.  According to the
   definition in [ITU-T_G709_2016], OTUCn and ODUCn perform only 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.

Wang, et al.             Expires 9 November 2022                [Page 2]
Internet-Draft              B100G Extensions                    May 2022

   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 an overview of the OTUCn
   and ODUCn signals, and then analysing how the current GMPLS routing
   and signalling mechanisms can be utilized to set up ODUk (e.g.,
   ODUflex) LSPs over ODUCn links.

2.  OTN terminology used in this document

   *  LSP: Label Switched Path.

   *  ODU: Optical Data Unit.

   *  ODUCn: Optical Data Unit-Cn.

   *  ODUflex: Optical Data Unit - flexible.

   *  ODUk: Optical Data Unit-k

   *  OPUCn: Optical Payload Unit-Cn.  Where Cn indicates that the bit
      rate is approximately n*100G.

   *  OTUCn: Fully standardized Optical Transport Unit-Cn.

   *  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 5
      Gbit/s tributary slots (where M is strictly less than 20*n).

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

   *  FlexO: Flexible OTN information structure.  This information
      structure is usually with a specific bit rate and frame format,
      consisting of overhead and payload, which is used as a group for
      the transport of an OTUCn signal.

Wang, et al.             Expires 9 November 2022                [Page 3]
Internet-Draft              B100G Extensions                    May 2022

   *  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 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 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*100G.  The following are the key characteristics of
   the OTUCn signal:

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

   *  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_2020] Figure 7-1).  The OTUC signal contains the ODUC
      signals.

   *  Each of the OTUC instance have the same overhead as the standard
      OTUk signal in [ITU-T_G709_2020].  The combined signal OTUCn has n
      instances of OTUC overhead, ODUC overhead.

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

Wang, et al.             Expires 9 November 2022                [Page 4]
Internet-Draft              B100G Extensions                    May 2022

   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 networks.  ITU-T
      Recommendation [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 that of the ODUCn
   signal.  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.
   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 tributary slots.  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 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 same Overhead area, and the payload
   area, but has a higher rate since its payload area can embed an ODU4
   signal.

Wang, et al.             Expires 9 November 2022                [Page 5]
Internet-Draft              B100G Extensions                    May 2022

   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_2020]
   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 1).
   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.

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

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

                           Figure 1: ODUCn signal

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.

Wang, et al.             Expires 9 November 2022                [Page 6]
Internet-Draft              B100G Extensions                    May 2022

3.4.  Structure of OPUCn MSI with Payload type 0x22

   As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary
   slots (TSs).  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):

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

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 ODUk (e.g., ODUflex) as
      specified in clause 17 of [ITU-T_G709_2020].

   *  ODU Virtual Concatenation 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-100G clients using ODU
      VCAT shall continue to be supported.

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

Wang, et al.             Expires 9 November 2022                [Page 7]
Internet-Draft              B100G Extensions                    May 2022

                     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 2: Digital Structure of OTN interfaces (from G.709:Figure 6-1)

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.  Similar to that, ODUCn links can also be
   represented as TE-Links, which can be seen in the Figure 3.

  +-----+              +-----+
  |     |              |     |
  |  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 3: ODUCn TE-Links

Wang, et al.             Expires 9 November 2022                [Page 8]
Internet-Draft              B100G Extensions                    May 2022

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

4.2.  Implications and Applicability for GMPLS Signalling

   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 which can be seen by the client
   ODUk/ODUflex is a set of 5 Gbit/s 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 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 and therefore the two nodes terminating the TE-link know (by
   internal/local configuration) the attributes of the ODUCn TE Link.

   Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14
   bits, while this field in [RFC7139] only has 12 bits, some extension
   work is needed.  Given that a 12-bit TPN field can support ODUCn
   links with up to n=400 (i.e. 40Tbit/s links), this extension is not
   urgently needed.

   An example is given in Figure 4 to illustrate the label format
   defined in [RFC7139] for multiplexing ODU4 onto ODUC10.  One ODUC10
   has 200 5 Gbit/s 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.

Wang, et al.             Expires 9 November 2022                [Page 9]
Internet-Draft              B100G Extensions                    May 2022

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

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 lowest layer of the ODU
   multiplexing hierarchy, 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)

Wang, et al.             Expires 9 November 2022               [Page 10]
Internet-Draft              B100G Extensions                    May 2022

      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

Wang, et al.             Expires 9 November 2022               [Page 11]
Internet-Draft              B100G Extensions                    May 2022

      Antonello Bonfanti, Cisco Systems, abonfant@cisco.com

      Yuji Tochio, Fujitsu, tochio@fujitsu.com

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   This document analyses and reuses the protocol extensions in
   [RFC7138] and [RFC7139] without introducing any new extensions.
   Therefore, this document introduces no new security considerations to
   the existing signalling protocol and routing protocol comparing to
   [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.  References

9.1.  Normative References

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

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

Wang, et al.             Expires 9 November 2022               [Page 12]
Internet-Draft              B100G Extensions                    May 2022

   [ITU-T_G709_2012]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              02/2012", February 2012.

   [ITU-T_G709_2016]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              07/2016", July 2016.

Authors' Addresses

   Qilei Wang (editor)
   ZTE Corporation
   Nanjing
   China
   Email: wang.qilei@zte.com.cn

   Radha Valiveti (editor)
   Infinera Corp
   Sunnyvale
   USA
   Email: rvaliveti@infinera.com

   Haomian Zheng (editor)
   Huawei
   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

Wang, et al.             Expires 9 November 2022               [Page 13]