idnits 2.17.1 draft-zih-ccamp-otn-b100g-fwk-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2017) is 2634 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-izh-ccamp-flexe-fwk-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 Y. Zhang 4 Intended status: Informational ZTE 5 Expires: August 11, 2017 R. Valiveti 6 I. Hussain, Ed. 7 R. Rao 8 Infinera Corp 9 H. Helvoort 10 Hai Gaoming B.V 11 February 7, 2017 13 GMPLS Routing and Signaling Framework for B100G 14 draft-zih-ccamp-otn-b100g-fwk-00 16 Abstract 18 The latest revision of G.709 introduces support for OTU links with 19 rates larger than 100G. This document provides a framework to 20 address the GMPLS routing and signalling extensions that enable GMPLS 21 to setup paths through network that contain these newly introduced 22 OTUCn links. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 11, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview of B100G links in G.709 . . . . . . . . . . . . . . 5 62 3.1. The OTUCn signal . . . . . . . . . . . . . . . . . . . . 5 63 3.1.1. Carrying OTUCn signal between 3R points . . . . . . . 6 64 3.2. The OTUCn-M signal . . . . . . . . . . . . . . . . . . . 9 65 3.3. The ODUCn signal . . . . . . . . . . . . . . . . . . . . 10 66 3.4. OPUCn Time Slot Granularity . . . . . . . . . . . . . . . 10 67 3.5. Structure of OPUCn MSI . . . . . . . . . . . . . . . . . 11 68 3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 12 69 4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.1. 100GE Client Service with a homogeneous chain of OTUC1 71 links . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.2. 100GE Client Service with a mix of OTU4, and OTUC1 links 16 73 4.3. 400GE Client Service with a mix of OTUCn links . . . . . 16 74 4.4. FlexE aware transport over OTUCn links . . . . . . . . . 17 75 4.5. FlexE Client transport over OTUCn links . . . . . . . . . 18 76 4.6. Multihop ODUCn link . . . . . . . . . . . . . . . . . . . 19 77 4.7. Use of OTUCn-M links . . . . . . . . . . . . . . . . . . 20 78 4.8. Intermediate State of ODU mux . . . . . . . . . . . . . . 21 79 5. GMPLS Implications . . . . . . . . . . . . . . . . . . . . . 21 80 5.1. OTN ODUCn layer network . . . . . . . . . . . . . . . . . 21 81 5.2. Implications for GMPLS Signaling . . . . . . . . . . . . 22 82 5.3. Implications for GMPLS Routing . . . . . . . . . . . . . 22 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 9.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 The current GMPLS routing [RFC7138] and signaling extensions 94 [RFC7139] includes coverage for all the OTN capabilities that were 95 defined in the 2012 version of G.709 [ITU-T_G709_2012]. The 2012 96 version of the G.709 included support for the following capabilities: 98 a. Introduction of ODU0 100 b. Mapping of 100BASE-X client (1GE) and other sub-1.25G client 101 signals into ODU0 103 c. Mapping of FC-1200 into ODU2e 105 d. Mappings for 100GBASE-R and 40GBASE-R Ethernet client signals. 107 e. OTU4 layer with a rate of 100G. 109 f. Support for 1.25G tributary slots in OPU2, OPU3, OPU4 -- to fully 110 support the newly introduced ODU0 signal. 112 g. Support for multi-lane interfaces for OTU3, and OTU4 signals 114 The 2016 version of G.709 [ITU-T_G709_2012] introduces support for 115 higher rate OTU signals, termed OTUCn (which have a nominal rate of 116 100n Gbps). The newly introduced OTUCn represent a very powerful 117 extension to the OTN capabilities, and one which naturally scales to 118 transport any newer clients with bit rates in excess of 100G, as they 119 are introduced. 121 This document presents an overview of the changes introduced in 122 [ITU-T_G709_2016] and analyzes them to identify the extensions that 123 would be required in GMPLS routing and signaling to enable the new 124 OTN capabilities. In an OTN network as defined by [ITU-T_G709_2016] 125 and [ITU-T_G798], two layers can be switched at the intermediate 126 nodes: (a) ODU (digital switching), (b) OCh/Optical Tributary Signal 127 (OTSi) (optical switching). This document focuses on the GMPLS 128 extensions that are necessary to support ODU switching in networks 129 that include the beyond 100G OTU links. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 2. Terminology 139 a. OPUCn: Optical Payload Unit -Cn. This signal can be seen as the 140 interleaving of n OPUC "slices". 142 b. ODUCn: Optical Data Unit - Cn. Like the OPUCn, this signal can 143 be seen as the interleaving of n slices of ODUC signals. 145 c. OTUCn: Fully standardized Optical Transport Unit - Cn. This 146 signal can be viewed as being formed as a result of multiplexing 147 n OTUC "slices". An OTUCn has a bandwidth of (approximately) 148 nx100G. An OTUCn signal has n OTUC/ODUC/OPUC overhead instances. 150 d. OTUCn-M: This signal is an extension of the OTUCn signal 151 introduced above. This signal contains the same amount of 152 overhead as the OTUCn signal, but contains a reduced amount of 153 payload area. Specifically the payload area consists of M 5G 154 tributary slots (where M is strictly less than 20*n). 156 e. GMP: Generic Mapping Procedure. This procedure allows a uniform 157 asynchronous mapping procedure for a adapting a client signal to 158 a server layer. This generic mapping procedure computes the 159 population of stuff bytes for all client/server signal rates. 160 Specifically this procedure is used to map client signals into 161 ODU(s), and Low-Order ODUs into High-Order ODUs. 163 f. PSI: OPU Payload structure Indicator. This is a multi-frame 164 message and describes the composition of the OPU signal. This 165 structure includes a field called Payload Type (PT) whose values 166 indicates whether the OPU payload area has been formed by (a) 167 mapping a single non-OTN client (b) multiplexing LO-ODUs. The 168 MSI field is a substructure of the PSI structure, and contains 169 information about the ODU mix contained in a HO-ODU. For 170 mappings of type (b), the following PT codepoints are defined: 172 A. 0x20: indicates 2.5G time slots (with AMP) 174 B. 0x21: indicates 1.25G tributary slots (with GMP). 176 C. 0x22: (introduced in [ITU-T_G709_2016] is used for ODUCn 177 entities, and implies a tributary slot granularity of 5G 178 (with GMP). 180 g. MSI: Multiplex Structure Indicator. This structure indicates the 181 grouping of the tributary slots in an OPU payload area to realize 182 a client signal that is multiplexed into an OPU. The individual 183 clients multiplexed into the OPU payload area are distinguished 184 by the Tributary Port number (TPN). 186 h. FlexO lane: Refers to an electrical/optical lane of a FlexO 187 interface, used to carry OTUC transport signals. 189 i. FlexO group: Refers to the group of m * FlexO interfaces. 191 j. AMP: Asynchronous Mapping Procedure 192 k. BMP: Bitsynchronous Mapping Procedure 194 l. GMP: Generic Mapping Procedure 196 3. Overview of B100G links in G.709 198 3.1. The OTUCn signal 200 In G.709 [ITU-T_G709_2012], the standard mechanism for transporting a 201 client signal is to first map it into an ODU signal (of the 202 appropriate rate), and then switch the resulting ODU signal through 203 the OTN network. In the course of its traversal through the OTN 204 network, the ODU signal generated by the mapper is either (a) 205 multiplexed into higher-order ODU, and then encapsulated to form an 206 OTU or (b) directly encapsulated into an OTU signal that defines the 207 section layer. The option (b), i.e. direct encapsulation into an OTU 208 was possible only for ODU1/ODU2/ODU3/ODU4; ODU signals with other 209 rates (e.g. ODUflex) would first have to be processed per option (a) 210 above. The term "client signal" is generic in the sense that it 211 encompasses both Constant Bit rate (CBR) clients (e.g. 10GBASE-R, 212 SONET OC-768), or packet traffic -- where the goal is to transfer the 213 payload from end-to-end (without regard for bit transparency at the 214 PCS layer). Given that OTU4 was the highest rate section layer 215 signal supported in [ITU-T_G709_2012], the client signal rates were 216 limited to be less than 100G (if ODU-VCAT was not used). 218 With the emergence of client signals with rates greater than 100Gbps 219 (e.g. 200GBASE-R, 400GBASE-R Ethernet), aggregate signals such as 220 FlexE ([OIF_FLEXE_1.0], and the availability of NPUs which can source 221 packet traffic of n*100G, it becomes necessary for the OTN to 222 transport these signals. This means that the OTN must be capable of 223 creating, and switching ODU entities with rates in excess of n*100G. 224 Traditionally, the ITU-T has introduced OTUx/ODUx signals in G.709 as 225 and when new client signals with higher rates are defined by other 226 standards bodies (e.g. IEEE). Rather than follow the traditional 227 trajectory, [ITU-T_G709_2016] takes a general and scalable approach 228 to decoupling the rates of OTU signals from the client rate 229 evolution. The new OTU signal is called OTUCn; this signal is 230 defined to have a rate of (approximately) n*100G. The following are 231 the key characteristics of the OTUCn signal: 233 a. Unlike the signals OTU1..OTU4, the OTUCn signals are not realized 234 by keeping the frame format intact and increasing the frame rate. 236 b. The OTUCn signal contains one ODUCn, which in turn contains one 237 OPUCn signal. The OTUCn and ODUCn signals serve as section layer 238 entities. 240 c. The OTUCn signals can be viewed as formed by interleaving n OTUC 241 signals (where are labeled 1, 2, ..., n), each of which has the 242 format of a standard OTUk signal without the FEC columns (per 243 [ITU-T_G709_2016]:Figure 7-1). The ODUCn, and OPUCn have a 244 similar structure, i.e. they can be seen as being formed by 245 interleaving n instances of ODUC, OPUC signals (respectively) The 246 OTUC signal contains the ODUC, and OPUC signals, just as in the 247 case of fixed rate OTUs defined in G.709 [ITU-T_G709_2016]. 249 d. Each of the OTUC "slices" have the same overhead (OH) as the 250 standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined 251 signal OTUCn has n instances of OTUC OH, ODUC OH, and OPUC OH. 253 e. The OTUC signal has a slightly highly rate compared to the OTU4 254 signal (without FEC); this is to ensure that the OPUC payload 255 area can carry an ODU4 signal. 257 3.1.1. Carrying OTUCn signal between 3R points 259 As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn 260 and OPUCn signal structures are presented in an interface independent 261 manner, by means of n OTUC, ODUC and OPUC instances that are marked 262 #1 to #n. Specifically, the definition of the OTUCn signal does not 263 cover aspects such as FEC, modulation formats, etc. These details 264 are defined as part of the adaptation of the OTUCn layer to the 265 optical layer(s). The specific interleaving of OTUC/ODUC/OPUC 266 signals onto the optical signals is interface specific and specified 267 for OTN interfaces with standardized application codes in the 268 interface specific recommendations (G.709.x). 270 The original working assumption was that the first B100G inter-domain 271 interface for an OTUC4 would use the optical modules developed for 272 the 400GbE signal. This assumption has been revised as a result of 273 new insights into how the notions developed for FlexE can be applied 274 to the OTN domain. The new developments make it possible to support 275 OTUC4 signals without having to wait for the 400GbE optical modules. 276 The main motivation for developing the interoperable FlexO interfaces 277 is to (a) reuse already existing optical modules developed for 278 carrying Ethernet signals and (b) realize higher rate OTUCn 279 interfaces by bonding the required number of available PHY(s) -- 280 thereby decoupling the rates of OTUCn interfaces from the rates of 281 the available Ethernet PHY(s) . The FlexO layer can be viewed as an 282 encapsulation layer for the OTUCn signal. 284 Recommendation [ITU-T_G709.1] specifies a flexible interoperable 285 short-reach OTN interface over which an OTUCn (n >=1) is transferred, 286 using bonded FlexO interfaces which belong to a FlexO group. 287 Conceptually, the FlexO can be seen as the adaptation of the idea of 288 FlexE [OIF_FLEXE_1.0] to OTN signals. Like the FlexE group, the 289 FlexO group supports physical interface bonding, the management of 290 the group members, overhead for communication between FlexO peers 291 etc. (these overheads are separate from the GCC0 channel defined over 292 OTUCn). In its current form, Recommendation [ITU-T_G709.1] is 293 limited to the case of transporting OTUCn signals using n 100G 294 Ethernet PHY(s). When the PHY(s) for the emerging set of Ethernet 295 signals, e.g. 200GbE and 400GbE, become available, new 296 recommendations can define the required adaptations. 298 The (high-level) sequence of steps performed at the FlexO/OTUCn 299 adaptation source are the following: 301 a. one OTUCn is split into n instances of OTUC at the FlexO source 302 node. 304 b. One or more OTUC instances are associated with one FlexO 305 interface (which could have a rate of p*100G. As of this 306 document's writing, Ethernet PHY(s) exist for transporting 307 100GBASE-R signals (i.e. p=1). This is the basis for the FlexO 308 interface specified in [ITU-T_G709.1]. For this specific 309 instance, the mapping between OTUC, and the FlexO interface is 310 1:1, and the mapping is illustrated in Figure 1. Figure 2 311 illustrates the scenario in which OTUCn transport makes use of 312 200GbE PHY(s). 314 c. The contents of the selected subset of OTUC signals are mapped to 315 FlexO frames directed at one of the FlexO interfaces in the FlexO 316 group. 318 d. Alignment markers are added to these FlexO frames so that the 319 resulting stream can be transported across multiple physical/ 320 electrical lanes. The standard IEEE FEC used in conjuction with 321 the appropriate Ethernet signal(e.g. 100GbE, or 200GbE) is also 322 added to the frames. 324 The sink performs the reverse sequence of operations and reconstructs 325 the OTUCn signal. As a result of the direct encapsulation of the 326 OTUCn signal into the FlexO layer, full transparency for the OTUCn 327 layer is guaranteed. Once the OTUCn signal is transported between 3R 328 regeneration points, all B100G capabilities -- such as the support 329 for ODUs with rates higher than 100G, and client signals larger than 330 100G are enabled. 332 ================================================================== 334 +----------------------------------+ 335 | OTUCn | OTUCn signal 336 +----------------------------------+ 337 | | | 338 | | .... | 339 +-------+ +-------+ +-------+ n X OTUC instances 340 | OTUC | | OTUC | | OTUC | 341 +-------+ +-------+ +-------+ 342 | | | 343 | | | 344 +-------+ +-------+ +-------+ n FlexO interfaces 345 | FlexO | | FlexO | | FlexO | 346 | Frame | | Frame | | Frame | 347 +-------+ +-------+ +-------+ 348 | | | 349 +----------------------------------------> Electrical lanes 350 | | | 351 | | | 352 +-------+ +-------+ +-------+ n 100GbE Eth PHY(s) 353 | 100GE | | 100GE | | 100GE | 354 | PHY | | PHY | | PHY | 355 +-------+ +-------+ +-------+ 357 ================================================================== 359 Figure 1: OTUCn transport using 100GbE PHY(s) 361 ================================================================== 363 +----------------------------------+ 364 | OTUCn | OTUCn signal 365 +---+-----------+--------------+---+ 366 | | | 367 | | .... | 368 +---+---+ +---+---+ +---+---+ n X OTUC instances 369 | OTUCx2| | OTUCx2| | OTUCx2| n/2 groups, 2 OTUC/group 370 +---+---+ +---+---+ +---+---+ 371 | | | 372 | | | 373 +---+---+ +---+---+ +---+---+ n/2 FlexO interfaces 374 | FlexO | | FlexO | | FlexO | 375 | Frame | | Frame | | Frame | 376 +---+---+ +---+---+ +---+---+ 377 | | | 378 +----------------------------------------> Electrical lanes 379 | | | 380 | | | 381 +---+---+ +---+---+ +---+---+ n/2 200GbE Eth PHY(s) 382 | 200GE | | 200GE | | 200GE | 383 | PHY | | PHY | | PHY | 384 +-------+ +-------+ +-------+ 386 ================================================================== 388 Figure 2: OTUCn transport with 200G PHY(s) 390 3.2. The OTUCn-M signal 392 The standard OTUCn signal has the same rate as that of the ODUCn 393 signal as captured in Table 1. This implies that the OTUCn signal 394 can only be transported over wavelengths which have a capacity of 395 multiples of (approximately) 100G. Modern DSPs support a variety of 396 bit rates per wavelength, depending on the reach requirements for the 397 optical link. With this in mind, ITU-T supports the notion of a 398 reduced rate OTUCn signal, termed the OTUCn-M. The OTUCn-M signal is 399 derived from the OTUCn signal by retaining all the n slices of 400 overhead (one per OTUC slice) and trimming the OPUC tributary slots 401 marked as "unavailable". This operation is equivalent to that 402 referred to as "crunching" in the context of FlexE PHY(s). 404 3.3. The ODUCn signal 406 The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by 407 the appropriate interleaving of content from n ODUC frames. The ODUC 408 frames have the same structure as a standard ODU -- in the sense that 409 it has the same Overhead (OH), and the payload area -- but has a 410 higher rate since its payload area can embed an ODU4 signal. The 411 ODUCn is meant to be used as a high-order signal only -- implying 412 that only other lower-rate (i.e. low-order) ODUs can be multiplexed 413 into an ODUCn signal; in other words, no client signals can be 414 directly mapped to an ODUCn signal. The ODUCn signals have a rate 415 that is captured in Table 1. 417 +----------+---------------------------------+ 418 | ODU Type | ODU Bit Rate | 419 +----------+---------------------------------+ 420 | ODUCn | n x 239/226 x 99,532,800 kbit/s | 421 +----------+---------------------------------+ 423 Not all values of 'n' may be standardized by ITU-T-T. 425 Table 1: ODUCn rates 427 The ODUCn is a higher-order ODU signal, and is encapsulated into an 428 OTUCn signal which occupies the section layer. In most common 429 scenarios, the ODUCn, and OTUCn signals will be co-terminous, i.e. 430 they will have identical source/sink locations. [ITU-T_G709_2016] 431 and [ITU-T_G872] allow for the ODUCn signal to pass through a digital 432 regenerator node which will terminate the OTUCn layer, but will pass 433 the regenerated (but otherwise untouched) ODUCn towards a different 434 OTUCn interface where a fresh OTUCn layer will be initiated. 435 Specifically, the OPUCn signal flows through these regenerators 436 unchanged. That is, the set of client signals, their TPNs, trib-slot 437 allocation remains unchanged. Note however that the ODUCn Overhead 438 (OH) might be modified if TCM sub-layers are instantiated in order to 439 monitor the performance of the repeater hops. In this sense, the 440 ODUCn should not be seen as a general, switchable ODU. 442 3.4. OPUCn Time Slot Granularity 444 [ITU-T_G709_2012] introduced the support for 1.25G granular tributary 445 slots in OPU2, OPU3, and OPU4 signals. With the introduction of 446 higher rate signals such as the OPUCn (which are formed by 447 interleaving n OPUC signals), it is no longer practical for the 448 optical networks (and the datapath hardware) to support a very large 449 number of flows at such a fine granularity. ITU-T has defined the 450 OPUC with a tributary slot granularity of 5G. This choice is 451 motivated by the following reasons: 453 a. Low bitrate flows will usually be aggregated into higher-order 454 ODUs before they are transported over the core of the transport 455 network, and as a consequence, the network is not expected to see 456 a large number of small bitrate flows such as ODU0. 458 b. The IEEE is planning to define new MAC rates such as 25Gbps. The 459 choice of 5G TS for OPUC nicely accomodates 25GE clients, without 460 wasting a large amount of bandwidth 462 c. The OIF FlexE Implementation agreement also defines the FlexE PHY 463 calendar slots to have a bandwidth of 5G; the OPUC granularity 464 perfectly matches the capacity of the finest FlexE client. 466 3.5. Structure of OPUCn MSI 468 An OPUCn signal can be viewed as being formed from an interleaving of 469 n OPUC signals. Each of the OPUC "slices" has a format that is very 470 similar to that OPU4 -- albeit with a slightly higher rate (since an 471 ODU4 can be fully embedded in the payload area of the OPUC signal). 472 As mentioned above, the OPUC signal has 20 tributary slots, each with 473 a bandwidth of 5G. The PSI structure for an OPUCn signal can be 474 viewed as the concatenation of n PSI structures (one per OPUC). The 475 PSI structure of an OPUC includes the following fields: 477 a. the Payload Type (PT) - 1byte - with a value of 0x22. This 478 indicates that ODUC has been formed by multiplexing zero or more 479 low-order ODUs into OPUC. 481 b. Reserved Field - 1 byte. In ODUs other than ODUC (e.g. 482 ODU0/1/2/3/4/flex), this byte carries the "Client Signal Failure 483 Indication". This field is unused in the case of ODUC entities 484 since no non-OTN client signal is directly mapped to these server 485 layers. 487 c. The MSI field (of size 40 bytes) which contains the information 488 about 20 tributary slots; each such information structure 489 occupies 2 bytes and has the following format 490 (G.709:Section 20.4.1 [ITU-T_G709_2016]): 492 +----------+--------------------------------------------------------+ 493 | Bit | Description | 494 | Position | | 495 | # (Bit | | 496 | 1= MSB; | | 497 | Bit 16 = | | 498 | LSB) | | 499 +----------+--------------------------------------------------------+ 500 | 1 | The TS availability bit 1 indicates if the tributary | 501 | | slot is available or unavailable | 502 | 9 | The TS occupation bit 9 indicates if the tributary | 503 | | slot is allocated or unallocated | 504 | 2-8, | The tributary port number (TPN) of the client signal | 505 | 10-16 | that is being transported in this TS. A given client | 506 | | uses the same TPN value in all the TS(s) that are | 507 | | being used to transport the client signal. ODTUCn.ts | 508 | | tributary ports are numbered 1 to 10n. The current | 509 | | 14-bit field for the TPN will allow the index 'n' to | 510 | | grow as large as 1638 -- which is sufficient for all | 511 | | conceivable OTUCn links. | 512 +----------+--------------------------------------------------------+ 514 Table 2: OPUC MSI information (for each tributary slot 516 3.6. Client Signal Mappings 518 Note that [ITU-T_G709_2016] introduces support for OTUCn signals with 519 rates of n*100G and also introduces support for client signals with 520 rates larger than 100G (e.g. the future 400GBASE-R client being 521 standardized by IEEE, higher packet streams from NPUs). The approach 522 taken by the ITU-T to map non-OTN client signals to the appropriate 523 ODU containers is as follows: 525 a. All client signals with rates less than 100G are mapped as 526 specified in [ITU-T_G709_2016]:Clause 17. These mappings are 527 identical to those specified in the earlier revision of G.709 528 [ITU-T_G709_2012]. Thus, for example, the 1000BASE-X/10GBASE-R 529 signals are mapped to ODU0/ODU2e respectively (see Table 3 -- 530 based on Table 7-2 in [ITU-T_G709_2016]) 532 b. Always map the new and emerging client signals to ODUflex signals 533 of the appropriate rates (see Table 3 -- based on Table 7-2 in 534 [ITU-T_G709_2016]) 536 c. Drop support for ODU Virtual Concatenation. This simplifies the 537 network, and the supporting hardware since multiple different 538 mappings for the same client are no longer necessary. 540 d. ODUflex signals are low-order signals only. If the ODUflex 541 entities have rates of 100G or less, they can be transported 542 using either an ODUk (k=1..4) or an ODUCn server layer. On the 543 other hand, ODUflex connections with rates greater than 100G will 544 require the server layer to be ODUCn. The ODUCn signals must be 545 adapted to an OTUCn signal. Figure 3 illstrates the hierarchy of 546 the digital signals defined in G.709; this figure does not 547 illustrate the handed off to the optical layers. 549 +----------------+--------------------------------------------------+ 550 | ODU Type | ODU Bit Rate | 551 +----------------+--------------------------------------------------+ 552 | ODU0 | 1,244,160 Kbps | 553 | ODU1 | 239/238 x 2,488,320 Kbps | 554 | ODU2 | 239/237 x 9,953,280 Kbps | 555 | ODU2e | 239/237 x 10,312,500 Kbps | 556 | ODU3 | 239/236 x 39,813,120 Kbps | 557 | ODU4 | 239/227 x 99,532,800 Kbps | 558 | ODUflex for | 239/238 x Client signal Bit rate | 559 | CBR client | | 560 | signals | | 561 | ODUflex for | Configured bit rate | 562 | GFP-F mapped | | 563 | packet traffic | | 564 | ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= | 565 | IMP mapped | 1 | 566 | packet traffic | | 567 | ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is | 568 | FlexE aware | total number of available tributary slots among | 569 | transport | all PHYs which have been crunched and combined. | 570 +----------------+--------------------------------------------------+ 572 Note that this table doesn't include ODUCn -- since it cannot be 573 generated by mapping a non-OTN signal. An ODUCn is always formed by 574 multiplexing multiple LO-ODUs. 576 Table 3: Types and rates of ODUs usable for client mappings 578 ================================================================== 580 Clients (e.g. SONET/SDH, Ethernet) 581 + + + 582 | | | 583 +------------------+-------+------+------------------------+ 584 | OPUk | 585 +----------------------------------------------------------+ 586 | ODUk | 587 +-----------------------+---------------------------+------+ 588 | OTUk, OTUk.V, OTUkV | OPUk | | 589 +----------+----------------------------------------+ | 590 | OTLk.n | | ODUk | | 591 +----------+ +---------------------+-----+ | 592 | OTUk, OTUk.V, OTUkV | OPUCn | 593 +----------+-----------------------+ 594 | OTLk.n | | ODUCn | 595 +----------+ +------------+ 596 | OTUCn | 597 +------------+ 599 ================================================================== 601 Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 603 4. Usecases 605 This section introduces various usecases, in increasing order of 606 complexity. This material serves as background information that 607 provides the rationale for the requirements that any solution must 608 satisfy. At a later point in time, it is possible to consolidate 609 these usecases so that all the multiplexing (and demultiplexing) 610 variants are encountered along the path of an end-to-end ODU circuit. 612 Note: These usecases present scenarios in which OTUCn links are 613 depicted. These illustrations do not highlight how the OTUCn is 614 transported between the 3R points. That is, these usecases cover 615 cases in which a standard FlexO interface (e.g. as defined in 616 [ITU-T_G709.1]) is used, or whether a vendor specific mapping of 617 OTUCn to OTSiG (as defined in [ITU-T_G872]) is used. In other words, 618 multiple variants of these usecases based on FlexO usage (or not) are 619 not included in this document. 621 4.1. 100GE Client Service with a homogeneous chain of OTUC1 links 623 In the scenario illustrated in Figure 4 a 100GBASE-R client is mapped 624 into an ODU4 at NE1. The resulting ODU4 signal is multiplexed into 625 the ODUC1 server layer (using GMP) and further encapsulated to form 626 the OTUC1 signal. The links NE1-NE2, and NE2-NE3 are both OTUC1 627 links -- and they can carry one 100GE client mapped into an ODU4 628 server layer. Actions performed at NE2 are: (a) terminate OTUC1, and 629 ODUC1 towards NE1 (b) demultiplex the ODU4 signal from ODUC1 (c) map 630 the ODU4 signal onto a different ODUC1/OTUC1 towards NE3. NE3 631 performs the inverse sequence of steps performed at NE1, and recovers 632 the 100GBASE-R client from the ODU4 signal. Note that the ODU4 and 633 ODUC1 signals are not "interoperable" and that the ODUC1 is a server 634 layer to the ODU4 signal. 636 This illustration is also applicable to the usecase in which members 637 of a FlexE group are transported in a flexe-unaware mode in the 638 transport network. Although this illustration included only OTUC1 639 signals, any higher rate OTUCn signal can be substituted for these 640 signals. In this particular scenario, there are two adjacent ODUC1 641 hops, and the NE2 demultiplexs (and multiplexes) the ODU4 onto the 642 ODUC1. It is possible to construct an alternative scenario in the 643 case when NE2 acts as a regenerator, and doesn't terminate the ODUC1 644 signals in the two hops, and instead repeats the ODUC1 signal; this 645 scenario is specifically discussed in Section 4.6. 647 ================================================================== 649 +----------+ +----------+ 650 | 100GE | | 100GE | 651 +----------+ +---------------+ +----------+ 652 | ODU4 | | ODU4 | | ODU4 | 653 +----------+ +---------------+ +----------+ 654 | ODUC1 | | ODUC1 | ODUC1 | | ODUC1 | 655 +----------+ +---------------+ +----------+ 656 | OTUC1 +--------+ OTUC1 | OTUC1 +---------+ OTUC1 | 657 +----------+ +---------------+ +----------+ 658 NE1 NE2 NE3 660 +-------------> +-------------> 661 Scope of Scope of 662 OTUC1, ODUC1 OTUC1, ODUC1 664 ================================================================== 666 Figure 4: 100GE Client service 668 4.2. 100GE Client Service with a mix of OTU4, and OTUC1 links 670 In the scenario illustrated in Figure 5 a 100GBASE-R client is mapped 671 into an ODU4 at NE1. The resulting ODU4 signal is encapsulated with 672 an OTU layer to form the OTU4 signal. Actions performed at NE2 are: 673 (a) terminate OTU4 layer, and extract the ODU4 signal (b) map the 674 ODU4 signal onto a different ODUC1/OTUC1 towards NE3. NE3 performs 675 the same set of actions that were performed by NE3 in Figure 4. 677 ================================================================== 679 +----------+ +----------+ 680 | 100GE | | 100GE | 681 +----------+ +---------------+ +----------+ 682 | ODU4 | | ODU4 | | ODU4 | 683 +----------+ +-------+-------+ +----------+ 684 | OTU4 +--------+ OTU4 | ODUC1 | | ODUC1 | 685 +----------+ +---------------+ +----------+ 686 | OTUC1 +---------+ OTUC1 | 687 --------+ +----------+ 688 NE1 NE2 NE3 690 +--------------> +----------------> 691 Scope of Scope of 692 OTU4 layer OTUC1, ODUC1 694 ================================================================== 696 Figure 5: 100GE Client Service with a mix of OTU4, and OTUC1 links 698 4.3. 400GE Client Service with a mix of OTUCn links 700 In the scenario illustrated in Figure 6 a 400GBASE-R client is mapped 701 into an ODUflex at NE1. The resulting ODUflex signal is multiplexed 702 into an ODUC4 (using GMP), and then transformed into an OTUC4 signal. 703 The links between NE1-NE2, and NE2-NE3 are OTUC4 and OTUC6 704 (respectively). Actions performed at NE2 are: (a) terminate OTUC4, 705 and ODUC4 towards NE1 (b) demultiplex the ODUflex signal from ODUC4 706 (c) map the ODU4 signal onto ODUC6/OTUC6 towards NE3. NE3 performs 707 the inverse sequence of steps performed at NE1, and recovers the 708 400GBASE-R client from the ODUflex signal. 710 Although not specifically illustrated in this figure, the 200G of 711 spare capacity in the NE2-NE3 links can be used to carry other client 712 signals.. Although the scenario illustrated in Figure 6 is specific 713 to 400GE, the treatment for packet clients at other rates (e.g. 25G, 714 50G, 200G) follows a very similar processing sequence. In the case 715 of 25GBASE-R clients , the 25GE client signal will be mapped to an 716 ODUflex, and can be multiplexed into an ODU4 signal, or an ODUCn 717 signal as illustrated here. 719 ================================================================== 721 +----------+ +----------+ 722 | 400GE | | 400GE | 723 +----------+ +---------------+ +----------+ 724 | ODUflex | | ODUflex | | ODUflex | 725 +----------+ +-------+-------+ +----------+ 726 | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | 727 +----------+ +---------------+ +----------+ 728 | OTUC4 +--------+ OTUC4 | OTUC6 +---------+ OTUC6 | 729 +----------+ +-------+-------+ +----------+ 730 NE1 NE2 NE3 732 <-------------> <-------------> 733 Scope of Scope of 734 OTUC4, ODUC4 OTUC6, ODUC6 736 ================================================================== 738 Figure 6: 400GE transport over OTUCn links 740 4.4. FlexE aware transport over OTUCn links 742 In the scenario illustrated in Figure 7 NE1 interfaces to a client 743 equipment which includes the FlexE SHIM functions which originate/ 744 terminate a FlexE group. The transport network edge node NE2 is 745 FlexE aware -- but doesn't terminate the FlexE group. NE1 may (as 746 defined in the FlexE draft [I-D.izh-ccamp-flexe-fwk]), crunch the 747 unavailable tributary slots in the FlexE PHY signals, and map the 748 resultant stream to one or more ODUflex signals. The links between 749 NE1-NE2, and NE2-NE3 are OTUC4 and OTUC6 (respectively). Actions 750 performed at NE2 are: (a) terminate OTUC4, and ODUC4 towards NE1 (b) 751 demultiplex the ODUflex signal from ODUC4 (c) map the ODUflex signal 752 onto ODUC6/OTUC6 towards NE3. NE3 recovers the Crunched and combined 753 PHY(s) from the ODUflex signal, re-adds the unavailable calendar 754 slots, and outputs the resulting stream towards the FlexE PHY(s). 756 In the scenario illustrated in Figure 7 the lowest rate OTUCn link is 757 the OTUC4 link between NE1-NE2. This means that the size of the 758 FlexE group is at most 4. FlexE groups with greater sizes can be 759 handled by utilizing appropriate OTUCn links. Note that at most 400G 760 of the capacity of OTUC6 (or 600G) NE2-NE3 link is occupied by the 761 ODUflex signal; the remaining bandwidth can be allocated to other 762 client signals. 764 ================================================================== 766 FlexE +----------+ +----------+ FlexE 767 group | Crunched | | Crunche | Group 768 +------> and | | and +--------> 769 | Combined | | Combined | Add 770 | PHY(s) | | PHY(s) | unavailable 771 +----------+ +---------------+ +----------+ Calendar 772 | ODUflex | | ODUflex | | ODUflex | slots 773 +----------+ +-------+-------+ +----------+ 774 | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | 775 +----------+ +---------------+ +----------+ 776 | OTUC4 +---+ OTUC4 | OTUC6 +---+ OTUC6 | 777 +----------+ +-------+-------+ +----------+ 778 NE1 NE2 NE3 780 <---------> <-----------> 781 Scope of Scope of 782 OTUC4, ODUC4 OTUC6, ODUC6 784 ================================================================== 786 Figure 7: FlexE aware transport over OTUCn links 788 4.5. FlexE Client transport over OTUCn links 790 This use case (see Figure 8) concerns the scenario in which a FlexE 791 group is terminated at the transport network edge node (via the FlexE 792 SHIM function), and the FlexE clients are demultiplexed, and 793 independently transported through the OTN network. In the scenario 794 illustrated in Figure 8 the lowest rate OTUCn link is the OTUC4 link 795 between NE1-NE2. This means that the maximum bit rate of the FlexE 796 client is at most 400G. FlexE clients with greater sizes can be 797 handled by utilizing appropriate OTUCn links. This figure 798 illustrates the case in which one FlexE client is transported between 799 NE1 and NE3. Other FlexE clients recovered at NE1 can routed 800 independently to NE3, or to other network elements. 802 ================================================================== 804 +-----------------+ +---------------+ 805 | FlexE | | FlexE | 806 | Client | | Client | 807 +-----------------+ +---------------+ 808 | FlexE | | +---------------+ | | Flex | 809 | SHIM | ODUflex | | ODUflex | |ODUflex| SHIM | 810 +-----------------+ +---------------+ +---------------+ 811 | FlexE | ODUC4 | | ODUC4 | ODUC6 | | ODUC6 | FlexE | 812 +----+ PHY(s +---------+ +---------------+ +-------+ PHY(s)+----> 813 FlexE | | OTUC4 +---+ OTUC4 | OTUC6 +---+ OTUC6 | | FlexE 814 Group +-----------------+ +---------------+ +---------------+ Group 815 NE1 NE2 NE3 817 <------------> <-----------> 818 Scope of Scope of 819 OTUC4, ODUC4 OTUC6, ODUC6 821 ================================================================== 823 Figure 8: FlexE client transport over OTUCn links 825 4.6. Multihop ODUCn link 827 As mentioned in the introductory section, the ODUCn is not a 828 switchable entity. The ODUCn layer is a server layer, which more-or- 829 less occupies the position of a section layer in OTN networks. As 830 such, the ODUCn signal must be terminated and the contained low-order 831 ODU flows can be switched independently to other OTN interfaces. 832 G.709 and G.872 however allow for digital regenerators to terminate 833 the OTUCn layer, and reinject the ODUCn layer towards another 834 interface (where a new OTUCn section layer is started). This 835 scenario is illustrated in Figure 9. In this figure, NE3 is the 836 regenerator. The ODUC2 signal is terminated at NE2, and NE4. At the 837 regeneration points, all the clients embedded inside the ODUCn signal 838 are not touched (i.e. no TS changes can occur). More specifically, 839 the OPUC2 signal is not modified in any way. However, the ODUC2 OH 840 may be modified if intrusive TCM monitoring points are applied to the 841 ODUC2 signal at NE3. It is for this reason that the ODUC2 entity 842 must be visible at NE3. 844 In scenarios involving multi-hop ODUCn links, GMPLS signalling will 845 be required to first establish the ODUCn LSP, and then use it as an 846 FA-LSP to switch any contained Low-order ODUs. 848 ================================================================== 850 +----------+ +----------+ 851 | 100GE | | 100GE | 852 +----------+ +---------------+ +----------+ 853 | ODU4 | | ODU4 | | ODU4 | 854 +----------+ +-------+-------+ +---------+ +----------+ 855 | ODUC1 | | ODUC1 | ODUC2 | | ODUC2 | | ODUC2 | 856 +----------+ +---------------+ +---------+ +----------+ 857 | OTUC1 +-----+ OTUC1 | OTUC2 +-------+ OTUC2 +-------+ OTUC2 | 858 +----------+ +-------+-------+ +---------+ +----------+ 859 NE1 NE2 NE3 NE4 861 <-------------> <-------------> <-------------> 862 Scope of OTUC2 OTUC2 863 OTUC1, ODUC1 865 <---------------------------------> 866 ODUC2 868 ================================================================== 870 Figure 9: Multihop ODUCn link 872 4.7. Use of OTUCn-M links 874 The scenario illustrated in Figure 10 is a variant of the basic 875 usecase presented in Figure 4. The only difference is that the 876 second hop of the ODU4 connection makes use of a OTUC2-30 link which 877 has a capacity of 150G. 879 ================================================================== 881 +----------+ +-----------+ 882 | 100GE | | 100GE | 883 +----------+ +------------------+ +-----------+ 884 | ODU4 | | ODU4 | | ODU4 | 885 +----------+ +-------+----------+ +-----------+ 886 | ODUC1 | | ODUC1 | ODUC2 | | ODUC2 | 887 +----------+ +------------------+ +-----------+ 888 | OTUC1 +--------+ OTUC1 | OTUC2-30 +------+ OTUC2-30 | 889 +----------+ +-------+----------+ +-----------+ 890 NE1 NE2 NE3 892 +-------------> +-------------> 893 Scope of Scope of 894 OTUC1, ODUC1 OTUC2-30 895 ODUC2 897 ================================================================== 899 Figure 10: 100GE Client service over OTUCn-M links 901 4.8. Intermediate State of ODU mux 903 The ODUCn links have a tributary slot granularity of 5G -- and this 904 makes it a bit inefficient if a small number of ODU0 flows have to be 905 switched across an ODUCn links. In these cases, it is conceivable 906 that the intermediate nodes may offer the convenience of a 907 intermediate-stage multiplexing, whereby multiple ODU0 flows are 908 first multiplexed into a higher rate container (e.g. ODU2), and then 909 multiplexed into an ODUCn signal. This however assumes that all 910 these ODU0 flows are co-routed in the network. If this assumption 911 cannot be made, the only solution is to multiplex these ODU0 flows 912 into higher rate flows, from the source of the traffic. This usecase 913 isn't elaborated in this document. We can add details if required. 915 5. GMPLS Implications 917 5.1. OTN ODUCn layer network 919 As described in the overview section, ODUCn can not be used to 920 support non-OTN client signal, so the mapping hierarchy would be the 921 OTN client signals (e.g. ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, 922 ODUflex) are first multiplexed into an ODUCn container, then the 923 ODUCn container is then mapped into OTUCn (see Figure 3). The signal 924 hierarchy supported by the ODUCn and OTUCn layers needs to be taken 925 into consideration in control plane Routing and Signaling. 927 5.2. Implications for GMPLS Signaling 929 As described in Section 3 [ITU-T_G709_2016] introduced some new 930 containers, such as OPUCn, ODUCn, and OTUCn. The GMPLS signaling 931 mechanisms defined in [RFC4328] and [RFC7139] do not support these 932 new OTN features. Therefore, GMPLS signaling protocol extensions 933 will be necessary to support this new functionality. The following 934 summarizes key aspects that should be considered for GMPLS signaling 935 extensions: 937 a. The GMPLS signalling protocol SHALL be able to specify the new 938 ODUCn/OTUCn signal types and related traffic information. The 939 traffic parameters should be extended in a signalling message to 940 support the new ODUCn/OTUCn signal types 942 b. The GMPLS signalling protocol SHALL be able to set up ODUCn/OTUCn 943 LSP with related mapping and multiplexing capabilities, and 944 allocate slot resources for ODU clients signal. [Note: Under 945 Discussion] 947 c. The GMPLS signalling protocol SHALL be able to set up LSP using 948 5G TS granularity 950 d. The GMPLS signalling protocol SHALL support the TPN allocation 951 and negotiation 953 e. The GMPLS signalling protocol SHALL support the setup of OTUCn 954 sub rates (OTUCn-M) LSP, which includes the negotiation of 955 unavaliable slots number, slots postion and allocation of slot 956 resources. [Note: Under Discussion] 958 f. The GMPLS signalling protocol SHALL be able to set up 959 ODUCn/OTUCn/OTUCn-M LSP over FlexO group. [Note: Under 960 Discussion] 962 g. The GMPLS signalling protocol SHALL be able to set up 963 ODUCn/OTUCn/OTUCn-M LSP over different kinds of FlexO interfaces 964 (e.g., 100G/200G FlexO interfaces) [Note: Under Discussion] 966 5.3. Implications for GMPLS Routing 968 The path computation process needs to select a suitable route and 969 capabilities for an ODUCn/OTUCn/OTUCn-M connection request. In order 970 to perform the path computation, it needs to evaluate the available 971 bandwidth/slots available on one or more candidate links. The 972 routing protocol should be extended to convey sufficient information 973 to represent ODU Traffic Engineering (TE) topology. Following GMPLS 974 Routing Implications should be considered: 976 a. The GMPLS Routing protocol should be able to indicate the 977 ODUCn/OTUCn/OTUCn subrates (OTUCn-M) support information 979 b. The GMPLS Routing protocol SHALL support the advertisement of 5G 980 Tributary Slot Granularity 982 c. The GMPLS Routing protocol SHALL support the advertisement of 983 unused ODUCn tributary slot resource information. 985 d. The GMPLS Routing protocol SHALL support the advertisement of 986 available/unavailable tributary slot information in OTUCn-M 987 scenario 989 e. The GMPLS Routing protocol SHALL support the advertisement of 990 OTUCn implementation (FlexO) specific information, including the 991 specific Flexible OTN interface support information [Note: Under 992 Discussion] 994 6. Acknowledgements 996 7. IANA Considerations 998 This memo includes no request to IANA. 1000 8. Security Considerations 1002 None. 1004 9. References 1006 9.1. Normative References 1008 [ITU-T_G709.1] 1009 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 1010 2016", , 2016. 1012 [ITU-T_G709_2012] 1013 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 1014 02/2012", 1015 http://www.itu.int/rec/T-REC-G..709-201202-S/en, February 1016 2012. 1018 [ITU-T_G709_2016] 1019 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 1020 07/2016", 1021 http://www.itu.int/rec/T-REC-G..709-201606-P/en, July 1022 2016. 1024 [ITU-T_G798] 1025 ITU-T, "ITU-T G.798: Characteristics of optical transport 1026 network hierarchy equipment functional blocks; 02/2014", 1027 http://www.itu.int/rec/T-REC-G.798-201212-I/en, February 1028 2014. 1030 [ITU-T_G872] 1031 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 1032 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 1033 January 2017. 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, 1037 DOI 10.17487/RFC2119, March 1997, 1038 . 1040 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 1041 Switching (GMPLS) Signaling Extensions for G.709 Optical 1042 Transport Networks Control", RFC 4328, 1043 DOI 10.17487/RFC4328, January 2006, 1044 . 1046 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 1047 J. Drake, "Traffic Engineering Extensions to OSPF for 1048 GMPLS Control of Evolving G.709 Optical Transport 1049 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 1050 . 1052 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1053 and K. Pithewan, "GMPLS Signaling Extensions for Control 1054 of Evolving G.709 Optical Transport Networks", RFC 7139, 1055 DOI 10.17487/RFC7139, March 2014, 1056 . 1058 9.2. Informative References 1060 [I-D.izh-ccamp-flexe-fwk] 1061 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 1062 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 1063 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 1064 Zhong, "GMPLS Routing and Signaling Framework for Flexible 1065 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 1066 progress), October 2016. 1068 [OIF_FLEXE_1.0] 1069 OIF, "FLex Ethernet Implementation Agreement Version 1.0 1070 (OIF-FLEXE-01.0)", March 2016. 1072 Authors' Addresses 1074 Qilei Wang (editor) 1075 ZTE 1076 Nanjing 1077 CN 1079 Email: wang.qilei@zte.com.cn 1081 Yuanbin Zhang 1082 ZTE 1083 Beijing 1084 CN 1086 Email: zhang.yuanbin@zte.com.cn 1088 Radha Valiveti 1089 Infinera Corp 1090 Sunnyvale 1091 USA 1093 Email: rvaliveti@infinera.com 1095 Iftekhar Hussain (editor) 1096 Infinera Corp 1097 Sunnyvale 1098 USA 1100 Email: IHussain@infinera.com 1101 Rajan Rao 1102 Infinera Corp 1103 Sunnyvale 1104 USA 1106 Email: rrao@infinera.com 1108 Huub van Helvoort 1109 Hai Gaoming B.V 1111 Email: huubatwork@gmail.com