idnits 2.17.1 draft-merge-ccamp-otn-b100g-fwk-01.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 (July 2, 2017) is 2480 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: January 3, 2018 Infinera Corp 6 H. Zheng, Ed. 7 Huawei 8 H. Helvoort 9 Hai Gaoming B.V 10 S. Belotti 11 Nokia 12 July 2, 2017 14 GMPLS Routing and Signaling Framework for B100G 15 draft-merge-ccamp-otn-b100g-fwk-01 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 http://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 January 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 (http://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 OTU4, and OTUC1 links 14 76 4.3. 400GE Client Service with a mix of OTUCn links . . . . . 14 77 4.4. FlexE aware transport over OTUCn links . . . . . . . . . 15 78 4.5. FlexE Client transport over OTUCn links . . . . . . . . . 16 79 4.6. Multihop ODUCn link . . . . . . . . . . . . . . . . . . . 17 80 4.7. Use of OTUCn-M links . . . . . . . . . . . . . . . . . . 18 81 4.8. Intermediate State of ODU mux . . . . . . . . . . . . . . 19 82 5. GMPLS Implications . . . . . . . . . . . . . . . . . . . . . 19 83 5.1. OTN ODUCn/OTUCn hierarchy . . . . . . . . . . . . . . . . 19 84 5.2. Implications for GMPLS Signaling . . . . . . . . . . . . 20 85 5.3. Implications for GMPLS Routing . . . . . . . . . . . . . 21 86 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 88 8. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 22 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 94 12.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Introduction 99 The current GMPLS routing [RFC7138] and signaling extensions 100 [RFC7139] includes coverage for all the OTN capabilities that were 101 defined in the 2012 version of G.709 [ITU-T_G709_2012]. 103 The 2016 version of G.709 [ITU-T_G709_2012] introduces support for 104 higher rate OTU signals, termed OTUCn (which have a nominal rate of n 105 x 100 Gbps). The newly introduced OTUCn represent a very powerful 106 extension to the OTN capabilities, and one which naturally scales to 107 transport any newer clients with bit rates in excess of 100G, as they 108 are introduced. 110 This document presents an overview of the changes introduced in 111 [ITU-T_G709_2016] and analyzes them to identify the extensions that 112 would be required in GMPLS routing and signaling to enable the new 113 OTN capabilities. 115 1.1. Scope 117 For the purposes of the B100G control plane discussion, the OTN 118 should be considered as a combination of ODU and OTSi layers. Note 119 that [ITU-T_G709_2016] is deprecating the use of the term "Och" for 120 B100G entities, and leaving it intact only for maintaining continuity 121 in the description of the signals with bandwidth upto 100G. This 122 document focuses on only the control of the ODU layer. The control 123 of the OTSi layer will be addressed in a separate document. 125 2. Terminology 127 2.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2.2. OTN terminology used in this document 135 a. OPUCn: Optical Payload Unit -Cn. 137 b. ODUCn: Optical Data Unit - Cn. 139 c. OTUCn: Fully standardized Optical Transport Unit - Cn. 141 d. OTUCn-M: This signal is an extension of the OTUCn signal 142 introduced above. This signal contains the same amount of 143 overhead as the OTUCn signal, but contains a reduced amount of 144 payload area. Specifically the payload area consists of M 5G 145 tributary slots (where M is strictly less than 20*n). 147 e. PSI: OPU Payload structure Indicator. This is a multi-frame 148 message and describes the composition of the OPU signal. This 149 field is a concatenation of the Payload type (PT) and the 150 Multiplex Structrure Indicator (MSI) defined below. 152 f. MSI: Multiplex Structure Indicator. This structure indicates the 153 grouping of the tributary slots in an OPU payload area to realize 154 a client signal that is multiplexed into an OPU. The individual 155 clients multiplexed into the OPU payload area are distinguished 156 by the Tributary Port number (TPN). 158 g. GMP: Generic Mapping Procedure. 160 Detailed description of these terms can be found in 161 [ITU-T_G709_2016]. 163 3. Overview of B100G in G.709 165 This section provides an overview of new features in 166 [ITU-T_G709_2016]. 168 3.1. OTUCn 170 In G.709 [ITU-T_G709_2012], the standard mechanism for transporting a 171 client signal is to first map it into an ODU signal (of the 172 appropriate rate), and then switch the resulting ODU signal through 173 the OTN network. In the course of its traversal through the OTN 174 network, the ODU signal generated by the mapper is either (a) 175 multiplexed into higher-order ODU, and then encapsulated to form an 176 OTU or (b) directly encapsulated into an OTU signal that defines the 177 section layer. The option (b), i.e. direct encapsulation into an OTU 178 was possible only for ODU1/ODU2/ODU3/ODU4; ODU signals with other 179 rates (e.g. ODUflex) would first have to be processed per option (a) 180 above. The term "client signal" is generic in the sense that it 181 encompasses both Constant Bit rate (CBR) clients (e.g. 10GBASE-R, 182 SONET OC-768), or packet traffic -- where the goal is to transfer the 183 payload from end-to-end (without regard for bit transparency at the 184 PCS layer). Given that OTU4 was the highest rate section layer 185 signal supported in [ITU-T_G709_2012], the client signal rates were 186 limited to be less than 100G (if ODU-VCAT was not used). 188 In order to carry client signals with rates greater than 100Gbps, 189 [ITU-T_G709_2016] takes a general and scalable approach that 190 decouples the rates of OTU signals from the client rate evolution. 191 The new OTU signal is called OTUCn; this signal is defined to have a 192 rate of (approximately) n*100G. The following are the key 193 characteristics of the OTUCn signal: 195 a. The OTUCn signal contains one ODUCn, which in turn contains one 196 OPUCn signal. The OTUCn and ODUCn signals perform digital 197 section roles only (see [ITU-T_G709_2016]:Section 6.1.1). The 198 OTUCn and ODUCn can be seen as being analogous to the regenerator 199 section, and multiplex section in SDH respectively. 201 b. The OTUCn signals can be viewed as being formed by interleaving n 202 OTUC signals (where are labeled 1, 2, ..., n), each of which has 203 the format of a standard OTUk signal without the FEC columns (per 204 [ITU-T_G709_2016]:Figure 7-1). The ODUCn, and OPUCn have a 205 similar structure, i.e. they can be seen as being formed by 206 interleaving n instances of ODUC, OPUC signals (respectively) The 207 OTUC signal contains the ODUC, and OPUC signals, just as in the 208 case of fixed rate OTUs defined in G.709 [ITU-T_G709_2016]. 210 c. Each of the OTUC "slices" have the same overhead (OH) as the 211 standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined 212 signal OTUCn has n instances of OTUC OH, ODUC OH, and OPUC OH. 214 d. The OTUC signal has a slightly higher rate compared to the OTU4 215 signal (without FEC); this is to ensure that the OPUC payload 216 area can carry an ODU4 signal. 218 3.1.1. Carrying OTUCn between 3R points 220 As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn 221 and OPUCn signal structures are presented in a (physical) interface 222 independent manner, by means of n OTUC, ODUC and OPUC instances that 223 are marked #1 to #n. Specifically, the definition of the OTUCn 224 signal does not cover aspects such as FEC, modulation formats, etc. 225 These details are defined as part of the adaptation of the OTUCn 226 layer to the optical layer(s). The specific interleaving of 227 OTUC/ODUC/OPUC signals onto the optical signals is interface specific 228 and specified for OTN interfaces with standardized application codes 229 in the interface specific recommendations (G.709.x). 231 The following scenarios of OTUCn transport need to be considered (see 232 Figure 1): 234 a. inter-domain interfaces: These types of interfaces are used for 235 connecting OTN edge nodes to (a) client equipment (e.g. routers) 236 or (b) hand-off points from other OTN networks. ITU-T has 237 standardized the Flexible OTN (FlexO) interfaces to support these 238 functions. Recommendation [ITU-T_G709.1] specifies a flexible 239 interoperable short-reach OTN interface over which an OTUCn (n 240 >=1) is transferred, using bonded FlexO interfaces which belong 241 to a FlexO group. The FlexO group supports physical interface 242 bonding, management of the group members, overhead for 243 communication between FlexO peers etc. (these overheads are 244 separate from the GCC0 channel defined over OTUCn). In its 245 current form, Recommendation [ITU-T_G709.1] is limited to the 246 case of transporting OTUCn signals using n 100G Ethernet PHY(s). 247 The mechanisms for transporting the OTUCn signals over 100G 248 optical interfaces are specified in [ITU-T_G709.1] and are not 249 repeated here. When the PHY(s) for the emerging set of Ethernet 250 signals, e.g. 200GbE and 400GbE, become available, new 251 recommendations can define the required adaptations. 253 b. intra-domain interfaces: In these cases, the OTUCn is transported 254 using a proprietary (vendor specific) encapsulation, FEC etc. In 255 future, it may be possible to transport OTUCn for intra-domain 256 links using future variants of FlexO. 258 ================================================================== 260 +--------------------------------------------------------+ 261 | OTUCn signal | 262 +--------------------------------------------------------+ 263 | Inter+Domain | Intra+Domain | Intra+Domain | 264 | Interface (IrDI)| Interface (IaDI)| Interface | 265 | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | 266 | | (Future) | Encap, FEC etc. | 267 +--------------------------------------------------------+ 269 ================================================================== 271 Figure 1: OTUCn transport possibilities 273 It is possible for an OTUCn signal to be transported via multiple 274 hops of lower-layer adaptation (see Figure 2). In this scenario, the 275 OTUCn spans multiple optical paths joined by a FlexO segment. An 276 end-to-end OTUCn LSP needs to be setup after the optical circuits are 277 established. The information about the FlexO interfaces (and group) 278 are configured at the FlexO endpoints, and there is no dynamic setup. 280 ================================================================== 282 Optical Segment Optical Segment 283 <--------------> <--------------> 285 +------+ +------+ +------+ +------+ 286 | | | +-----------+ | | | 287 | A +---------+ B |-----------| C +--------+ D | 288 | | | +-----------+ | | | 289 +------+ +------+ ^ +------+ +------+ 290 | 291 + 292 FlexO Group 293 <--------------------------------------------------> OTUCn 295 +-------+ +-------+ +-------+ 296 | OTUCn | | OTUCn | | OTUCn | 297 +-------+ +-------+ +-------+ 298 | OTSiG | | FlexO | | OTSiG | 299 +-------+ +-------+ +-------+ 301 ================================================================== 303 Figure 2: OTUCn transport - Multihop 305 This document views FlexO (even if there are some digital sub-layers 306 involved in the adaptation) and other OTUCn transport mechanisms as 307 "lower layers", and are therefore considered out-of-scope. The OTUCn 308 layer operates independent of the method used to transport the 309 signal. 311 3.2. ODUCn 313 The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by 314 the appropriate interleaving of content from n ODUC signal instances. 315 The ODUC frames have the same structure as a standard ODU -- in the 316 sense that it has the same Overhead (OH) area, and the payload area 317 -- but has a higher rate since its payload area can embed an ODU4 318 signal. The ODUCn signal can be formed in one of the following ways: 320 By multiplexing lower-rate (i.e. both low-order and high-order) 321 ODUk signals. 323 Each of the n instances of ODUC can carry the NULL signal (as 324 specified in [ITU-T_G709_2016]: Section 17.5.1) 325 Each of the n instances of ODUC can carry the PN-11 PRBS test 326 sequence (as specified in [ITU-T_G709_2016]: Section 17.5.2) 328 It is concievable that vendors might implement proprietary 329 mappings (Payload Type values of 0x80-x8F)of non-OTN client 330 signals. An interoperable control plane cannot make use of these 331 proprietary ODUCn signals, and hence this case isn't considered in 332 this document. 334 The ODUCn signals have a rate that is captured in Table 1. 336 +----------+--------------------------------------------------------+ 337 | ODU Type | ODU Bit Rate | 338 +----------+--------------------------------------------------------+ 339 | ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 | 340 | | kbit/s | 341 +----------+--------------------------------------------------------+ 343 Table 1: ODUCn rates 345 The ODUCn is a multiplex section ODU signal, and is mapped into an 346 OTUCn signal which provides the regenerator section layer. In some 347 scenarios, the ODUCn, and OTUCn signals will be co-terminous, i.e. 348 they will have identical source/sink locations. [ITU-T_G709_2016] 349 and [ITU-T_G872] allow for the ODUCn signal to pass through a digital 350 regenerator node which will terminate the OTUCn layer, but will pass 351 the regenerated (but otherwise untouched) ODUCn towards a different 352 OTUCn interface where a fresh OTUCn layer will be initiated (see 353 Figure 3). In this case, an ODUCn LSP needs to be set up to traverse 354 the 3 OTUCn segments. 356 Specifically, the OPUCn signal flows through these regenerators 357 unchanged. That is, the set of client signals, their TPNs, trib-slot 358 allocation remains unchanged. Note however that the ODUCn Overhead 359 (OH) might be modified if TCM sub-layers are instantiated in order to 360 monitor the performance of the repeater hops. In this sense, the 361 ODUCn should not be seen as a general ODU which can be switched via 362 an ODUk cross-connect. 364 ================================================================== 366 ^ FlexO group ^ FlexO group 367 | | 368 +--------+ | +--------+ +--------+ | +--------+ 369 | +-----------+ | | +----------+ | 370 | OTN |-----------| OTN | | OTN |----------| OTN | 371 | DXC +-----------+ WXC +----------------+ WXC +----------+ DXC | 372 | | | 3R | | 3R | | | 373 +--------+ +--------+ +--------+ +--------+ 375 <------------------> <----------------------> <------------------> 376 OTUCn/FlexO OTUCn/OTSiG OTUCn/FlexO 378 <-----------------------------------------------------------------> ODUCn 380 ================================================================== 382 Figure 3: Multi-hop ODUCn signal 384 3.3. OTUCn-M 386 The standard OTUCn signal has the same rate as that of the ODUCn 387 signal as captured in Table 1. This implies that the OTUCn signal 388 can only be transported over wavelength groups which have a total 389 capacity of multiples of (approximately) 100G. Modern DSPs support a 390 variety of bit rates per wavelength, depending on the reach 391 requirements for the optical link. With this in mind, ITU-T supports 392 the notion of a reduced rate OTUCn signal, termed the OTUCn-M. The 393 OTUCn-M signal is derived from the OTUCn signal by retaining all the 394 n instances of overhead (one per OTUC slice) and crunching the OPUC 395 tributary slots marked as "unavailable". 397 3.4. OPUCn Time Slot Granularity 399 [ITU-T_G709_2012] introduced the support for 1.25G granular tributary 400 slots in OPU2, OPU3, and OPU4 signals. With the introduction of 401 higher rate signals such as the OPUCn, it is no longer practical for 402 the optical networks (and the datapath hardware) to support a very 403 large number of flows at such a fine granularity. ITU-T has defined 404 the OPUC with a tributary slot granularity of 5G. This means that 405 the ODUCn signal has 20*n tributary slots (of 5Gbps capacity). 407 3.5. Structure of OPUCn MSI with Payload type 0x22 409 As mentioned above, the OPUCn signal has 20*n 5G tributary slots. 410 The OPUCn contains n PSI structures, one per OPUC instance. The PSI 411 structure consists of the Payload Type (of 0x22), followed by a 412 Reserved Field (1 byte), followed by the MSI. The OPUCn MSI field 413 has a fixed length of 40*n bytes and indicates the ODTU content of 414 each TS of an OPUCn. Two bytes are used for each of the 20*n 415 tributary slots, and each such information structure has the 416 following format ([ITU-T_G709_2016] G.709:Section 20.4.1): 418 a. The TS availability bit 1 indicates if the tributary slot is 419 available or unavailable 421 b. The TS occupation bit 9 indicates if the tributary slot is 422 allocated or unallocated 424 c. The tributary port number in bits 2-8, 10-16 indicates the 425 identity of the OTN client signal (i.e. LO-ODU) that is being 426 transported in this TS; a flexible assignment of tributary port 427 to tributary slots is possible. Note that 1 <= TPN <= 10*n. The 428 value is set to all-0s when the occupation bit has the value 0 429 (tributary slot is unallocated). The same TPN value is used in 430 all the TS(s) assigned to a given OTN client client signal. 432 3.6. Client Signal Mappings 434 Note that [ITU-T_G709_2016] introduces support for OTUCn signals with 435 rates of n*100G and also introduces support for client signals with 436 rates larger than 100G (e.g. the future 400GBASE-R client being 437 standardized by IEEE, higher packet streams from NPUs). The approach 438 taken by the ITU-T to map non-OTN client signals to the appropriate 439 ODU containers is as follows: 441 a. All client signals with rates less than 100G are mapped as 442 specified in [ITU-T_G709_2016]:Clause 17. These mappings are 443 identical to those specified in the earlier revision of G.709 444 [ITU-T_G709_2012]. Thus, for example, the 1000BASE-X/10GBASE-R 445 signals are mapped to ODU0/ODU2e respectively (see Table 2 -- 446 based on Table 7-2 in [ITU-T_G709_2016]) 448 b. Always map the new and emerging client signals to ODUflex signals 449 of the appropriate rates (see Table 2 -- based on Table 7-2 in 450 [ITU-T_G709_2016]) 452 c. Drop support for ODU Virtual Concatenation. This simplifies the 453 network, and the supporting hardware since multiple different 454 mappings for the same client are no longer necessary. Note that 455 legacy implementations that transported sub-100G clients using 456 ODU VCAT shall continue to be supported. 458 d. ODUflex signals are low-order signals only. If the ODUflex 459 entities have rates of 100G or less, they can be transported 460 using either an ODUk (k=1..4) or an ODUCn server layer. On the 461 other hand, ODUflex connections with rates greater than 100G will 462 require the server layer to be ODUCn. The ODUCn signals must be 463 adapted to an OTUCn signal. Figure 4 illstrates the hierarchy of 464 the digital signals defined in [ITU-T_G709_2016]. 466 +----------------+--------------------------------------------------+ 467 | ODU Type | ODU Bit Rate | 468 +----------------+--------------------------------------------------+ 469 | ODU0 | 1,244,160 Kbps | 470 | ODU1 | 239/238 x 2,488,320 Kbps | 471 | ODU2 | 239/237 x 9,953,280 Kbps | 472 | ODU2e | 239/237 x 10,312,500 Kbps | 473 | ODU3 | 239/236 x 39,813,120 Kbps | 474 | ODU4 | 239/227 x 99,532,800 Kbps | 475 | ODUflex for | 239/238 x Client signal Bit rate | 476 | CBR client | | 477 | signals | | 478 | ODUflex for | Configured bit rate | 479 | GFP-F mapped | | 480 | packet traffic | | 481 | ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= | 482 | IMP mapped | 1 | 483 | packet traffic | | 484 | ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is | 485 | FlexE aware | total number of available tributary slots among | 486 | transport | all PHYs which have been crunched and combined. | 487 +----------------+--------------------------------------------------+ 489 Note that this table doesn't include ODUCn -- since it cannot be 490 generated by mapping a non-OTN signal. An ODUCn is always formed by 491 multiplexing multiple LO-ODUs. 493 Table 2: Types and rates of ODUs usable for client mappings 495 ================================================================== 497 Clients (e.g. SONET/SDH, Ethernet) 498 + + + 499 | | | 500 +------------------+-------+------+------------------------+ 501 | OPUk | 502 +----------------------------------------------------------+ 503 | ODUk | 504 +-----------------------+---------------------------+------+ 505 | OTUk, OTUk.V, OTUkV | OPUk | | 506 +----------+----------------------------------------+ | 507 | OTLk.n | | ODUk | | 508 +----------+ +---------------------+-----+ | 509 | OTUk, OTUk.V, OTUkV | OPUCn | 510 +----------+-----------------------+ 511 | OTLk.n | | ODUCn | 512 +----------+ +------------+ 513 | OTUCn | 514 +------------+ 516 ================================================================== 518 Figure 4: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 520 4. Usecases 522 This section introduces various usecases that provide the rationale 523 for the requirements that any solution must satisfy. At a later 524 point in time, it is possible to consolidate these usecases so that 525 all the multiplexing (and demultiplexing) variants are encountered 526 along the path of an end-to-end ODU circuit. 528 Note-1: These usecases present scenarios in which OTUCn links are 529 depicted. These illustrations do not highlight how the OTUCn is 530 transported between the 3R points. That is, these usecases cover 531 cases in which a standard FlexO interface (e.g. as defined in 532 [ITU-T_G709.1]) is used, or whether a vendor specific mapping of 533 OTUCn to OTSiG (as defined in [ITU-T_G872]) is used. In other words, 534 multiple variants of these usecases based on FlexO usage (or not) are 535 not included in this document. 537 Note-2: This version of the document covers many usecases in detail. 538 Future versions of this document may combine multiple usecases (e.g. 539 all cases involving ODUflex into one broad category), and retain only 540 the minimal set of usecases. 542 4.1. 100GE Client Service with a homogeneous chain of OTUC1 links 544 In the scenario illustrated in Figure 5 a 100GBASE-R client is mapped 545 into an ODU4 at NE1. The resulting ODU4 signal is multiplexed into 546 the ODUC1 server layer (using GMP) and further encapsulated to form 547 the OTUC1 signal. The links NE1-NE2, and NE2-NE3 are both OTUC1 548 links -- and they can carry one 100GE client mapped into an ODU4 549 server layer. Actions performed at NE2 are: (a) terminate OTUC1, and 550 ODUC1 towards NE1 (b) demultiplex the ODU4 signal from ODUC1 (c) map 551 the ODU4 signal onto a different ODUC1/OTUC1 towards NE3. NE3 552 performs the inverse sequence of steps performed at NE1, and recovers 553 the 100GBASE-R client from the ODU4 signal. Note that the ODU4 and 554 ODUC1 signals are not "interoperable" and that the ODUC1 is a server 555 layer to the ODU4 signal. 557 This illustration is also applicable to the usecase in which members 558 of a FlexE group are transported in a flexe-unaware mode in the 559 transport network. Although this illustration included only OTUC1 560 signals, any higher rate OTUCn signal can be substituted for these 561 signals. In this particular scenario, there are two adjacent ODUC1 562 hops, and the NE2 demultiplexs (and multiplexes) the ODU4 onto the 563 ODUC1. It is possible to construct an alternative scenario in the 564 case when NE2 acts as a regenerator, and doesn't terminate the ODUC1 565 signals in the two hops, and instead repeats the ODUC1 signal; this 566 scenario is specifically discussed in Section 4.6. 568 ================================================================== 570 +----------+ +----------+ 571 | 100GE | | 100GE | 572 +----------+ +---------------+ +----------+ 573 | ODU4 | | ODU4 | | ODU4 | 574 +----------+ +---------------+ +----------+ 575 | ODUC1 | | ODUC1 | ODUC1 | | ODUC1 | 576 +----------+ +---------------+ +----------+ 577 | OTUC1 +--------+ OTUC1 | OTUC1 +---------+ OTUC1 | 578 +----------+ +---------------+ +----------+ 579 NE1 NE2 NE3 581 +-------------> +-------------> 582 Scope of Scope of 583 OTUC1, ODUC1 OTUC1, ODUC1 585 ================================================================== 587 Figure 5: 100GE Client service 589 4.2. 100GE Client Service with a mix of OTU4, and OTUC1 links 591 In the scenario illustrated in Figure 6 a 100GBASE-R client is mapped 592 into an ODU4 at NE1. The resulting ODU4 signal is encapsulated with 593 an OTU layer to form the OTU4 signal. Actions performed at NE2 are: 594 (a) terminate OTU4 layer, and extract the ODU4 signal (b) map the 595 ODU4 signal onto a different ODUC1/OTUC1 towards NE3. NE3 performs 596 the same set of actions that were performed by NE3 in Figure 5. This 597 usecase illustrates a scenario in which an ODU4 signal can span 598 between network elements regardless of whether they support the OTUCn 599 interfaces or not. 601 ================================================================== 603 +----------+ +----------+ 604 | 100GE | | 100GE | 605 +----------+ +---------------+ +----------+ 606 | ODU4 | | ODU4 | | ODU4 | 607 +----------+ +-------+-------+ +----------+ 608 | OTU4 +--------+ OTU4 | ODUC1 | | ODUC1 | 609 +----------+ +---------------+ +----------+ 610 | OTUC1 +---------+ OTUC1 | 611 --------+ +----------+ 612 NE1 NE2 NE3 614 +--------------> +----------------> 615 Scope of Scope of 616 OTU4 layer OTUC1, ODUC1 618 ================================================================== 620 Figure 6: 100GE Client Service with a mix of OTU4, and OTUC1 links 622 4.3. 400GE Client Service with a mix of OTUCn links 624 In the scenario illustrated in Figure 7 a 400GBASE-R client is mapped 625 into an ODUflex at NE1. The resulting ODUflex signal is multiplexed 626 into an ODUC4 (using GMP), and then transformed into an OTUC4 signal. 627 The links between NE1-NE2, and NE2-NE3 are OTUC4 and OTUC6 628 (respectively). Actions performed at NE2 are: (a) terminate OTUC4, 629 and ODUC4 towards NE1 (b) demultiplex the ODUflex signal from ODUC4 630 (c) map the ODUflex signal onto ODUC6/OTUC6 towards NE3. NE3 631 performs the inverse sequence of steps performed at NE1, and recovers 632 the 400GBASE-R client from the ODUflex signal. 634 Although not specifically illustrated in this figure, the 200G of 635 spare capacity in the NE2-NE3 links can be used to carry other client 636 signals.. Although the scenario illustrated in Figure 7 is specific 637 to 400GE, the treatment for packet clients at other rates (e.g. 25G, 638 50G, 200G) follows a very similar processing sequence. In the case 639 of 25GBASE-R clients , the 25GE client signal will be mapped to an 640 ODUflex, and can be multiplexed into an ODU4 signal, or an ODUCn 641 signal as illustrated here. 643 ================================================================== 645 +----------+ +----------+ 646 | 400GE | | 400GE | 647 +----------+ +---------------+ +----------+ 648 | ODUflex | | ODUflex | | ODUflex | 649 +----------+ +-------+-------+ +----------+ 650 | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | 651 +----------+ +---------------+ +----------+ 652 | OTUC4 +--------+ OTUC4 | OTUC6 +---------+ OTUC6 | 653 +----------+ +-------+-------+ +----------+ 654 NE1 NE2 NE3 656 <-------------> <-------------> 657 Scope of Scope of 658 OTUC4, ODUC4 OTUC6, ODUC6 660 ================================================================== 662 Figure 7: 400GE transport over OTUCn links 664 4.4. FlexE aware transport over OTUCn links 666 In the scenario illustrated in Figure 8 NE1 interfaces to a client 667 equipment which includes the FlexE SHIM functions which originate/ 668 terminate a FlexE group. The transport network edge node NE2 is 669 FlexE aware -- but doesn't terminate the FlexE group. NE1 may (as 670 defined in the FlexE draft [I-D.izh-ccamp-flexe-fwk]), crunch the 671 unavailable tributary slots in the FlexE PHY signals, and map the 672 resultant stream to one or more ODUflex signals. The links between 673 NE1-NE2, and NE2-NE3 are OTUC4 and OTUC6 (respectively). Actions 674 performed at NE2 are: (a) terminate OTUC4, and ODUC4 towards NE1 (b) 675 demultiplex the ODUflex signal from ODUC4 (c) map the ODUflex signal 676 onto ODUC6/OTUC6 towards NE3. NE3 recovers the Crunched and combined 677 PHY(s) from the ODUflex signal, re-adds the unavailable calendar 678 slots, and outputs the resulting stream towards the FlexE PHY(s). 680 In the scenario illustrated in Figure 8 the lowest rate OTUCn link is 681 the OTUC4 link between NE1-NE2. This means that the size of the 682 FlexE group is at most 4. FlexE groups with greater sizes can be 683 handled by utilizing appropriate OTUCn links. Note that at most 400G 684 of the capacity of OTUC6 (or 600G) NE2-NE3 link is occupied by the 685 ODUflex signal; the remaining bandwidth can be allocated to other 686 client signals. 688 ================================================================== 690 FlexE +----------+ +----------+ FlexE 691 group | Crunched | | Crunche | Group 692 +------> and | | and +--------> 693 | Combined | | Combined | Add 694 | PHY(s) | | PHY(s) | unavailable 695 +----------+ +---------------+ +----------+ Calendar 696 | ODUflex | | ODUflex | | ODUflex | slots 697 +----------+ +-------+-------+ +----------+ 698 | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | 699 +----------+ +---------------+ +----------+ 700 | OTUC4 +---+ OTUC4 | OTUC6 +---+ OTUC6 | 701 +----------+ +-------+-------+ +----------+ 702 NE1 NE2 NE3 704 <---------> <-----------> 705 Scope of Scope of 706 OTUC4, ODUC4 OTUC6, ODUC6 708 ================================================================== 710 Figure 8: FlexE aware transport over OTUCn links 712 4.5. FlexE Client transport over OTUCn links 714 This use case (see Figure 9) concerns the scenario in which a FlexE 715 group is terminated at the transport network edge node (via the FlexE 716 SHIM function), and the FlexE clients are demultiplexed, and 717 independently transported through the OTN network. In the scenario 718 illustrated in Figure 9 the lowest rate OTUCn link is the OTUC4 link 719 between NE1-NE2. This means that the maximum bit rate of the FlexE 720 client is at most 400G. FlexE clients with greater sizes can be 721 handled by utilizing appropriate OTUCn links. This figure 722 illustrates the case in which one FlexE client is transported between 723 NE1 and NE3. Other FlexE clients recovered at NE1 can routed 724 independently to NE3, or to other network elements. 726 ================================================================== 728 +-----------------+ +---------------+ 729 | FlexE | | FlexE | 730 | Client | | Client | 731 +-----------------+ +---------------+ 732 | FlexE | | +---------------+ | | Flex | 733 | SHIM | ODUflex | | ODUflex | |ODUflex| SHIM | 734 +-----------------+ +---------------+ +---------------+ 735 | FlexE | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | FlexE | 736 +----+ PHY(s +---------+ +---------------+ +-------+ PHY(s)+----> 737 FlexE | | OTUC4 +---+ OTUC4 | OTUC6 +---+ OTUC6 | | FlexE 738 Group +-----------------+ +---------------+ +---------------+ Group 739 NE1 NE2 NE3 741 <------------> <-----------> 742 Scope of Scope of 743 OTUC4, ODUC4 OTUC6, ODUC6 745 ================================================================== 747 Figure 9: FlexE client transport over OTUCn links 749 4.6. Multihop ODUCn link 751 As mentioned in the introductory section, the ODUCn is not a 752 switchable entity. The ODUCn layer is a server layer, which more-or- 753 less occupies the position of a section layer in OTN networks. As 754 such, the ODUCn signal must be terminated and the contained low-order 755 ODU flows can be switched independently to other OTN interfaces. 756 G.709 and G.872 however allow for digital regenerators to terminate 757 the OTUCn layer, and reinject the ODUCn layer towards another 758 interface (where a new OTUCn section layer is started). This 759 scenario is illustrated in Figure 10. In this figure, NE3 is the 760 regenerator. The ODUC2 signal is terminated at NE2, and NE4. At the 761 regeneration points, all the clients embedded inside the ODUCn signal 762 are not touched (i.e. no TS changes can occur). More specifically, 763 the OPUC2 signal is not modified in any way. However, the ODUC2 OH 764 may be modified if intrusive TCM monitoring points are applied to the 765 ODUC2 signal at NE3. It is for this reason that the ODUC2 entity 766 must be visible at NE3. 768 In scenarios involving multi-hop ODUCn links, GMPLS signalling will 769 be required to setup multiple ODUCn LSPs, each covering a regenerator 770 section (since an end-to-end ODUCn LSP is not possible except in very 771 simple configurations). A LO-ODU can then be switched across 772 multiple ODUCn LSPs (possibly with different rates). 774 ================================================================== 776 +----------+ +----------+ 777 | 100GE | | 100GE | 778 +----------+ +---------------+ +----------+ 779 | ODU4 | | ODU4 | | ODU4 | 780 +----------+ +-------+-------+ +---------+ +----------+ 781 | ODUC1 | | ODUC1 | ODUC2 | | ODUC2 | | ODUC2 | 782 +----------+ +---------------+ +---------+ +----------+ 783 | OTUC1 +-----+ OTUC1 | OTUC2 +-------+ OTUC2 +-------+ OTUC2 | 784 +----------+ +-------+-------+ +---------+ +----------+ 785 NE1 NE2 NE3 NE4 787 <-------------> <-------------> <-------------> 788 Scope of OTUC2 OTUC2 789 OTUC1, ODUC1 791 <---------------------------------> 792 ODUC2 794 ================================================================== 796 Figure 10: Multihop ODUCn link 798 4.7. Use of OTUCn-M links 800 The scenario illustrated in Figure 11 is a variant of the basic 801 usecase presented in Figure 5. The only difference is that the 802 second hop of the ODU4 connection makes use of a OTUC2-30 link which 803 has a capacity of 150G. 805 ================================================================== 807 +----------+ +-----------+ 808 | 100GE | | 100GE | 809 +----------+ +------------------+ +-----------+ 810 | ODU4 | | ODU4 | | ODU4 | 811 +----------+ +-------+----------+ +-----------+ 812 | ODUC1 | | ODUC1 | ODUC2 | | ODUC2 | 813 +----------+ +------------------+ +-----------+ 814 | OTUC1 +--------+ OTUC1 | OTUC2-30 +------+ OTUC2-30 | 815 +----------+ +-------+----------+ +-----------+ 816 NE1 NE2 NE3 818 +-------------> +-------------> 819 Scope of Scope of 820 OTUC1, ODUC1 OTUC2-30 821 ODUC2 823 ================================================================== 825 Figure 11: 100GE Client service over OTUCn-M links 827 4.8. Intermediate State of ODU mux 829 The ODUCn links have a tributary slot granularity of 5G -- and this 830 makes it a bit inefficient if a small number of ODU0 flows have to be 831 switched across an ODUCn links. In these cases, it is conceivable 832 that the intermediate nodes may offer the convenience of a 833 intermediate-stage multiplexing, whereby multiple ODU0 flows are 834 first multiplexed into a higher rate container (e.g. ODU2), and then 835 multiplexed into an ODUCn signal. This however assumes that all 836 these ODU0 flows are co-routed in the network. If this assumption 837 cannot be made, the only solution is to multiplex these ODU0 flows 838 into higher rate flows, from the source of the traffic. This usecase 839 isn't elaborated in this document. We can add details if required. 841 5. GMPLS Implications 843 5.1. OTN ODUCn/OTUCn hierarchy 845 As described in [ITU-T_G872], the digital layers of the OTN are 846 divided into the OTU layer and a hierarchy of one or more ODU layers. 847 As an ODUCn cannot be used to support non-OTN client signals, the OTN 848 client signals (e.g. ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex) 849 are first multiplexed into an ODUCn container, then the ODUCn 850 container is then mapped into OTUCn (see Figure 1). The signal 851 hierarchy supported by the ODUCn and OTUCn needs to be taken into 852 consideration in control plane Routing and Signaling. 854 ODUCn based connection management is concerned with controlling the 855 connectivity of ODUCn paths. According to [ITU-T_G872], the 856 intermediate nodes with ODUCn do not support the switching of ODUCn 857 tributary slot. Intermediate ODUCn points are only considered as a 858 forwarding node. Once an ODUCn path is used to transport client 859 signal, the TS occupied will not change across the ODUCn network. 861 5.2. Implications for GMPLS Signaling 863 [RFC7139] extends the base RSVP-TE signaling specification [RFC4328] 864 to define RSVP-TE signaling extensions that can used to control OTN 865 networks built in accordance with [ITU-T_G709_2012]. 866 [ITU-T_G709_2016] introduced some new containers, such as OPUCn, 867 ODUCn, and OTUCn. The mechanisms defined in [RFC7139] do not support 868 these new OTN features. Therefore, GMPLS signaling protocols MUST be 869 extended to support this new functionality. The following summarizes 870 key aspects that should be considered for GMPLS signaling extensions: 872 a. Per the description in clause 7 of [ITU-T_G872], "the digital 873 layers of the OTN are divided into the OTU layer and a hierarchy 874 of one or more ODU layers". In B100G links, the ODUCn layer is 875 the bottom of the ODU hierarchy, and an ODUCn (induced) LSP needs 876 to be established before the LO-ODUs can flow across this link. 877 The traffic parameters in a signaling message should be extended 878 to support the new signal type(s) for the ODUCn signals. This 879 approach keeps the treatment for ODUCn signals consistent with 880 that of other ODU(s). 882 b. Support the new TS granularity: the signaling protocol should be 883 able to identify the TS granularity (i.e., the new 5 Gbps TS 884 granularity) to be used for establishing a Hierarchical LSP that 885 will be used to carry service LSP(s) requiring a specific TS 886 granularity. 888 c. Support for LSP setup of new ODUCn containers with related 889 mapping and multiplexing capabilities. 891 d. A new label format MUST carry the information about the set of 892 ODUCn tributary slots allocated to a specific LO-ODU. It MUST be 893 possible for a single LO-ODU to occupy an arbitrary set of 894 tributary slots, selected from one or more OTUC/ODUC instances. 896 e. Support for TPN allocation and negotiation: TPN needs to be 897 configured as part of the MSI information. A signaling mechanism 898 must be identified to carry TPN information if the control plane 899 is used to configure MSI information. The range of TPN is 900 [1..10*n] and the range of TPN is smaller than the number of 901 tributary slots (20*n); e.g. it is not possible to carry 15 5G 902 ODUflex signals in an ODUC1. This constraint MUST be taken into 903 account in the control plane supported). 905 f. 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 g. 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.3. 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. Open Issues 950 1. [Note (RSV)]: This document elaborates on several FlexE and 400GE 951 usecases. Since all these cases map the non-OTN client signals 952 into ODUflex signals of various rates, it might be better to 953 combine all these usecases into one category that handles ODUflex 954 LSPs. From a control plane point of view, the differences in the 955 data plane processing are not relevant. This change will be made 956 in a future revision of this document (if there is agreement). 958 7. Acknowledgements 960 8. Authors (Full List) 962 Qilei Wang (editor) 964 ZTE 966 Nanjing, China 968 Email: wang.qilei@zte.com.cn 970 Radha Valiveti (editor) 972 Infinera Corp 974 Sunnyvale, CA, USA 976 Email: rvaliveti@infinera.com 978 Haomian Zheng (editor) 980 Huawei 982 CN 984 EMail: zhenghaomian@huawei.com 985 Huub van Helvoort 987 Hai Gaoming B.V 989 EMail: huubatwork@gmail.com 991 Sergio Belotti 993 Nokia 995 EMail: sergio.belotti@nokia.com 997 Iftekhar Hussain 999 Infinera Corp 1001 Sunnyvale, CA, USA 1003 Email: IHussain@infinera.com 1005 Daniele Ceccarelli 1007 Ericsson 1009 Email: daniele.ceccarelli@ericsson.com 1011 9. Contributors 1013 Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com 1015 Fatai Zhang, Huawei,zhangfatai@huawei.com 1017 Italo Busi, Huawei,italo.busi@huawei.com 1019 Zheyu Fan, Huawei, fanzheyu2@huawei.com 1021 Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn 1023 Zafar Ali, Cisco Systems, zali@cisco.com 1025 Daniel King, d.king@lancaster.ac.uk 1026 Manoj Kumar, Cisco Systems, manojk2@cisco.com 1028 Antonello Bonfanti, Cisco Systems, abonfant@cisco.com 1030 Akshaya Nadahalli, Cisco Systems, anadahal@cisco.com 1032 10. IANA Considerations 1034 This memo includes no request to IANA. 1036 11. Security Considerations 1038 None. 1040 12. References 1042 12.1. Normative References 1044 [ITU-T_G709.1] 1045 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 1046 2016", , 2016. 1048 [ITU-T_G709_2012] 1049 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 1050 02/2012", 1051 http://www.itu.int/rec/T-REC-G..709-201202-S/en, February 1052 2012. 1054 [ITU-T_G709_2016] 1055 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 1056 07/2016", 1057 http://www.itu.int/rec/T-REC-G..709-201606-P/en, July 1058 2016. 1060 [ITU-T_G872] 1061 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 1062 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 1063 January 2017. 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, 1067 DOI 10.17487/RFC2119, March 1997, 1068 . 1070 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 1071 Switching (GMPLS) Signaling Extensions for G.709 Optical 1072 Transport Networks Control", RFC 4328, 1073 DOI 10.17487/RFC4328, January 2006, 1074 . 1076 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 1077 J. Drake, "Traffic Engineering Extensions to OSPF for 1078 GMPLS Control of Evolving G.709 Optical Transport 1079 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 1080 . 1082 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1083 and K. Pithewan, "GMPLS Signaling Extensions for Control 1084 of Evolving G.709 Optical Transport Networks", RFC 7139, 1085 DOI 10.17487/RFC7139, March 2014, 1086 . 1088 12.2. Informative References 1090 [I-D.izh-ccamp-flexe-fwk] 1091 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 1092 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 1093 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 1094 Zhong, "GMPLS Routing and Signaling Framework for Flexible 1095 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 1096 progress), October 2016. 1098 Authors' Addresses 1100 Qilei Wang (editor) 1101 ZTE 1102 Nanjing 1103 CN 1105 Email: wang.qilei@zte.com.cn 1107 Radha Valiveti (editor) 1108 Infinera Corp 1109 Sunnyvale 1110 USA 1112 Email: rvaliveti@infinera.com 1113 Haomian Zheng (editor) 1114 Huawei 1115 CN 1117 Email: zhenghaomian@huawei.com 1119 Huub van Helvoort 1120 Hai Gaoming B.V 1122 Email: huubatwork@gmail.com 1124 Sergio Belotti 1125 Nokia 1127 Email: sergio.belotti@nokia.com