Internet Engineering Task Force Q. Wang, Ed. Internet-Draft ZTE Corporation Intended status: Informational R. Valiveti, Ed. Expires: December 16, 2021 Infinera Corp H. Zheng, Ed. Huawei H. Helvoort Hai Gaoming B.V S. Belotti Nokia June 14, 2021 Applicability of GMPLS for B100G Optical Transport Network draft-ietf-ccamp-gmpls-otn-b100g-applicability-07 Abstract This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up ODUk (e.g., ODUflex) LSP over 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 December 16, 2021. Copyright Notice Copyright (c) 2021 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 Wang, et al. Expires December 16, 2021 [Page 1] Internet-Draft B100G Extensions June 2021 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 2. OTN terminology used in this document . . . . . . . . . . . . 3 3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 3 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Time Slot Granularity . . . . . . . . . . . . . . . . . . 7 3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 7 3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 8 4. GMPLS Implications and Applicability . . . . . . . . . . . . 9 4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 9 4.2. Implications and Applicability for GMPLS Signalling . . . 10 4.3. Implications and Applicability for GMPLS Routing . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The current GMPLS routing [RFC7138] and signalling [RFC7139] extensions support the control of OTN signals and capabilities that were defined in the 2012 version of G.709 [ITU-T_G709_2012]. In 2016 a new version of G.709 was published: [ITU-T_G709_2016]. This version introduces new higher rate OTU and 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) LSP over ODUCn links, independently from how these links have been set up. Since the [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn comparing to [ITU-T_G709_2016], this document starts Wang, et al. Expires December 16, 2021 [Page 2] Internet-Draft B100G Extensions June 2021 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 setup ODUk (e.g., ODUflex) LSPs over ODUCn links. 2. OTN terminology used in this document a. OPUCn: Optical Payload Unit - Cn. Where Cn indicates that the bit rate is approximately n*100G. 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 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. f. 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). Detailed description 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]. 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: Wang, et al. Expires December 16, 2021 [Page 3] Internet-Draft B100G Extensions June 2021 a. 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) b. The OTUCn signals can be viewed as being formed by interleaving n OTUC signals (which are labeled 1, 2, ..., n), each of which has the format of a standard OTUk signal without the FEC columns (per [ITU-T_G709_2020] 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 [ITU-T_G709_2020]. c. Each of the OTUC "slices" 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. d. The OTUC signal has a slightly higher rate compared to the OTU4 signal (without FEC); this is to ensure that the OPUC payload area can carry an ODU4 signal. As explained above, within [ITU-T_G709_2020], the OTUCn, ODUCn and OPUCn signal structures are presented in a (physical) interface independent manner, by means of n OTUC, ODUC and OPUC instances that are marked #1 to #n. Specifically, the definition of the OTUCn signal does not cover aspects such as FEC, modulation formats, etc. These details are defined as part of the adaptation of the OTUCn layer to the optical layer(s). The specific interleaving of OTUC/ODUC/OPUC signals onto the optical signals is interface specific and specified for OTN interfaces with standardized application codes in the interface specific recommendations (G.709.x). OTUCn interfaces can be categorized as follows, based on the type of peer network element (see Figure 1): a. inter-domain interfaces: These types of interfaces are used for connecting OTN edge nodes to (a) client equipment (e.g. routers) or (b) hand-off points from other OTN networks. ITU-T has standardized the Flexible OTN (FlexO) interfaces to support these functions. For example, Recommendation [ITU-T_G709.1] specifies a flexible interoperable short-reach OTN interface over which an OTUCn (n >=1) is transferred, using bonded FlexO interfaces which belong to a FlexO group. b. intra-domain interfaces: In these cases, the OTUCn is transported using a proprietary (vendor specific) encapsulation, FEC etc. It may also be possible to transport OTUCn for intra-domain links using FlexO. Wang, et al. Expires December 16, 2021 [Page 4] Internet-Draft B100G Extensions June 2021 ================================================================== +--------------------------------------------------------+ | 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.1.1. OTUCn-M The standard OTUCn signal has the same rate as that of the ODUCn signal as shown 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 path. In other words, it is possible to extend the reach of an optical path (i.e. increase the physical distance covered) by lowering the bitrate of the digital signal that is modulated onto the optical signals. If the total rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100G, it is possible to "crunch" the OTUCn not to transmit some of unused timeslots. With this in mind, ITU-T supports the notion of a reduced rate OTUCn signal, termed the OTUCn-M. The OTUCn-M signal is derived from the OTUCn signal by retaining all the n instances of overhead (one per OTUC slice) but with only M (M is less than 20*n) OPUCn tributary slots available to carry ODUk LSPs. As the "crunching" algorithm is not standardized, knowing the value of M is not enough to decide the timeslot availability. 3.2. ODUCn The ODUCn signal 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 December 16, 2021 [Page 5] Internet-Draft B100G Extensions June 2021 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-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 2). In this case, the ODUCn is carried by 3 OTUCn segments. Specifically, the OPUCn signal flows through these regenerators unchanged. That is, the set of client signals, their TPNs, trib-slot allocation remains unchanged. The ODUCn Overhead might be modified if TCM sub-layers are instantiated in order to monitor the performance of the regenerator hops. In this sense, the ODUCn should NOT be seen as a general ODU which can be switched via an ODUk cross- connect. Wang, et al. Expires December 16, 2021 [Page 6] Internet-Draft B100G Extensions June 2021 ================================================================== +--------+ +--------+ | +-----------+ | | OTN |-----------| OTN | | DXC +-----------+ DXC + | | | | +--------+ +--------+ <--------ODUCn-------> <-------OTUCn------> +--------+ +--------+ +--------+ +--------+ | +--------+ | | +----------+ | | OTN |--------| OTN | | OTN |----------| OTN | | DXC +--------+ WXC +--------+ WXC +----------+ DXC | | | | 3R | | 3R | | | +--------+ +--------+ +--------+ +--------+ <-------------------------ODUCn--------------------------> <---------------> <---------------> <------------------> OTUCn OTUCn OTUCn ================================================================== Figure 2: ODUCn signal 3.3. Time Slot Granularity [ITU-T_G709_2012] has introduced the support for 1.25G granular tributary slots in OPU2, OPU3, and OPU4 signals. With the introduction of higher rate signals, it is not practical for the optical networks (and the data plane hardware) to support a very large number of connections at such a fine granularity. [ITU- T_G709_2012] has defined the OPUC with a 5G tributary slot granularity. This means that the ODUCn signal has 20*n tributary slots (of 5 Gbit/s capacity). It is worthwhile considering that the range of tributary port number (TPN) is 10*n instead of 20*n, which restricts the maximum client signals that could be carried over one single ODUC1. 3.4. Structure of OPUCn MSI with Payload type 0x22 As mentioned above, the OPUCn signal has 20*n 5G tributary slots. 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): Wang, et al. Expires December 16, 2021 [Page 7] Internet-Draft B100G Extensions June 2021 a. The TS availability bit indicates if the tributary slot is available or unavailable b. The TS occupation bit indicates if the tributary slot is allocated or unallocated c. The tributary port 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: a. All client signals are mapped into an ODUk (e.g., ODUflex) as specified in clause 17 of [ITU-T_G709_2020]. b. 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. c. 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 December 16, 2021 [Page 8] Internet-Draft B100G Extensions June 2021 ================================================================== 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. 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 below. Wang, et al. Expires December 16, 2021 [Page 9] Internet-Draft B100G Extensions June 2021 ================================================================== +-----+ +-----+ | | | | | 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 4: ODUCn TE-Links Two endpoints of a TE-Link are configured with the supported resource information, which may include whether the TE-Link is supported by an ODUCn or an ODUk or an OTUk, as well as the link attribute information (e.g., slot granularity, 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 LSP with no/few changes. As the resource on the ODUCn link which can be seen by the client ODUk/ODUflex is a set of 5G slots, the label defined in RFC7139 is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is used to indicate how the LO ODUj signal is multiplexed into the HO ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object is used to indicate how the ODUk signal is multiplexed into the ODUCn link. The ODUk Signal Type is indicated by Traffic Parameters. The IF_ID RSVP_HOP object provides a pointer to the interface associated with TE-Link and therefore the two nodes terminating the TE-link know (by internal/local configuration) the attributes of the ODUCn TE Link. Wang, et al. Expires December 16, 2021 [Page 10] Internet-Draft B100G Extensions June 2021 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. 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 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 5: 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 Wang, et al. Expires December 16, 2021 [Page 11] Internet-Draft B100G Extensions June 2021 value to represent the ODUCn signal type in the OSPF-TE routing protocol. The OSPF-TE extension defined in section 4 of RFC7138 can be reused to advertise the resource information on the ODUCn link to help finish the setup of ODUk/ODUflex. 5. Acknowledgements 6. Authors (Full List) Qilei Wang (editor) ZTE Nanjing, China Email: wang.qilei@zte.com.cn Radha Valiveti (editor) Infinera Corp Sunnyvale, CA, USA Email: rvaliveti@infinera.com Haomian Zheng (editor) Huawei CN EMail: zhenghaomian@huawei.com Huub van Helvoort Hai Gaoming B.V Wang, et al. Expires December 16, 2021 [Page 12] Internet-Draft B100G Extensions June 2021 EMail: huubatwork@gmail.com Sergio Belotti Nokia EMail: sergio.belotti@nokia.com Iftekhar Hussain Infinera Corp Sunnyvale, CA, USA Email: IHussain@infinera.com Daniele Ceccarelli Ericsson Email: daniele.ceccarelli@ericsson.com 7. Contributors Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com Fatai Zhang, Huawei,zhangfatai@huawei.com Italo Busi, Huawei,italo.busi@huawei.com 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 Wang, et al. Expires December 16, 2021 [Page 13] Internet-Draft B100G Extensions June 2021 Yuji Tochio, Fujitsu, tochio@fujitsu.com 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations None. 10. References 10.1. Normative References [ITU-T_G709_2020] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 06/2020", https://www.itu.int/rec/T-REC- G.709-202006-I/en, June 2020. [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, . 10.2. Informative References [ITU-T_G709.1] ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 2018", , 2018. [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. Wang, et al. Expires December 16, 2021 [Page 14] Internet-Draft B100G Extensions June 2021 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 December 16, 2021 [Page 15]