idnits 2.17.1 draft-merge-ccamp-otn-b100g-fwk-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4203' is mentioned on line 927, but not defined == Missing Reference: 'G709-2016' is mentioned on line 932, but not defined == Outdated reference: A later version (-07) exists of draft-izh-ccamp-flexe-fwk-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Wang, Ed. 3 Internet-Draft ZTE 4 Intended status: Informational R. Valiveti, Ed. 5 Expires: May 3, 2018 Infinera Corp 6 H. Zheng, Ed. 7 Huawei 8 H. Helvoort 9 Hai Gaoming B.V 10 S. Belotti 11 Nokia 12 October 30, 2017 14 GMPLS Routing and Signaling Framework for B100G 15 draft-merge-ccamp-otn-b100g-fwk-02 17 Abstract 19 The 2016 revision of G.709 introduces support for OTU links with 20 rates larger than 100G. This document provides a framework to 21 address the GMPLS routing and signalling extensions that enable GMPLS 22 to setup paths through network that contain these newly introduced 23 OTUCn links. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 3, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2.2. OTN terminology used in this document . . . . . . . . . . 3 64 3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4 65 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1.1. Carrying OTUCn between 3R points . . . . . . . . . . 5 67 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.4. OPUCn Time Slot Granularity . . . . . . . . . . . . . . . 9 70 3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 10 71 3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 10 72 4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. 100GE Client Service with a homogeneous chain of OTUC1 74 links . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.2. 100GE Client Service with a mix of ODU4, and ODUC1 76 connections . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.3. Transport of non-OTN Client Signal over ODUCn connection 14 78 4.3.1. 400GE Client Service with a mix of OTUCn links . . . 14 79 4.3.2. FlexE aware transport over OTUCn links . . . . . . . 15 80 4.3.3. FlexE Client transport over OTUCn links . . . . . . . 16 81 4.4. Multihop ODUCn link . . . . . . . . . . . . . . . . . . . 17 82 4.5. Use of OTUCn-M links . . . . . . . . . . . . . . . . . . 18 83 4.6. Intermediate State of ODU mux . . . . . . . . . . . . . . 19 84 5. GMPLS Implications . . . . . . . . . . . . . . . . . . . . . 19 85 5.1. OTN ODUCn/OTUCn hierarchy . . . . . . . . . . . . . . . . 19 86 5.2. OTUCn/OTUCn-M/ODUCn LSP . . . . . . . . . . . . . . . . . 20 87 5.3. Implications for GMPLS Signaling . . . . . . . . . . . . 20 88 5.4. Implications for GMPLS Routing . . . . . . . . . . . . . 21 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 7. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 22 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 96 11.2. Informative References . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 The current GMPLS routing [RFC7138] and signaling extensions 103 [RFC7139] includes coverage for all the OTN capabilities that were 104 defined in the 2012 version of G.709 [ITU-T_G709_2012]. 106 The 2016 version of G.709 [ITU-T_G709_2012] introduces support for 107 higher rate OTU signals, termed OTUCn (which have a nominal rate of n 108 x 100 Gbps). The newly introduced OTUCn represent a very powerful 109 extension to the OTN capabilities, and one which naturally scales to 110 transport any newer clients with bit rates in excess of 100G, as they 111 are introduced. 113 This document presents an overview of the changes introduced in 114 [ITU-T_G709_2016] and analyzes them to identify the extensions that 115 would be required in GMPLS routing and signaling to enable the new 116 OTN capabilities. 118 1.1. Scope 120 For the purposes of the B100G control plane discussion, the OTN 121 should be considered as a combination of ODU and OTSi layers. Note 122 that [ITU-T_G709_2016] is deprecating the use of the term "Och" for 123 B100G entities, and leaving it intact only for maintaining continuity 124 in the description of the signals with bandwidth upto 100G. This 125 document focuses on only the control of the ODU layer. The control 126 of the OTSi layer is out of scope of this document. 128 2. Terminology 130 2.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 2.2. OTN terminology used in this document 138 a. OPUCn: Optical Payload Unit -Cn. 140 b. ODUCn: Optical Data Unit - Cn. 142 c. OTUCn: Fully standardized Optical Transport Unit - Cn. 144 d. OTUCn-M: This signal is an extension of the OTUCn signal 145 introduced above. This signal contains the same amount of 146 overhead as the OTUCn signal, but contains a reduced amount of 147 payload area. Specifically the payload area consists of M 5G 148 tributary slots (where M is strictly less than 20*n). 150 e. PSI: OPU Payload structure Indicator. This is a multi-frame 151 message and describes the composition of the OPU signal. This 152 field is a concatenation of the Payload type (PT) and the 153 Multiplex Structrure Indicator (MSI) defined below. 155 f. MSI: Multiplex Structure Indicator. This structure indicates the 156 grouping of the tributary slots in an OPU payload area to realize 157 a client signal that is multiplexed into an OPU. The individual 158 clients multiplexed into the OPU payload area are distinguished 159 by the Tributary Port number (TPN). 161 g. GMP: Generic Mapping Procedure. 163 Detailed description of these terms can be found in 164 [ITU-T_G709_2016]. 166 3. Overview of B100G in G.709 168 This section provides an overview of new features in 169 [ITU-T_G709_2016]. 171 3.1. OTUCn 173 In G.709 [ITU-T_G709_2012], the standard mechanism for transporting a 174 client signal is to first map it into an ODU signal (of the 175 appropriate rate), and then switch the resulting ODU signal through 176 the OTN network. In the course of its traversal through the OTN 177 network, the ODU signal generated by the mapper is either (a) 178 multiplexed into higher-order ODU, and then encapsulated to form an 179 OTU or (b) directly encapsulated into an OTU signal that defines the 180 section layer. The option (b), i.e. direct encapsulation into an OTU 181 was possible only for ODU1/ODU2/ODU3/ODU4; ODU signals with other 182 rates (e.g. ODUflex) would first have to be processed per option (a) 183 above. The term "client signal" is generic in the sense that it 184 encompasses both Constant Bit rate (CBR) clients (e.g. 10GBASE-R, 185 SONET OC-768), or packet traffic -- where the goal is to transfer the 186 payload from end-to-end (without regard for bit transparency at the 187 PCS layer). Given that OTU4 was the highest rate section layer 188 signal supported in [ITU-T_G709_2012], the client signal rates were 189 limited to be less than 100G (if ODU-VCAT was not used). 191 In order to carry client signals with rates greater than 100Gbps, 192 [ITU-T_G709_2016] takes a general and scalable approach that 193 decouples the rates of OTU signals from the client rate evolution. 195 The new OTU signal is called OTUCn; this signal is defined to have a 196 rate of (approximately) n*100G. The following are the key 197 characteristics of the OTUCn signal: 199 a. The OTUCn signal contains one ODUCn, which in turn contains one 200 OPUCn signal. The OTUCn and ODUCn signals perform digital 201 section roles only (see [ITU-T_G709_2016]:Section 6.1.1). The 202 OTUCn and ODUCn can be seen as being analogous to the regenerator 203 section, and multiplex section in SDH respectively. 205 b. The OTUCn signals can be viewed as being formed by interleaving n 206 OTUC signals (where are labeled 1, 2, ..., n), each of which has 207 the format of a standard OTUk signal without the FEC columns (per 208 [ITU-T_G709_2016]:Figure 7-1). The ODUCn, and OPUCn have a 209 similar structure, i.e. they can be seen as being formed by 210 interleaving n instances of ODUC, OPUC signals (respectively) The 211 OTUC signal contains the ODUC, and OPUC signals, just as in the 212 case of fixed rate OTUs defined in G.709 [ITU-T_G709_2016]. 214 c. Each of the OTUC "slices" have the same overhead (OH) as the 215 standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined 216 signal OTUCn has n instances of OTUC OH, ODUC OH, and OPUC OH. 218 d. The OTUC signal has a slightly higher rate compared to the OTU4 219 signal (without FEC); this is to ensure that the OPUC payload 220 area can carry an ODU4 signal. 222 3.1.1. Carrying OTUCn between 3R points 224 As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn 225 and OPUCn signal structures are presented in a (physical) interface 226 independent manner, by means of n OTUC, ODUC and OPUC instances that 227 are marked #1 to #n. Specifically, the definition of the OTUCn 228 signal does not cover aspects such as FEC, modulation formats, etc. 229 These details are defined as part of the adaptation of the OTUCn 230 layer to the optical layer(s). The specific interleaving of 231 OTUC/ODUC/OPUC signals onto the optical signals is interface specific 232 and specified for OTN interfaces with standardized application codes 233 in the interface specific recommendations (G.709.x). 235 The following scenarios of OTUCn transport need to be considered (see 236 Figure 1): 238 a. inter-domain interfaces: These types of interfaces are used for 239 connecting OTN edge nodes to (a) client equipment (e.g. routers) 240 or (b) hand-off points from other OTN networks. ITU-T has 241 standardized the Flexible OTN (FlexO) interfaces to support these 242 functions. Recommendation [ITU-T_G709.1] specifies a flexible 243 interoperable short-reach OTN interface over which an OTUCn (n 244 >=1) is transferred, using bonded FlexO interfaces which belong 245 to a FlexO group. The FlexO group supports physical interface 246 bonding, management of the group members, overhead for 247 communication between FlexO peers etc. (these overheads are 248 separate from the GCC0 channel defined over OTUCn). In its 249 current form, Recommendation [ITU-T_G709.1] is limited to the 250 case of transporting OTUCn signals using n 100G Ethernet PHY(s). 251 The mechanisms for transporting the OTUCn signals over 100G 252 optical interfaces are specified in [ITU-T_G709.1] and are not 253 repeated here. When the PHY(s) for the emerging set of Ethernet 254 signals, e.g. 200GbE and 400GbE, become available, new 255 recommendations can define the required adaptations. 257 b. intra-domain interfaces: In these cases, the OTUCn is transported 258 using a proprietary (vendor specific) encapsulation, FEC etc. In 259 future, it may be possible to transport OTUCn for intra-domain 260 links using future variants of FlexO. 262 ================================================================== 264 +--------------------------------------------------------+ 265 | OTUCn signal | 266 +--------------------------------------------------------+ 267 | Inter+Domain | Intra+Domain | Intra+Domain | 268 | Interface (IrDI)| Interface (IaDI)| Interface | 269 | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | 270 | | (Future) | Encap, FEC etc. | 271 +--------------------------------------------------------+ 273 ================================================================== 275 Figure 1: OTUCn transport possibilities 277 It is possible for an OTUCn signal to be transported via multiple 278 hops of lower-layer adaptation (see Figure 2). In this scenario, the 279 OTUCn spans multiple optical paths joined by a FlexO segment. An 280 end-to-end OTUCn LSP needs to be setup after the optical circuits are 281 established. The information about the FlexO interfaces (and group) 282 are configured at the FlexO endpoints, and there is no dynamic setup. 284 ================================================================== 286 Optical Segment Optical Segment 287 <--------------> <--------------> 289 +------+ +------+ +------+ +------+ 290 | | | +-----------+ | | | 291 | A +---------+ B |-----------| C +--------+ D | 292 | | | +-----------+ | | | 293 +------+ +------+ ^ +------+ +------+ 294 | 295 + 296 FlexO Group 297 <--------------------------------------------------> OTUCn 299 +-------+ +-------+ +-------+ 300 | OTUCn | | OTUCn | | OTUCn | 301 +-------+ +-------+ +-------+ 302 | OTSiG | | FlexO | | OTSiG | 303 +-------+ +-------+ +-------+ 305 ================================================================== 307 Figure 2: OTUCn transport - Multihop 309 This document views FlexO (even if there are some digital sub-layers 310 involved in the adaptation) and other OTUCn transport mechanisms as 311 "lower layers", and are therefore considered out-of-scope. The OTUCn 312 layer operates independent of the method used to transport the 313 signal. 315 3.2. ODUCn 317 The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by 318 the appropriate interleaving of content from n ODUC signal instances. 319 The ODUC frames have the same structure as a standard ODU -- in the 320 sense that it has the same Overhead (OH) area, and the payload area 321 -- but has a higher rate since its payload area can embed an ODU4 322 signal. The ODUCn signal can be formed in one of the following ways: 324 By multiplexing lower-rate (i.e. both low-order and high-order) 325 ODUk signals. 327 Each of the n instances of ODUC can carry the NULL signal (as 328 specified in [ITU-T_G709_2016]: Section 17.5.1) 329 Each of the n instances of ODUC can carry the PN-11 PRBS test 330 sequence (as specified in [ITU-T_G709_2016]: Section 17.5.2) 332 It is concievable that vendors might implement proprietary 333 mappings (Payload Type values of 0x80-x8F)of non-OTN client 334 signals. An interoperable control plane cannot make use of these 335 proprietary ODUCn signals, and hence this case isn't considered in 336 this document. 338 The ODUCn signals have a rate that is captured in Table 1. 340 +----------+--------------------------------------------------------+ 341 | ODU Type | ODU Bit Rate | 342 +----------+--------------------------------------------------------+ 343 | ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 | 344 | | kbit/s | 345 +----------+--------------------------------------------------------+ 347 Table 1: ODUCn rates 349 The ODUCn is a multiplex section ODU signal, and is mapped into an 350 OTUCn signal which provides the regenerator section layer. In some 351 scenarios, the ODUCn, and OTUCn signals will be co-terminous, i.e. 352 they will have identical source/sink locations. [ITU-T_G709_2016] 353 and [ITU-T_G872] allow for the ODUCn signal to pass through a digital 354 regenerator node which will terminate the OTUCn layer, but will pass 355 the regenerated (but otherwise untouched) ODUCn towards a different 356 OTUCn interface where a fresh OTUCn layer will be initiated (see 357 Figure 3). In this case, an ODUCn LSP needs to be set up to traverse 358 the 3 OTUCn segments. 360 Specifically, the OPUCn signal flows through these regenerators 361 unchanged. That is, the set of client signals, their TPNs, trib-slot 362 allocation remains unchanged. Note however that the ODUCn Overhead 363 (OH) might be modified if TCM sub-layers are instantiated in order to 364 monitor the performance of the repeater hops. In this sense, the 365 ODUCn should not be seen as a general ODU which can be switched via 366 an ODUk cross-connect. 368 ================================================================== 370 ^ FlexO group ^ FlexO group 371 | | 372 +--------+ | +--------+ +--------+ | +--------+ 373 | +-----------+ | | +----------+ | 374 | OTN |-----------| OTN | | OTN |----------| OTN | 375 | DXC +-----------+ WXC +----------------+ WXC +----------+ DXC | 376 | | | 3R | | 3R | | | 377 +--------+ +--------+ +--------+ +--------+ 379 <------------------> <----------------------> <------------------> 380 OTUCn/FlexO OTUCn/OTSiG OTUCn/FlexO 382 <-----------------------------------------------------------------> ODUCn 384 ================================================================== 386 Figure 3: Multi-hop ODUCn signal 388 3.3. OTUCn-M 390 The standard OTUCn signal has the same rate as that of the ODUCn 391 signal as captured in Table 1. This implies that the OTUCn signal 392 can only be transported over wavelength groups which have a total 393 capacity of multiples of (approximately) 100G. Modern DSPs support a 394 variety of bit rates per wavelength, depending on the reach 395 requirements for the optical link. With this in mind, ITU-T supports 396 the notion of a reduced rate OTUCn signal, termed the OTUCn-M. The 397 OTUCn-M signal is derived from the OTUCn signal by retaining all the 398 n instances of overhead (one per OTUC slice) and crunching the OPUC 399 tributary slots marked as "unavailable". 401 3.4. OPUCn Time Slot Granularity 403 [ITU-T_G709_2012] introduced the support for 1.25G granular tributary 404 slots in OPU2, OPU3, and OPU4 signals. With the introduction of 405 higher rate signals such as the OPUCn, it is no longer practical for 406 the optical networks (and the datapath hardware) to support a very 407 large number of flows at such a fine granularity. ITU-T has defined 408 the OPUC with a tributary slot granularity of 5G. This means that 409 the ODUCn signal has 20*n tributary slots (of 5Gbps capacity). 411 3.5. Structure of OPUCn MSI with Payload type 0x22 413 As mentioned above, the OPUCn signal has 20*n 5G tributary slots. 414 The OPUCn contains n PSI structures, one per OPUC instance. The PSI 415 structure consists of the Payload Type (of 0x22), followed by a 416 Reserved Field (1 byte), followed by the MSI. The OPUCn MSI field 417 has a fixed length of 40*n bytes and indicates the ODTU content of 418 each TS of an OPUCn. Two bytes are used for each of the 20*n 419 tributary slots, and each such information structure has the 420 following format ([ITU-T_G709_2016] G.709:Section 20.4.1): 422 a. The TS availability bit 1 indicates if the tributary slot is 423 available or unavailable 425 b. The TS occupation bit 9 indicates if the tributary slot is 426 allocated or unallocated 428 3.6. Client Signal Mappings 430 Note that [ITU-T_G709_2016] introduces support for OTUCn signals with 431 rates of n*100G and also introduces support for client signals with 432 rates larger than 100G (e.g. the future 400GBASE-R client being 433 standardized by IEEE, higher packet streams from NPUs). The approach 434 taken by the ITU-T to map non-OTN client signals to the appropriate 435 ODU containers is as follows: 437 a. All client signals with rates less than 100G are mapped as 438 specified in [ITU-T_G709_2016]:Clause 17. These mappings are 439 identical to those specified in the earlier revision of G.709 440 [ITU-T_G709_2012]. Thus, for example, the 1000BASE-X/10GBASE-R 441 signals are mapped to ODU0/ODU2e respectively (see Table 2 -- 442 based on Table 7-2 in [ITU-T_G709_2016]) 444 b. Always map the new and emerging client signals to ODUflex signals 445 of the appropriate rates (see Table 2 -- based on Table 7-2 in 446 [ITU-T_G709_2016]) 448 c. Drop support for ODU Virtual Concatenation. This simplifies the 449 network, and the supporting hardware since multiple different 450 mappings for the same client are no longer necessary. Note that 451 legacy implementations that transported sub-100G clients using 452 ODU VCAT shall continue to be supported. 454 d. ODUflex signals are low-order signals only. If the ODUflex 455 entities have rates of 100G or less, they can be transported 456 using either an ODUk (k=1..4) or an ODUCn server layer. On the 457 other hand, ODUflex connections with rates greater than 100G will 458 require the server layer to be ODUCn. The ODUCn signals must be 459 adapted to an OTUCn signal. Figure 4 illstrates the hierarchy of 460 the digital signals defined in [ITU-T_G709_2016]. 462 +----------------+--------------------------------------------------+ 463 | ODU Type | ODU Bit Rate | 464 +----------------+--------------------------------------------------+ 465 | ODU0 | 1,244,160 Kbps | 466 | ODU1 | 239/238 x 2,488,320 Kbps | 467 | ODU2 | 239/237 x 9,953,280 Kbps | 468 | ODU2e | 239/237 x 10,312,500 Kbps | 469 | ODU3 | 239/236 x 39,813,120 Kbps | 470 | ODU4 | 239/227 x 99,532,800 Kbps | 471 | ODUflex for | 239/238 x Client signal Bit rate | 472 | CBR client | | 473 | signals | | 474 | ODUflex for | Configured bit rate | 475 | GFP-F mapped | | 476 | packet traffic | | 477 | ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= | 478 | IMP mapped | 1 | 479 | packet traffic | | 480 | ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is | 481 | FlexE aware | total number of available tributary slots among | 482 | transport | all PHYs which have been crunched and combined. | 483 +----------------+--------------------------------------------------+ 485 Note that this table doesn't include ODUCn -- since it cannot be 486 generated by mapping a non-OTN signal. An ODUCn is always formed by 487 multiplexing multiple LO-ODUs. 489 Table 2: Types and rates of ODUs usable for client mappings 491 ================================================================== 493 Clients (e.g. SONET/SDH, Ethernet) 494 + + + 495 | | | 496 +------------------+-------+------+------------------------+ 497 | OPUk | 498 +----------------------------------------------------------+ 499 | ODUk | 500 +-----------------------+---------------------------+------+ 501 | OTUk, OTUk.V, OTUkV | OPUk | | 502 +----------+----------------------------------------+ | 503 | OTLk.n | | ODUk | | 504 +----------+ +---------------------+-----+ | 505 | OTUk, OTUk.V, OTUkV | OPUCn | 506 +----------+-----------------------+ 507 | OTLk.n | | ODUCn | 508 +----------+ +------------+ 509 | OTUCn | 510 +------------+ 512 ================================================================== 514 Figure 4: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 516 4. Usecases 518 This section introduces various usecases that provide the rationale 519 for the requirements that any solution must satisfy. At a later 520 point in time, it is possible to consolidate these usecases so that 521 all the multiplexing (and demultiplexing) variants are encountered 522 along the path of an end-to-end ODU circuit. 524 Note-1: These usecases present scenarios in which OTUCn links are 525 depicted. These illustrations do not highlight how the OTUCn is 526 transported between the 3R points. That is, these usecases do not 527 cover cases in which a standard FlexO interface (e.g. as defined in 528 [ITU-T_G709.1]) is used, or whether a vendor specific mapping of 529 OTUCn to OTSiG (as defined in [ITU-T_G872]) is used. In other words, 530 multiple variants of these usecases based on FlexO usage (or not) are 531 not included in this document. 533 4.1. 100GE Client Service with a homogeneous chain of OTUC1 links 535 In the scenario illustrated in Figure 5 a 100GBASE-R client is mapped 536 into an ODU4 at NE1. The resulting ODU4 signal is multiplexed into 537 the ODUC1 server layer (using GMP) and further encapsulated to form 538 the OTUC1 signal. The links NE1-NE2, and NE2-NE3 are both OTUC1 539 links -- and they can carry one 100GE client mapped into an ODU4 540 server layer. Actions performed at NE2 are: (a) terminate OTUC1, and 541 ODUC1 towards NE1 (b) demultiplex the ODU4 signal from ODUC1 (c) map 542 the ODU4 signal onto a different ODUC1/OTUC1 towards NE3. NE3 543 performs the inverse sequence of steps performed at NE1, and recovers 544 the 100GBASE-R client from the ODU4 signal. Note that the ODU4 and 545 ODUC1 signals are not "interoperable" and that the ODUC1 is a server 546 layer to the ODU4 signal. 548 This illustration is also applicable to the usecase in which members 549 of a FlexE group are transported in a flexe-unaware mode in the 550 transport network. Although this illustration included only OTUC1 551 signals, any higher rate OTUCn signal can be substituted for these 552 signals. In this particular scenario, there are two adjacent ODUC1 553 hops, and the NE2 demultiplexs (and multiplexes) the ODU4 onto the 554 ODUC1. It is possible to construct an alternative scenario in the 555 case when NE2 acts as a regenerator, and doesn't terminate the ODUC1 556 signals in the two hops, and instead repeats the ODUC1 signal; this 557 scenario is specifically discussed in Section 4.4. 559 ================================================================== 561 +----------+ +----------+ 562 | 100GE | | 100GE | 563 +----------+ +---------------+ +----------+ 564 | ODU4 | | ODU4 | | ODU4 | 565 +----------+ +---------------+ +----------+ 566 | ODUC1 | | ODUC1 | ODUC1 | | ODUC1 | 567 +----------+ +---------------+ +----------+ 568 | OTUC1 +--------+ OTUC1 | OTUC1 +---------+ OTUC1 | 569 +----------+ +---------------+ +----------+ 570 NE1 NE2 NE3 572 +-------------> +-------------> 573 Scope of Scope of 574 OTUC1, ODUC1 OTUC1, ODUC1 576 ================================================================== 578 Figure 5: 100GE Client service 580 4.2. 100GE Client Service with a mix of ODU4, and ODUC1 connections 582 In the scenario illustrated in Figure 6 a 100GBASE-R client is mapped 583 into an ODU4 at NE1. The resulting ODU4 signal is encapsulated with 584 an OTU layer to form the OTU4 signal. Actions performed at NE2 are: 585 (a) terminate OTU4 layer, and extract the ODU4 signal (b) map the 586 ODU4 signal onto a different ODUC1/OTUC1 towards NE3. NE3 performs 587 the same set of actions that were performed by NE3 in Figure 5. This 588 usecase illustrates a scenario in which an ODU4 signal can span 589 between network elements regardless of whether they support the OTUCn 590 interfaces or not. 592 ================================================================== 594 +----------+ +----------+ 595 | 100GE | | 100GE | 596 +----------+ +---------------+ +----------+ 597 | ODU4 | | ODU4 | | ODU4 | 598 +----------+ +-------+-------+ +----------+ 599 | OTU4 +--------+ OTU4 | ODUC1 | | ODUC1 | 600 +----------+ +---------------+ +----------+ 601 | OTUC1 +---------+ OTUC1 | 602 --------+ +----------+ 603 NE1 NE2 NE3 605 +--------------> +----------------> 606 Scope of Scope of 607 OTU4 layer OTUC1, ODUC1 609 ================================================================== 611 Figure 6: 100GE Client Service with a mix of OTU4, and OTUC1 links 613 4.3. Transport of non-OTN Client Signal over ODUCn connection 615 Editor Note: this section may not be needed, as this section mainly 616 describes the setup of client signal over ODUflex, then over ODUCn. 617 Setup of ODUk/ODUflex can reuse mechanisms defined in RFC7139. 619 4.3.1. 400GE Client Service with a mix of OTUCn links 621 In the scenario illustrated in Figure 7 a 400GBASE-R client is mapped 622 into an ODUflex at NE1. The resulting ODUflex signal is multiplexed 623 into an ODUC4 (using GMP), and then transformed into an OTUC4 signal. 624 The links between NE1-NE2, and NE2-NE3 are OTUC4 and OTUC6 625 (respectively). Actions performed at NE2 are: (a) terminate OTUC4, 626 and ODUC4 towards NE1 (b) demultiplex the ODUflex signal from ODUC4 627 (c) map the ODUflex signal onto ODUC6/OTUC6 towards NE3. NE3 628 performs the inverse sequence of steps performed at NE1, and recovers 629 the 400GBASE-R client from the ODUflex signal. 631 Although not specifically illustrated in this figure, the 200G of 632 spare capacity in the NE2-NE3 links can be used to carry other client 633 signals.. Although the scenario illustrated in Figure 7 is specific 634 to 400GE, the treatment for packet clients at other rates (e.g. 25G, 635 50G, 200G) follows a very similar processing sequence. In the case 636 of 25GBASE-R clients , the 25GE client signal will be mapped to an 637 ODUflex, and can be multiplexed into an ODU4 signal, or an ODUCn 638 signal as illustrated here. 640 ================================================================== 642 +----------+ +----------+ 643 | 400GE | | 400GE | 644 +----------+ +---------------+ +----------+ 645 | ODUflex | | ODUflex | | ODUflex | 646 +----------+ +-------+-------+ +----------+ 647 | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | 648 +----------+ +---------------+ +----------+ 649 | OTUC4 +--------+ OTUC4 | OTUC6 +---------+ OTUC6 | 650 +----------+ +-------+-------+ +----------+ 651 NE1 NE2 NE3 653 <-------------> <-------------> 654 Scope of Scope of 655 OTUC4, ODUC4 OTUC6, ODUC6 657 ================================================================== 659 Figure 7: 400GE transport over OTUCn links 661 4.3.2. FlexE aware transport over OTUCn links 663 In the scenario illustrated in Figure 8 NE1 interfaces to a client 664 equipment which includes the FlexE SHIM functions which originate/ 665 terminate a FlexE group. The transport network edge node NE2 is 666 FlexE aware -- but doesn't terminate the FlexE group. NE1 may (as 667 defined in the FlexE draft [I-D.izh-ccamp-flexe-fwk]), crunch the 668 unavailable tributary slots in the FlexE PHY signals, and map the 669 resultant stream to one or more ODUflex signals. The links between 670 NE1-NE2, and NE2-NE3 are OTUC4 and OTUC6 (respectively). Actions 671 performed at NE2 are: (a) terminate OTUC4, and ODUC4 towards NE1 (b) 672 demultiplex the ODUflex signal from ODUC4 (c) map the ODUflex signal 673 onto ODUC6/OTUC6 towards NE3. NE3 recovers the Crunched and combined 674 PHY(s) from the ODUflex signal, re-adds the unavailable calendar 675 slots, and outputs the resulting stream towards the FlexE PHY(s). 677 In the scenario illustrated in Figure 8 the lowest rate OTUCn link is 678 the OTUC4 link between NE1-NE2. This means that the size of the 679 FlexE group is at most 4. FlexE groups with greater sizes can be 680 handled by utilizing appropriate OTUCn links. Note that at most 400G 681 of the capacity of OTUC6 (or 600G) NE2-NE3 link is occupied by the 682 ODUflex signal; the remaining bandwidth can be allocated to other 683 client signals. 685 ================================================================== 687 FlexE +----------+ +----------+ FlexE 688 group | Crunched | | Crunche | Group 689 +------> and | | and +--------> 690 | Combined | | Combined | Add 691 | PHY(s) | | PHY(s) | unavailable 692 +----------+ +---------------+ +----------+ Calendar 693 | ODUflex | | ODUflex | | ODUflex | slots 694 +----------+ +-------+-------+ +----------+ 695 | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | 696 +----------+ +---------------+ +----------+ 697 | OTUC4 +---+ OTUC4 | OTUC6 +---+ OTUC6 | 698 +----------+ +-------+-------+ +----------+ 699 NE1 NE2 NE3 701 <---------> <-----------> 702 Scope of Scope of 703 OTUC4, ODUC4 OTUC6, ODUC6 705 ================================================================== 707 Figure 8: FlexE aware transport over OTUCn links 709 4.3.3. FlexE Client transport over OTUCn links 711 This use case (see Figure 9) concerns the scenario in which a FlexE 712 group is terminated at the transport network edge node (via the FlexE 713 SHIM function), and the FlexE clients are demultiplexed, and 714 independently transported through the OTN network. In the scenario 715 illustrated in Figure 9 the lowest rate OTUCn link is the OTUC4 link 716 between NE1-NE2. This means that the maximum bit rate of the FlexE 717 client is at most 400G. FlexE clients with greater sizes can be 718 handled by utilizing appropriate OTUCn links. This figure 719 illustrates the case in which one FlexE client is transported between 720 NE1 and NE3. Other FlexE clients recovered at NE1 can routed 721 independently to NE3, or to other network elements. 723 ================================================================== 725 +-----------------+ +---------------+ 726 | FlexE | | FlexE | 727 | Client | | Client | 728 +-----------------+ +---------------+ 729 | FlexE | | +---------------+ | | Flex | 730 | SHIM | ODUflex | | ODUflex | |ODUflex| SHIM | 731 +-----------------+ +---------------+ +---------------+ 732 | FlexE | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | FlexE | 733 +----+ PHY(s +---------+ +---------------+ +-------+ PHY(s)+----> 734 FlexE | | OTUC4 +---+ OTUC4 | OTUC6 +---+ OTUC6 | | FlexE 735 Group +-----------------+ +---------------+ +---------------+ Group 736 NE1 NE2 NE3 738 <------------> <-----------> 739 Scope of Scope of 740 OTUC4, ODUC4 OTUC6, ODUC6 742 ================================================================== 744 Figure 9: FlexE client transport over OTUCn links 746 4.4. Multihop ODUCn link 748 As mentioned in the introductory section, the ODUCn is not a 749 switchable entity. The ODUCn layer is a server layer, which more-or- 750 less occupies the position of a section layer in OTN networks. As 751 such, the ODUCn signal must be terminated and the contained low-order 752 ODU flows can be switched independently to other OTN interfaces. 753 G.709 and G.872 however allow for digital regenerators to terminate 754 the OTUCn layer, and reinject the ODUCn layer towards another 755 interface (where a new OTUCn section layer is started). This 756 scenario is illustrated in Figure 10. In this figure, NE3 is the 757 regenerator. The ODUC2 signal is terminated at NE2, and NE4. At the 758 regeneration points, all the clients embedded inside the ODUCn signal 759 are not touched (i.e. no TS changes can occur). More specifically, 760 the OPUC2 signal is not modified in any way. However, the ODUC2 OH 761 may be modified if intrusive TCM monitoring points are applied to the 762 ODUC2 signal at NE3. It is for this reason that the ODUC2 entity 763 must be visible at NE3. 765 In scenarios involving multi-hop ODUCn links, GMPLS signalling will 766 be required to setup multiple ODUCn LSPs, each covering a regenerator 767 section (since an end-to-end ODUCn LSP is not possible except in very 768 simple configurations). A LO-ODU can then be switched across 769 multiple ODUCn LSPs (possibly with different rates). 771 ================================================================== 773 +----------+ +----------+ 774 | 100GE | | 100GE | 775 +----------+ +---------------+ +----------+ 776 | ODU4 | | ODU4 | | ODU4 | 777 +----------+ +-------+-------+ +---------+ +----------+ 778 | ODUC1 | | ODUC1 | ODUC2 | | ODUC2 | | ODUC2 | 779 +----------+ +---------------+ +---------+ +----------+ 780 | OTUC1 +-----+ OTUC1 | OTUC2 +-------+ OTUC2 +-------+ OTUC2 | 781 +----------+ +-------+-------+ +---------+ +----------+ 782 NE1 NE2 NE3 NE4 784 <-------------> <-------------> <-------------> 785 Scope of OTUC2 OTUC2 786 OTUC1, ODUC1 788 <---------------------------------> 789 ODUC2 791 ================================================================== 793 Figure 10: Multihop ODUCn link 795 4.5. Use of OTUCn-M links 797 The scenario illustrated in Figure 11 is a variant of the basic 798 usecase presented in Figure 5. The only difference is that the 799 second hop of the ODU4 connection makes use of a OTUC2-30 link which 800 has a capacity of 150G. 802 ================================================================== 804 +----------+ +-----------+ 805 | 100GE | | 100GE | 806 +----------+ +------------------+ +-----------+ 807 | ODU4 | | ODU4 | | ODU4 | 808 +----------+ +-------+----------+ +-----------+ 809 | ODUC1 | | ODUC1 | ODUC2 | | ODUC2 | 810 +----------+ +------------------+ +-----------+ 811 | OTUC1 +--------+ OTUC1 | OTUC2-30 +------+ OTUC2-30 | 812 +----------+ +-------+----------+ +-----------+ 813 NE1 NE2 NE3 815 +-------------> +-------------> 816 Scope of Scope of 817 OTUC1, ODUC1 OTUC2-30 818 ODUC2 820 ================================================================== 822 Figure 11: 100GE Client service over OTUCn-M links 824 4.6. Intermediate State of ODU mux 826 The ODUCn links have a tributary slot granularity of 5G -- and this 827 makes it a bit inefficient if a small number of ODU0 flows have to be 828 switched across an ODUCn links. In these cases, it is conceivable 829 that the intermediate nodes may offer the convenience of a 830 intermediate-stage multiplexing, whereby multiple ODU0 flows are 831 first multiplexed into a higher rate container (e.g. ODU2), and then 832 multiplexed into an ODUCn signal. This however assumes that all 833 these ODU0 flows are co-routed in the network. If this assumption 834 cannot be made, the only solution is to multiplex these ODU0 flows 835 into higher rate flows, from the source of the traffic. This usecase 836 isn't elaborated in this document. We can add details if required. 838 5. GMPLS Implications 840 5.1. OTN ODUCn/OTUCn hierarchy 842 As described in [ITU-T_G872], the digital layers of the OTN are 843 divided into the OTU layer and a hierarchy of one or more ODU layers. 844 As an ODUCn cannot be used to support non-OTN client signals, the OTN 845 client signals (e.g. ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex) 846 are first multiplexed into an ODUCn container, then the ODUCn 847 container is then mapped into OTUCn (see Figure 1). The signal 848 hierarchy supported by the ODUCn and OTUCn needs to be taken into 849 consideration in control plane Routing and Signaling. 851 ODUCn based connection management is concerned with controlling the 852 connectivity of ODUCn paths. According to [ITU-T_G872], the 853 intermediate nodes with ODUCn do not support the switching of ODUCn 854 tributary slot. Intermediate ODUCn points are only considered as a 855 forwarding node. Once an ODUCn path is used to transport client 856 signal, the TS occupied will not change across the ODUCn network. 858 5.2. OTUCn/OTUCn-M/ODUCn LSP 860 OTUCn/OTUCn-M Link is different from tranditional OTUk link. The 861 OTUk link is already configured once two matched OTU interfaces are 862 connected. But for setup of OTUCn link, the first thing that needs 863 to do is to bond several different OTUC instances together as one 864 group, which is seen as one OTUCn link. Control plane mechanisms are 865 needed to finish the bonding of these instances. 867 For transportation of client signal over ODUCn signal, an ODUCn LSP 868 is also needed to be configured with control plane mechanisms in 869 advance. 871 Once an ODUCn LSP is set up, the signaling mechanism defined in 872 [RFC7139] can be reused to set up ODUk LSP over ODUCn link. Setup of 873 ODUk LSP over ODUCn LSP is out of the scope of this document. 875 5.3. Implications for GMPLS Signaling 877 [RFC7139] extends the base RSVP-TE signaling specification [RFC4328] 878 to define RSVP-TE signaling extensions that can used to control OTN 879 networks built in accordance with [ITU-T_G709_2012]. 880 [ITU-T_G709_2016] introduced some new containers, such as OPUCn, 881 ODUCn, and OTUCn. The mechanisms defined in [RFC7139] do not support 882 these new OTN features. Therefore, GMPLS signaling protocols MUST be 883 extended to support this new functionality. The following summarizes 884 key aspects that should be considered for GMPLS signaling extensions: 886 a. Per the description in clause 7 of [ITU-T_G872], "the digital 887 layers of the OTN are divided into the OTU layer and a hierarchy 888 of one or more ODU layers". In B100G links, the ODUCn layer is 889 the bottom of the ODU hierarchy, and an ODUCn (induced) LSP needs 890 to be established before the LO-ODUs can flow across this link. 891 The traffic parameters in a signaling message should be extended 892 to support the new signal type(s) for the ODUCn signals. This 893 approach keeps the treatment for ODUCn signals consistent with 894 that of other ODU(s). 896 b. Support the new TS granularity: the signaling protocol should be 897 able to identify the TS granularity (i.e., the new 5 Gbps TS 898 granularity) to be used for establishing a Hierarchical LSP that 899 will be used to carry service LSP(s) requiring a specific TS 900 granularity. 902 c. A new label format MUST carry the information about one or more 903 OTUC/ODUC instances to be bonded together. 905 d. Support for LSP setup of OTUCn sub rates (OTUCn-M) path: based on 906 previous extensions, there should be new signal mechanism to 907 declare the OTUCn-m information. The GMPLS signalling protocol 908 SHALL support the setup of OTUCn sub rates (OTUCn-M) LSP, which 909 includes the negotiation of unavaliable slots number, slots 910 postion and allocation of slot resources. 912 e. The GMPLS signalling protocol should be able to specify the new 913 ODUCn/OTUCn signal types and related traffic information. The 914 traffic parameters should be extended in a signalling message to 915 support the new ODUCn/OTUCn signal types 917 5.4. Implications for GMPLS Routing 919 The path computation process needs to select a suitable route for an 920 ODUCn/OTUCn/OTUCn-M connection request. In order to perform the path 921 computation, it needs to evaluate the available bandwidth/slots 922 available on one or more candidate links. The routing protocol 923 SHOULD be extended to carry sufficient information to represent ODU 924 Traffic Engineering (TE) topology. 926 The Interface Switching Capability Descriptors defined in [RFC4203] 927 present a new constraint for LSP path computation. [RFC4203] defines 928 the Switching Capability, related Maximum LSP Bandwidth, and 929 Switching Capability specific information. [RFC7138] updates the 930 ISCD to support ODU4, ODU2e and ODUflex. The new Switching 931 Capability specific information provided in [RFC7138] have to be 932 adapted to support new features contained in [G709-2016]. The 933 following requirements should be considered: 935 a. Support for carrying the link multiplexing capability: As 936 discussed in Section 3.1.2, many different types of low-order 937 ODU(s) (e.g. ODUflex, ODU4) can be multiplexed into the ODUCn. 938 An ODUCn path may support one or more types of ODUk signals. The 939 routing protocol should be capable of carrying this multiplexing 940 capability. 942 b. Support for advertising 5G Tributary Slot Granularity introduced 943 [ITU-T_G709_2016]. 945 c. Support for advertisement of available bandwidth in an ODUCn 946 path. 948 6. Acknowledgements 950 7. Authors (Full List) 952 Qilei Wang (editor) 954 ZTE 956 Nanjing, China 958 Email: wang.qilei@zte.com.cn 960 Radha Valiveti (editor) 962 Infinera Corp 964 Sunnyvale, CA, USA 966 Email: rvaliveti@infinera.com 968 Haomian Zheng (editor) 970 Huawei 972 CN 974 EMail: zhenghaomian@huawei.com 976 Huub van Helvoort 978 Hai Gaoming B.V 980 EMail: huubatwork@gmail.com 982 Sergio Belotti 983 Nokia 985 EMail: sergio.belotti@nokia.com 987 Iftekhar Hussain 989 Infinera Corp 991 Sunnyvale, CA, USA 993 Email: IHussain@infinera.com 995 Daniele Ceccarelli 997 Ericsson 999 Email: daniele.ceccarelli@ericsson.com 1001 8. Contributors 1003 Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com 1005 Fatai Zhang, Huawei,zhangfatai@huawei.com 1007 Italo Busi, Huawei,italo.busi@huawei.com 1009 Zheyu Fan, Huawei, fanzheyu2@huawei.com 1011 Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn 1013 Zafar Ali, Cisco Systems, zali@cisco.com 1015 Daniel King, d.king@lancaster.ac.uk 1017 Manoj Kumar, Cisco Systems, manojk2@cisco.com 1019 Antonello Bonfanti, Cisco Systems, abonfant@cisco.com 1021 Akshaya Nadahalli, Cisco Systems, anadahal@cisco.com 1023 9. IANA Considerations 1025 This memo includes no request to IANA. 1027 10. Security Considerations 1029 None. 1031 11. References 1033 11.1. Normative References 1035 [ITU-T_G709.1] 1036 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 1037 2016", , 2016. 1039 [ITU-T_G709_2012] 1040 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 1041 02/2012", http://www.itu.int/rec/T-REC- 1042 G..709-201202-S/en, February 2012. 1044 [ITU-T_G709_2016] 1045 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 1046 07/2016", http://www.itu.int/rec/T-REC- 1047 G..709-201606-P/en, July 2016. 1049 [ITU-T_G872] 1050 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 1051 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 1052 January 2017. 1054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1055 Requirement Levels", BCP 14, RFC 2119, 1056 DOI 10.17487/RFC2119, March 1997, 1057 . 1059 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 1060 Switching (GMPLS) Signaling Extensions for G.709 Optical 1061 Transport Networks Control", RFC 4328, 1062 DOI 10.17487/RFC4328, January 2006, 1063 . 1065 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 1066 J. Drake, "Traffic Engineering Extensions to OSPF for 1067 GMPLS Control of Evolving G.709 Optical Transport 1068 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 1069 . 1071 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1072 and K. Pithewan, "GMPLS Signaling Extensions for Control 1073 of Evolving G.709 Optical Transport Networks", RFC 7139, 1074 DOI 10.17487/RFC7139, March 2014, 1075 . 1077 11.2. Informative References 1079 [I-D.izh-ccamp-flexe-fwk] 1080 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 1081 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 1082 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 1083 Zhong, "GMPLS Routing and Signaling Framework for Flexible 1084 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 1085 progress), October 2016. 1087 Authors' Addresses 1089 Qilei Wang (editor) 1090 ZTE 1091 Nanjing 1092 CN 1094 Email: wang.qilei@zte.com.cn 1096 Radha Valiveti (editor) 1097 Infinera Corp 1098 Sunnyvale 1099 USA 1101 Email: rvaliveti@infinera.com 1103 Haomian Zheng (editor) 1104 Huawei 1105 CN 1107 Email: zhenghaomian@huawei.com 1109 Huub van Helvoort 1110 Hai Gaoming B.V 1112 Email: huubatwork@gmail.com 1113 Sergio Belotti 1114 Nokia 1116 Email: sergio.belotti@nokia.com