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