Internet Engineering Task Force Q. Wang, Ed. Internet-Draft ZTE Intended status: Informational R. Valiveti, Ed. Expires: August 31, 2019 Infinera Corp H. Zheng, Ed. Huawei H. Helvoort Hai Gaoming B.V S. Belotti Nokia February 27, 2019 Applicability of GMPLS for B100G Optical Transport Network draft-ietf-ccamp-gmpls-otn-b100g-applicability-00 Abstract This document examines the applicability of using current existing GMPLS routing and signaling to set up ODUk/ODUflex over ODUCn link, as a result of the support of OTU/ODU links with rates larger than 100G 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 August 31, 2019. Copyright Notice Copyright (c) 2019 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 Wang, et al. Expires August 31, 2019 [Page 1] Internet-Draft B100G Extensions February 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. OTN terminology used in this document . . . . . . . . . . 3 3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Carrying OTUCn between 3R points . . . . . . . . . . 5 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Time Slot Granularity . . . . . . . . . . . . . . . . . . 8 3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8 3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 8 4. Applicability and GMPLS Implications . . . . . . . . . . . . 10 4.1. Applicability and Challenges . . . . . . . . . . . . . . 10 4.2. GMPLS Implications and Applicability . . . . . . . . . . 12 4.2.1. Implications and Applicability for GMPLS Signalling . 12 4.2.2. Implications and Applicability for GMPLS Routing . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The current GMPLS routing [RFC7138] and signaling extensions [RFC7139] only includes coverage for the control of all the OTN capabilities that were defined in the 2012 version of G.709 [ITU-T_G709_2012]. While the 2016 version of G.709 [ITU-T_G709_2016] introduces support for new higher rate ODU signals, termed ODUCn (which have a nominal rate of n x 100 Gbps), how to use GMPLS to configure ODUCn should be taken into consideration. But it seems how to configure the ODUCn Wang, et al. Expires August 31, 2019 [Page 2] Internet-Draft B100G Extensions February 2019 link needs more discussion, so this draft mainly focuses on the use of current GMPLS mechanisms to set up ODUk/ODUflex over an existing ODUCn link. This document presents an overview of the changes introduced in [ITU-T_G709_2016] to motivate the present topic and then analyzes how the current GMPLS routing and signalling mechanisms can be utilized to setup ODUk/ODUflex connections over ODUCn links. 1.1. Scope For the purposes of the B100G control plane discussion, the OTN should be considered as a combination of ODU and OTSi layers. Note that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for B100G entities, and leaving it intact only for maintaining continuity in the description of the signals with bandwidth upto 100G. This document focuses on only 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 will be included in this draft. 2. Terminology 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. OTN terminology used in this document a. OPUCn: Optical Payload Unit -Cn. 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 the payload area consists of M 5G tributary slots (where M is strictly less than 20*n). e. PSI: OPU Payload structure Indicator. This is a multi-frame message and describes the composition of the OPU signal. This field is a concatenation of the Payload type (PT) and the Multiplex Structrure Indicator (MSI) defined below. Wang, et al. Expires August 31, 2019 [Page 3] Internet-Draft B100G Extensions February 2019 f. MSI: Multiplex Structure Indicator. This structure indicates the grouping of the tributary slots in an OPU payload area to realize a client signal that 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: see [ITU-T_G872] i. OTSiA: see [ITU-T_G872] Detailed description of these terms can be found in [ITU-T_G709_2016]. 3. Overview of B100G in G.709 This section provides an overview of new features in [ITU-T_G709_2016]. 3.1. OTUCn In order to carry client signals with rates greater than 100Gbps, [ITU-T_G709_2016] takes a general and scalable approach that decouples the rates of OTU signals from the client rate evolution. The new OTU signal is called OTUCn; 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 (where 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 (OH) as the standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined signal OTUCn has n instances of OTUC OH, ODUC OH. Wang, et al. Expires August 31, 2019 [Page 4] Internet-Draft B100G Extensions February 2019 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. 3.1.1. Carrying OTUCn between 3R points 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). The following scenarios of OTUCn transport need to be considered (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. 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. In its current form, Recommendation [ITU-T_G709.1] is limited to the case of transporting OTUCn signals using n 100G Ethernet PHY(s). When the PHY(s) for the emerging set of Ethernet signals, e.g. 200GbE and 400GbE, become available, new recommendations can define the required adaptations. b. intra-domain interfaces: In these cases, the OTUCn is transported using a proprietary (vendor specific) encapsulation, FEC etc. In future, it may be possible to transport OTUCn for intra-domain links using future variants of FlexO. Wang, et al. Expires August 31, 2019 [Page 5] Internet-Draft B100G Extensions February 2019 ================================================================== +--------------------------------------------------------+ | 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 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 (OH) 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 = n x 105,258,138.053 | | | 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-terminous, i.e. they will have identical source/sink locations. [ITU-T_G709_2016] and [ITU-T_G872] allow 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. Wang, et al. Expires August 31, 2019 [Page 6] Internet-Draft B100G Extensions February 2019 Specifically, the OPUCn signal flows through these regenerators unchanged. That is, the set of client signals, their TPNs, trib-slot allocation remains unchanged. Note however that the ODUCn Overhead (OH) might be modified if TCM sub-layers are instantiated in order to monitor the performance of the repeater 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 | | 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 carrier(s). By the very nature of the OTUCn signal, it is constrained to rates which are multiples of (approximately) 100G. If it so 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. Wang, et al. Expires August 31, 2019 [Page 7] Internet-Draft B100G Extensions February 2019 3.4. Time Slot Granularity [ITU-T_G709_2012] introduced the support for 1.25G granular tributary slots in OPU2, OPU3, and OPU4 signals. With the introduction of higher rate signals, it is no longer practical for the optical networks (and the datapath hardware) to support a very large number of flows at such a fine granularity. ITU-T has defined the OPUC with a tributary slot granularity of 5G. This means that the ODUCn signal has 20*n tributary slots (of 5Gbps capacity). It is worthwhile considering that the range of tributary port number (TPN) is 10*n, and not 20*n which would allow for a different client signal to be carried in each TS. As an example, it will not be possible to embed 15 5G ODUflex signals in a ODUC1. 3.5. 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), followed by the MSI. The OPUCn MSI field has a fixed length of 40*n bytes and indicates the availability 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 1 indicates if the tributary slot is available or unavailable b. The TS occupation bit 9 indicates if the tributary slot is allocated or unallocated c. b.c. The tributary port # in bits 2 to 8 and 10 to 16 indicates the port number of the client that is being carried in this specific TS; a flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports are is from 1 to 10n. 3.6. 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 as specified in [ITU-T_G709_2016]:Clause 17. These mappings are identical to those specified in the earlier revision of G.709 [ITU-T_G709_2012]. Thus, 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]) Wang, et al. Expires August 31, 2019 [Page 8] Internet-Draft B100G Extensions February 2019 b. Always map the new and emerging client signals to ODUflex signals of the appropriate rates (see Table 2 -- based on Table 7-2 in [ITU-T_G709_2016]) c. Drop support for ODU Virtual Concatenation. 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 using either an ODUk (k=1..4) or an ODUCn server layer. On the other hand, ODUflex connections with rates greater than 100G will require the server layer to be ODUCn. The ODUCn signals must be adapted to an OTUCn signal. Figure 3 illstrates the hierarchy of the digital signals defined in [ITU-T_G709_2016]. +----------------+--------------------------------------------------+ | 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 Wang, et al. Expires August 31, 2019 [Page 9] Internet-Draft B100G Extensions February 2019 ================================================================== 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 Two typical scenarios are depicted in Appendix XIII of [ITU-T_G709_2016], which are also introduced into this document to help analyze the potential extension to GMPLS needed. Though these two scenarios are mainly introduced in G.709 to describe OTUCn sub rates application, they can also be used to describe general OTUCn application. One thing that should be note is these two scenarios are a little different from those described in [ITU-T_G709_2016], as the figure in this section include the OTSi(G) in to facilitate the description of the challenge brought by [ITU-T_G709_2016]. The first scenarios is depicted in Figure 4. This scenario deploys OTUCn/OTUCn-M between two line ports connecting two L1/L0 ODU cross connects (XC) within one optical transport network. One OTUCn is actually carried by one OTSi(G) or OTSiA. As defined in [ITU-T_G872], OTSiG is used to represent one or more OTSi as a group to carry a single client signal (e.g., OTUCn). The Wang, et al. Expires August 31, 2019 [Page 10] Internet-Draft B100G Extensions February 2019 OTSiG may have non-associated overhead, the combination of the OTSiG and OTSiG-O is represented by the OTSiA management/control abstraction. In this scenario, it is clear that the OTUCn and ODUCn link can be automatically established, after/together with the setup of OTSi(G) or OTSiA, as both OTUCn and ODUCn perform section layer only. One client OTUCn signal is carried by one single huge OTSi signal or a group of OTSi. There is a 1:1 mapping relationship between OTUCn and OTSi(G) or OTSiA. For example, one 400G OTUCn signal can be carried by one single 400G OTSi signal or one 400G OTUCn signal can be split into 4 different OTUC instances, with each instances carried by one OTSi. Those four OTSi function as a group to carry a single 400G OTUCn signal. ================================================================== +--------+ +--------+ | +---------------------+ | | OTN |---------------------| OTN | | XC +---------------------+ XC | | | | | +--------+ +--------+ <---------- ODUk/ODUflex -----------> <------------ ODUCn --------------> <------- OTUCn/OTUCn-M ---------> <--------OTSi(G)/OTSiA---------> ================================================================== Figure 4: Scenario A The second scenarios is depicted in Figure 4. This scenario deploys OTUCn/OTUCn-M between transponders which are in a different domain B, which are separated from the L1 ODU XCs in domain A and/or C. one end-to-end ODUCn is actually supported by three different OTUCn or OTUCn-M segments, which are in turn carried by OTSi(G) or OTSiA. In the second scenario, OTUCn links will be established automatically after/together with the setup of OTSi(G) or OTSiA, while there are still some doubts about how the ODUCn link is established. In principle, it could/should be possible but it is not yet clear in details how the ODUCn link can be automatically setup. Wang, et al. Expires August 31, 2019 [Page 11] Internet-Draft B100G Extensions February 2019 ================================================================== +--------------------------------------+ A | B | A or C | | | | +--------+ | +--------+ +--------+ | +--------+ | +----------|-+ | | +-|--------+ | | OTN |----------|-| Transp | | Transp |-|--------| OTN | | XC +----------|-+ onder +----------------+ onder +-|--------+ XC | | | | | | | | | | | +--------+ | +--------+ +--------+ | +--------+ | | +--------------------------------------+ <-----------------------------ODUk/ODUflex----------------------------> <----------------------------- ODUCn -------------------------------> <-------OTUCn-------><-----OTUCn/OTUCn-M-----><-------OTUCn-------> <--OTSi(G)/OTSiA--> <----OTSi(G)/OTSiA----> <--OTSi(G)/OTSiA--> ================================================================== Figure 5: Scenario B According to the above description, it can be concluded that some uncertainty about setup of ODUCn link still exist, and this uncertainty may have relationship with the progress in ITU-T. Based on the analysis, it is suggested that the scope of this draft should mainly focus on how to set up ODUk/ODUflex LSPs over ODUCn links, as also indicated in the figure above. 4.2. GMPLS Implications and Applicability 4.2.1. Implications and Applicability for GMPLS Signalling Once the ODUCn 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 serial of 5G slots, the label defined in RFC7139 is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn 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 Wang, et al. Expires August 31, 2019 [Page 12] Internet-Draft B100G Extensions February 2019 for today networks scenarios 12 bits are enough, as it can support a single ODUCn link up to n=400, namely 40Tbit. 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 6: Label format 4.2.2. Implications and Applicability for GMPLS Routing For routing, we think that no extension to current mechanisms defined in RFC7138 are needed. Because, once one ODUCn link is up, we need to advertise only the resources that can be used on this ODUCn link and the multiplexing hierarchy on this link. Considering ODUCn link is already configured, it's the ultimate hierarchy of this multiplexing, there is no need to explicitly extent the ODUCn signal type in the routing. Wang, et al. Expires August 31, 2019 [Page 13] Internet-Draft B100G Extensions February 2019 The OSPF-TE extension defined in section 4 of RFC7138 can be used to advertise the resource information on the ODUCn link to direct 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 Wang, et al. Expires August 31, 2019 [Page 14] Internet-Draft B100G Extensions February 2019 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, Huawei, fanzheyu2@huawei.com Dieter Beller, Nokia, Dieter.Beller@nokia.com Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn Zafar Ali, Cisco Systems, zali@cisco.com Daniel King, d.king@lancaster.ac.uk Manoj Kumar, Cisco Systems, manojk2@cisco.com Antonello Bonfanti, Cisco Systems, abonfant@cisco.com Akshaya Nadahalli, Cisco Systems, anadahal@cisco.com Wang, et al. Expires August 31, 2019 [Page 15] Internet-Draft B100G Extensions February 2019 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_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, . [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006, . [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, . Wang, et al. Expires August 31, 2019 [Page 16] Internet-Draft B100G Extensions February 2019 [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, . 10.2. Informative References [I-D.izh-ccamp-flexe-fwk] Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. Zhong, "GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in progress), October 2016. Authors' Addresses Qilei Wang (editor) ZTE Nanjing CN Email: wang.qilei@zte.com.cn Radha Valiveti (editor) Infinera Corp Sunnyvale 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 Wang, et al. Expires August 31, 2019 [Page 17] Internet-Draft B100G Extensions February 2019 Sergio Belotti Nokia Email: sergio.belotti@nokia.com Wang, et al. Expires August 31, 2019 [Page 18]