From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9376.txt | 730 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 730 insertions(+) create mode 100644 doc/rfc/rfc9376.txt (limited to 'doc/rfc/rfc9376.txt') 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, + . + + [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, + . + + [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, + . + +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, + . + + [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, . + +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 -- cgit v1.2.3