idnits 2.17.1 draft-merge-ccamp-gmpls-otn-b100g-applicability-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 : ---------------------------------------------------------------------------- ** There are 19 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4328' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'I-D.izh-ccamp-flexe-fwk' is defined on line 734, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-izh-ccamp-flexe-fwk-00 Summary: 1 error (**), 0 flaws (~~), 5 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, 2019 Infinera Corp 6 H. Zheng, Ed. 7 Huawei 8 H. Helvoort 9 Hai Gaoming B.V 10 S. Belotti 11 Nokia 12 July 2, 2018 14 Applicability of GMPLS for B100G Optical Transport Network 15 draft-merge-ccamp-gmpls-otn-b100g-applicability-00 17 Abstract 19 This document examines the applicability of using current existing 20 GMPLS routing and signaling to set up ODUk/ODUflex over ODUCn link, 21 as a result of the support of OTU/ODU links with rates larger than 22 100G in the 2016 version of G.709. 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 https://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 January 3, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 (https://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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. OTN terminology used in this document . . . . . . . . . . 3 63 3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4 64 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.1. Carrying OTUCn between 3R points . . . . . . . . . . 5 66 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Time Slot Granularity . . . . . . . . . . . . . . . . . . 8 69 3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8 70 3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 8 71 4. Applicability and GMPLS Implications . . . . . . . . . . . . 10 72 4.1. Applicability and Challenges . . . . . . . . . . . . . . 10 73 4.2. GMPLS Implications and Applicability . . . . . . . . . . 12 74 4.2.1. Implications and Applicability for GMPLS Signalling . 12 75 4.2.2. Implications and Applicability for GMPLS Routing . . 13 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 14 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 10.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 The current GMPLS routing [RFC7138] and signaling extensions 89 [RFC7139] only includes coverage for the control of all the OTN 90 capabilities that were defined in the 2012 version of G.709 91 [ITU-T_G709_2012]. 93 While the 2016 version of G.709 [ITU-T_G709_2016] introduces support 94 for new higher rate ODU signals, termed ODUCn (which have a nominal 95 rate of n x 100 Gbps), how to use GMPLS to configure ODUCn should be 96 taken into consideration. But it seems how to configure the ODUCn 97 link needs more discussion, so this draft mainly focuses on the use 98 of current GMPLS mechanisms to set up ODUk/ODUflex over an existing 99 ODUCn link. 101 This document presents an overview of the changes introduced in 102 [ITU-T_G709_2016] to motivate the present topic and then analyzes 103 how the current GMPLS routing and signalling mechanisms can be 104 utilized to setup ODUk/ODUflex connections over ODUCn links. 106 1.1. Scope 108 For the purposes of the B100G control plane discussion, the OTN 109 should be considered as a combination of ODU and OTSi layers. Note 110 that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for 111 B100G entities, and leaving it intact only for maintaining continuity 112 in the description of the signals with bandwidth upto 100G. This 113 document focuses on only the control of the ODU layer. The control 114 of the OTSi layer is out of scope of this document. But in order to 115 facilitate the description of the challenges brought by 116 [ITU-T_G709_2016] to B100G GMPLS routing and signalling, some general 117 description about OTSi will be included in this draft. 119 2. Terminology 121 2.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2.2. OTN terminology used in this document 129 a. OPUCn: Optical Payload Unit -Cn. 131 b. ODUCn: Optical Data Unit - Cn. 133 c. OTUCn: Fully standardized Optical Transport Unit - Cn. 135 d. OTUCn-M: This signal is an extension of the OTUCn signal 136 introduced above. This signal contains the same amount of 137 overhead as the OTUCn signal, but contains a reduced amount of 138 payload area. Specifically the payload area consists of M 5G 139 tributary slots (where M is strictly less than 20*n). 141 e. PSI: OPU Payload structure Indicator. This is a multi-frame 142 message and describes the composition of the OPU signal. This 143 field is a concatenation of the Payload type (PT) and the 144 Multiplex Structrure Indicator (MSI) defined below. 146 f. MSI: Multiplex Structure Indicator. This structure indicates the 147 grouping of the tributary slots in an OPU payload area to realize 148 a client signal that is multiplexed into an OPU. The individual 149 clients multiplexed into the OPU payload area are distinguished 150 by the Tributary Port number (TPN). 152 g. GMP: Generic Mapping Procedure. 154 h. OTSiG: see [ITU-T_G872] 156 i. OTSiA: see [ITU-T_G872] 158 Detailed description of these terms can be found in 159 [ITU-T_G709_2016]. 161 3. Overview of B100G in G.709 163 This section provides an overview of new features in 164 [ITU-T_G709_2016]. 166 3.1. OTUCn 168 In order to carry client signals with rates greater than 100Gbps, 169 [ITU-T_G709_2016] takes a general and scalable approach that 170 decouples the rates of OTU signals from the client rate evolution. 171 The new OTU signal is called OTUCn; this signal is defined to have a 172 rate of (approximately) n*100G. The following are the key 173 characteristics of the OTUCn signal: 175 a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals 176 perform digital section roles only (see 177 [ITU-T_G709_2016]:Section 6.1.1) 179 b. The OTUCn signals can be viewed as being formed by interleaving n 180 OTUC signals (where are labeled 1, 2, ..., n), each of which has 181 the format of a standard OTUk signal without the FEC columns (per 182 [ITU-T_G709_2016]Figure 7-1). The ODUCn have a similar 183 structure, i.e. they can be seen as being formed by interleaving 184 n instances of ODUC signals (respectively). The OTUC signal 185 contains the ODUC signals, just as in the case of fixed rate OTUs 186 defined in G.709 [ITU-T_G709_2016]. 188 c. Each of the OTUC "slices" have the same overhead (OH) as the 189 standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined 190 signal OTUCn has n instances of OTUC OH, ODUC OH. 192 d. The OTUC signal has a slightly higher rate compared to the OTU4 193 signal (without FEC); this is to ensure that the OPUC payload 194 area can carry an ODU4 signal. 196 3.1.1. Carrying OTUCn between 3R points 198 As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn 199 and OPUCn signal structures are presented in a (physical) interface 200 independent manner, by means of n OTUC, ODUC and OPUC instances that 201 are marked #1 to #n. Specifically, the definition of the OTUCn 202 signal does not cover aspects such as FEC, modulation formats, etc. 203 These details are defined as part of the adaptation of the OTUCn 204 layer to the optical layer(s). The specific interleaving of 205 OTUC/ODUC/OPUC signals onto the optical signals is interface specific 206 and specified for OTN interfaces with standardized application codes 207 in the interface specific recommendations (G.709.x). 209 The following scenarios of OTUCn transport need to be considered (see 210 Figure 1): 212 a. inter-domain interfaces: These types of interfaces are used for 213 connecting OTN edge nodes to (a) client equipment (e.g. routers) 214 or (b) hand-off points from other OTN networks. ITU-T has 215 standardized the Flexible OTN (FlexO) interfaces to support these 216 functions. Recommendation [ITU-T_G709.1] specifies a flexible 217 interoperable short-reach OTN interface over which an OTUCn (n 218 >=1) is transferred, using bonded FlexO interfaces which belong 219 to a FlexO group. In its current form, Recommendation 220 [ITU-T_G709.1] is limited to the case of transporting OTUCn 221 signals using n 100G Ethernet PHY(s). When the PHY(s) for the 222 emerging set of Ethernet signals, e.g. 200GbE and 400GbE, become 223 available, new recommendations can define the required 224 adaptations. 226 b. intra-domain interfaces: In these cases, the OTUCn is transported 227 using a proprietary (vendor specific) encapsulation, FEC etc. In 228 future, it may be possible to transport OTUCn for intra-domain 229 links using future variants of FlexO. 231 ================================================================== 233 +--------------------------------------------------------+ 234 | OTUCn signal | 235 +--------------------------------------------------------+ 236 | Inter+Domain | Intra+Domain | Intra+Domain | 237 | Interface (IrDI)| Interface (IaDI)| Interface | 238 | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | 239 | | (Future) | Encap, FEC etc. | 240 +--------------------------------------------------------+ 242 ================================================================== 244 Figure 1: OTUCn transport possibilities 246 3.2. ODUCn 248 The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by 249 the appropriate interleaving of content from n ODUC signal instances. 250 The ODUC frames have the same structure as a standard ODU -- in the 251 sense that it has the same Overhead (OH) area, and the payload area 252 -- but has a higher rate since its payload area can embed an ODU4 253 signal. 255 The ODUCn signals have a rate that is captured in Table 1. 257 +----------+--------------------------------------------------------+ 258 | ODU Type | ODU Bit Rate | 259 +----------+--------------------------------------------------------+ 260 | ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 | 261 | | kbit/s | 262 +----------+--------------------------------------------------------+ 264 Table 1: ODUCn rates 266 The ODUCn is a multiplex section ODU signal, and is mapped into an 267 OTUCn signal which provides the regenerator section layer. In some 268 scenarios, the ODUCn, and OTUCn signals will be co-terminous, i.e. 269 they will have identical source/sink locations. [ITU-T_G709_2016] 270 and [ITU-T_G872] allow for the ODUCn signal to pass through a digital 271 regenerator node which will terminate the OTUCn layer, but will pass 272 the regenerated (but otherwise untouched) ODUCn towards a different 273 OTUCn interface where a fresh OTUCn layer will be initiated (see 274 Figure 2). In this case, the ODUCn is carried by 3 OTUCn segments. 276 Specifically, the OPUCn signal flows through these regenerators 277 unchanged. That is, the set of client signals, their TPNs, trib-slot 278 allocation remains unchanged. Note however that the ODUCn Overhead 279 (OH) might be modified if TCM sub-layers are instantiated in order to 280 monitor the performance of the repeater hops. In this sense, the 281 ODUCn should not be seen as a general ODU which can be switched via 282 an ODUk cross-connect. 284 ================================================================== 286 +--------+ +--------+ +--------+ +--------+ 287 | +-----------+ | | +----------+ | 288 | OTN |-----------| OTN | | OTN |----------| OTN | 289 | DXC +-----------+ WXC +----------------+ WXC +----------+ DXC | 290 | | | 3R | | 3R | | | 291 +--------+ +--------+ +--------+ +--------+ 292 <--------------------------------ODUCn------------------------------> 293 <------------------> <----------------------> <------------------> 294 OTUCn OTUCn OTUCn 296 ================================================================== 298 Figure 2: ODUCn signal 300 3.3. OTUCn-M 302 The standard OTUCn signal has the same rate as that of the ODUCn 303 signal as captured in Table 1. This implies that the OTUCn signal 304 can only be transported over wavelength groups which have a total 305 capacity of multiples of (approximately) 100G. Modern DSPs support a 306 variety of bit rates per wavelength, depending on the reach 307 requirements for the optical link. In other words, it is possible to 308 extend the reach of an optical link (i.e. increase the physical 309 distance covered) by lowering the bitrate of the client signal that 310 is modulated onto the carrier(s). By the very nature of the OTUCn 311 signal, it is constrained to rates which are multiples of 312 (approximately) 100G. If it so happens that the total rate of the 313 LO-ODUs carried over the ODUCn is smaller than n X 100G, it is 314 possible to "crunch" the OTUCn to remove the unused capacity. With 315 this in mind, ITU-T supports the notion of a reduced rate OTUCn 316 signal, termed the OTUCn-M. The OTUCn-M signal is derived from the 317 OTUCn signal by retaining all the n instances of overhead (one per 318 OTUC slice) but only M tributary slots of capacity. 320 3.4. Time Slot Granularity 322 [ITU-T_G709_2012] introduced the support for 1.25G granular tributary 323 slots in OPU2, OPU3, and OPU4 signals. With the introduction of 324 higher rate signals, it is no longer practical for the optical 325 networks (and the datapath hardware) to support a very large number 326 of flows at such a fine granularity. ITU-T has defined the OPUC with 327 a tributary slot granularity of 5G. This means that the ODUCn signal 328 has 20*n tributary slots (of 5Gbps capacity). It is worthwhile 329 considering that the range of tributary port number (TPN) is 10*n, 330 and not 20*n which would allow for a different client signal to be 331 carried in each TS. As an example, it will not be possible to embed 332 15 5G ODUflex signals in a ODUC1. 334 3.5. Structure of OPUCn MSI with Payload type 0x22 336 As mentioned above, the OPUCn signal has 20*n 5G tributary slots. 337 The OPUCn contains n PSI structures, one per OPUC instance. The PSI 338 structure consists of the Payload Type (of 0x22), followed by a 339 Reserved Field (1 byte), followed by the MSI. The OPUCn MSI field 340 has a fixed length of 40*n bytes and indicates the availability of 341 each TS. Two bytes are used for each of the 20*n tributary slots, 342 and each such information structure has the following format 343 ([ITU-T_G709_2016] G.709:Section 20.4.1): 345 a. The TS availability bit 1 indicates if the tributary slot is 346 available or unavailable 348 b. The TS occupation bit 9 indicates if the tributary slot is 349 allocated or unallocated 351 c. b.c. The tributary port # in bits 2 to 8 and 10 to 16 indicates 352 the port number of the client that is being carried in this 353 specific TS; a flexible assignment of tributary port to tributary 354 slots is possible. Numbering of tributary ports are is from 1 to 355 10n. 357 3.6. Client Signal Mappings 359 The approach taken by the ITU-T to map non-OTN client signals to the 360 appropriate ODU containers is as follows: 362 a. All client signals with rates less than 100G are mapped as 363 specified in [ITU-T_G709_2016]:Clause 17. These mappings are 364 identical to those specified in the earlier revision of G.709 365 [ITU-T_G709_2012]. Thus, for example, the 1000BASE-X/10GBASE-R 366 signals are mapped to ODU0/ODU2e respectively (see Table 2 -- 367 based on Table 7-2 in [ITU-T_G709_2016]) 369 b. Always map the new and emerging client signals to ODUflex signals 370 of the appropriate rates (see Table 2 -- based on Table 7-2 in 371 [ITU-T_G709_2016]) 373 c. Drop support for ODU Virtual Concatenation. This simplifies the 374 network, and the supporting hardware since multiple different 375 mappings for the same client are no longer necessary. Note that 376 legacy implementations that transported sub-100G clients using 377 ODU VCAT shall continue to be supported. 379 d. ODUflex signals are low-order signals only. If the ODUflex 380 entities have rates of 100G or less, they can be transported 381 using either an ODUk (k=1..4) or an ODUCn server layer. On the 382 other hand, ODUflex connections with rates greater than 100G will 383 require the server layer to be ODUCn. The ODUCn signals must be 384 adapted to an OTUCn signal. Figure 3 illstrates the hierarchy of 385 the digital signals defined in [ITU-T_G709_2016]. 387 +----------------+--------------------------------------------------+ 388 | ODU Type | ODU Bit Rate | 389 +----------------+--------------------------------------------------+ 390 | ODU0 | 1,244,160 Kbps | 391 | ODU1 | 239/238 x 2,488,320 Kbps | 392 | ODU2 | 239/237 x 9,953,280 Kbps | 393 | ODU2e | 239/237 x 10,312,500 Kbps | 394 | ODU3 | 239/236 x 39,813,120 Kbps | 395 | ODU4 | 239/227 x 99,532,800 Kbps | 396 | ODUflex for | 239/238 x Client signal Bit rate | 397 | CBR client | | 398 | signals | | 399 | ODUflex for | Configured bit rate | 400 | GFP-F mapped | | 401 | packet traffic | | 402 | ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= | 403 | IMP mapped | 1 | 404 | packet traffic | | 405 | ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is | 406 | FlexE aware | total number of available tributary slots among | 407 | transport | all PHYs which have been crunched and combined. | 408 +----------------+--------------------------------------------------+ 410 Note that this table doesn't include ODUCn -- since it cannot be 411 generated by mapping a non-OTN signal. An ODUCn is always formed by 412 multiplexing multiple LO-ODUs. 414 Table 2: Types and rates of ODUs usable for client mappings 416 ================================================================== 418 Clients (e.g. SONET/SDH, Ethernet) 419 + + + 420 | | | 421 +------------------+-------+------+------------------------+ 422 | OPUk | 423 +----------------------------------------------------------+ 424 | ODUk | 425 +-----------------------+---------------------------+------+ 426 | OTUk, OTUk.V, OTUkV | OPUk | | 427 +----------+----------------------------------------+ | 428 | OTLk.n | | ODUk | | 429 +----------+ +---------------------+-----+ | 430 | OTUk, OTUk.V, OTUkV | OPUCn | 431 +----------+-----------------------+ 432 | OTLk.n | | ODUCn | 433 +----------+ +------------+ 434 | OTUCn | 435 +------------+ 437 ================================================================== 439 Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 441 4. Applicability and GMPLS Implications 443 4.1. Applicability and Challenges 445 Two typical scenarios are depicted in Appendix XIII of 446 [ITU-T_G709_2016], which are also introduced into this document to 447 help analyze the potential extension to GMPLS needed. Though these 448 two scenarios are mainly introduced in G.709 to describe OTUCn sub 449 rates application, they can also be used to describe general OTUCn 450 application. One thing that should be note is these two scenarios 451 are a little different from those described in [ITU-T_G709_2016], as 452 the figure in this section include the OTSi(G) in to facilitate the 453 description of the challenge brought by [ITU-T_G709_2016]. 455 The first scenarios is depicted in Figure 4. This scenario deploys 456 OTUCn/OTUCn-M between two line ports connecting two L1/L0 ODU cross 457 connects (XC) within one optical transport network. One OTUCn is 458 actually carried by one OTSi(G) or OTSiA. 460 As defined in [ITU-T_G872], OTSiG is used to represent one or more 461 OTSi as a group to carry a single client signal (e.g., OTUCn). The 462 OTSiG may have non-associated overhead, the combination of the OTSiG 463 and OTSiG-O is represented by the OTSiA management/control 464 abstraction. 466 In this scenario, it is clear that the OTUCn and ODUCn link can be 467 automatically established, after/together with the setup of OTSi(G) 468 or OTSiA, as both OTUCn and ODUCn perform section layer only. One 469 client OTUCn signal is carried by one single huge OTSi signal or a 470 group of OTSi. There is a 1:1 mapping relationship between OTUCn and 471 OTSi(G) or OTSiA. 473 For example, one 400G OTUCn signal can be carried by one single 400G 474 OTSi signal or one 400G OTUCn signal can be split into 4 different 475 OTUC instances, with each instances carried by one OTSi. Those four 476 OTSi function as a group to carry a single 400G OTUCn signal. 478 ================================================================== 480 +--------+ +--------+ 481 | +---------------------+ | 482 | OTN |---------------------| OTN | 483 | XC +---------------------+ XC | 484 | | | | 485 +--------+ +--------+ 486 <---------- ODUk/ODUflex -----------> 487 <------------ ODUCn --------------> 488 <------- OTUCn/OTUCn-M ---------> 489 <--------OTSi(G)/OTSiA---------> 491 ================================================================== 493 Figure 4: Scenario A 495 The second scenarios is depicted in Figure 4. This scenario deploys 496 OTUCn/OTUCn-M between transponders which are in a different domain B, 497 which are separated from the L1 ODU XCs in domain A and/or C. one 498 end-to-end ODUCn is actually supported by three different OTUCn or 499 OTUCn-M segments, which are in turn carried by OTSi(G) or OTSiA. 501 In the second scenario, OTUCn links will be established automatically 502 after/together with the setup of OTSi(G) or OTSiA, while there are 503 still some doubts about how the ODUCn link is established. In 504 principle, it could/should be possible but it is not yet clear in 505 details how the ODUCn link can be automatically setup. 507 ================================================================== 509 +--------------------------------------+ 510 A | B | A or C 511 | | | | 512 +--------+ | +--------+ +--------+ | +--------+ 513 | +----------|-+ | | +-|--------+ | 514 | OTN |----------|-| Transp | | Transp |-|--------| OTN | 515 | XC +----------|-+ onder +----------------+ onder +-|--------+ XC | 516 | | | | | | | | | | 517 +--------+ | +--------+ +--------+ | +--------+ 518 | | 519 +--------------------------------------+ 521 <-----------------------------ODUk/ODUflex----------------------------> 522 <----------------------------- ODUCn -------------------------------> 523 <-------OTUCn-------><-----OTUCn/OTUCn-M-----><-------OTUCn-------> 524 <--OTSi(G)/OTSiA--> <----OTSi(G)/OTSiA----> <--OTSi(G)/OTSiA--> 526 ================================================================== 528 Figure 5: Scenario B 530 According to the above description, it can be concluded that some 531 uncertainty about setup of ODUCn link still exist, and this 532 uncertainty may have relationship with the progress in ITU-T. Based 533 on the analysis, it is suggested that the scope of this draft should 534 mainly focus on how to set up ODUk/ODUflex LSPs over ODUCn links, as 535 also indicated in the figure above. 537 4.2. GMPLS Implications and Applicability 539 4.2.1. Implications and Applicability for GMPLS Signalling 541 Once the ODUCn link is configured, the GMPLS mechanisms defined in 542 RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes. 543 As the resource on the ODUCn link which can be seen by the client 544 ODUk/ODUflex is a serial of 5G slots, the label defined in RFC7139 is 545 able to accommodate the requirement of the setup of ODUk/ODUflex over 546 ODUCn link. 548 One thing should be note is the TPN used in RFC7139 and defined in 549 G.709-2016 for ODUCn link. Since the TPN currently defined in G.709 550 for ODUCn link has 14 bits, while this field in RFC7139 only has 12 551 bits, some extension work is needed, but this is not so urgent since 552 for today networks scenarios 12 bits are enough, as it can support a 553 single ODUCn link up to n=400, namely 40Tbit. 555 An example is given below to illustrate the label format defined in 556 RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G 557 slots, and twenty of them are allocated to the ODU4. Along with the 558 increase of "n", the label may become lengthy, an optimized label 559 format may be needed. 561 ================================================================== 563 0 1 2 3 564 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | TPN = 3 | Reserved | Length = 200 | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0| 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0| 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0| 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0| 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0| 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0| 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |0 0 0 0 0 0 0 0| Padding Bits(0) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 ================================================================== 585 Figure 6: Label format 587 4.2.2. Implications and Applicability for GMPLS Routing 589 For routing, we think that no extension to current mechanisms defined 590 in RFC7138 are needed. Because, once one ODUCn link is up, we need 591 to advertise only the resources that can be used on this ODUCn link 592 and the multiplexing hierarchy on this link. Considering ODUCn link 593 is already configured, it's the ultimate hierarchy of this 594 multiplexing, there is no need to explicitly extent the ODUCn signal 595 type in the routing. 597 The OSPF-TE extension defined in section 4 of RFC7138 can be used to 598 advertise the resource information on the ODUCn link to direct the 599 setup of ODUk/ODUflex. 601 5. Acknowledgements 603 6. Authors (Full List) 605 Qilei Wang (editor) 607 ZTE 609 Nanjing, China 611 Email: wang.qilei@zte.com.cn 613 Radha Valiveti (editor) 615 Infinera Corp 617 Sunnyvale, CA, USA 619 Email: rvaliveti@infinera.com 621 Haomian Zheng (editor) 623 Huawei 625 CN 627 EMail: zhenghaomian@huawei.com 629 Huub van Helvoort 631 Hai Gaoming B.V 633 EMail: huubatwork@gmail.com 635 Sergio Belotti 636 Nokia 638 EMail: sergio.belotti@nokia.com 640 Iftekhar Hussain 642 Infinera Corp 644 Sunnyvale, CA, USA 646 Email: IHussain@infinera.com 648 Daniele Ceccarelli 650 Ericsson 652 Email: daniele.ceccarelli@ericsson.com 654 7. Contributors 656 Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com 658 Fatai Zhang, Huawei,zhangfatai@huawei.com 660 Italo Busi, Huawei,italo.busi@huawei.com 662 Zheyu Fan, Huawei, fanzheyu2@huawei.com 664 Dieter Beller, Nokia, Dieter.Beller@nokia.com 666 Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn 668 Zafar Ali, Cisco Systems, zali@cisco.com 670 Daniel King, d.king@lancaster.ac.uk 672 Manoj Kumar, Cisco Systems, manojk2@cisco.com 674 Antonello Bonfanti, Cisco Systems, abonfant@cisco.com 676 Akshaya Nadahalli, Cisco Systems, anadahal@cisco.com 678 8. IANA Considerations 680 This memo includes no request to IANA. 682 9. Security Considerations 684 None. 686 10. References 688 10.1. Normative References 690 [ITU-T_G709.1] 691 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 692 2016", , 2016. 694 [ITU-T_G709_2012] 695 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 696 02/2012", http://www.itu.int/rec/T-REC- 697 G..709-201202-S/en, February 2012. 699 [ITU-T_G709_2016] 700 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 701 07/2016", http://www.itu.int/rec/T-REC- 702 G..709-201606-P/en, July 2016. 704 [ITU-T_G872] 705 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 706 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 707 January 2017. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 715 Switching (GMPLS) Signaling Extensions for G.709 Optical 716 Transport Networks Control", RFC 4328, 717 DOI 10.17487/RFC4328, January 2006, 718 . 720 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 721 J. Drake, "Traffic Engineering Extensions to OSPF for 722 GMPLS Control of Evolving G.709 Optical Transport 723 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 724 . 726 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 727 and K. Pithewan, "GMPLS Signaling Extensions for Control 728 of Evolving G.709 Optical Transport Networks", RFC 7139, 729 DOI 10.17487/RFC7139, March 2014, 730 . 732 10.2. Informative References 734 [I-D.izh-ccamp-flexe-fwk] 735 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 736 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 737 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 738 Zhong, "GMPLS Routing and Signaling Framework for Flexible 739 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 740 progress), October 2016. 742 Authors' Addresses 744 Qilei Wang (editor) 745 ZTE 746 Nanjing 747 CN 749 Email: wang.qilei@zte.com.cn 751 Radha Valiveti (editor) 752 Infinera Corp 753 Sunnyvale 754 USA 756 Email: rvaliveti@infinera.com 758 Haomian Zheng (editor) 759 Huawei 760 CN 762 Email: zhenghaomian@huawei.com 764 Huub van Helvoort 765 Hai Gaoming B.V 767 Email: huubatwork@gmail.com 768 Sergio Belotti 769 Nokia 771 Email: sergio.belotti@nokia.com