idnits 2.17.1 draft-ietf-ccamp-gmpls-otn-b100g-applicability-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 26 instances of too long lines in the document, the longest one being 10 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 7, 2019) is 1755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4328' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'I-D.izh-ccamp-flexe-fwk' is defined on line 768, 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 8, 2020 Infinera Corp 6 H. Zheng, Ed. 7 Huawei 8 H. Helvoort 9 Hai Gaoming B.V 10 S. Belotti 11 Nokia 12 July 7, 2019 14 Applicability of GMPLS for B100G Optical Transport Network 15 draft-ietf-ccamp-gmpls-otn-b100g-applicability-01 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 8, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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. TE-Link Representation . . . . . . . . . . . . . . . 12 75 4.2.2. Implications and Applicability for GMPLS Signalling . 13 76 4.2.3. Implications and Applicability for GMPLS Routing . . 14 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 78 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 15 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 10.2. Informative References . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 The current GMPLS routing [RFC7138] and signaling extensions 90 [RFC7139] only includes coverage for the control of all the OTN 91 capabilities that were defined in the 2012 version of G.709 92 [ITU-T_G709_2012]. 94 While the 2016 version of G.709 [ITU-T_G709_2016] introduces support 95 for new higher rate ODU signals, termed ODUCn (which have a nominal 96 rate of n x 100 Gbps), how to use GMPLS to configure ODUCn should be 97 taken into consideration. But it seems how to configure the ODUCn 98 link needs more discussion, so this draft mainly focuses on the use 99 of current GMPLS mechanisms to set up ODUk/ODUflex over an existing 100 ODUCn link. 102 This document presents an overview of the changes introduced in 103 [ITU-T_G709_2016] to motivate the present topic and then analyzes how 104 the current GMPLS routing and signalling mechanisms can be utilized 105 to setup ODUk/ODUflex connections over ODUCn links. 107 1.1. Scope 109 For the purposes of the B100G control plane discussion, the OTN 110 should be considered as a combination of ODU and OTSi layers. Note 111 that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for 112 B100G entities, and leaving it intact only for maintaining continuity 113 in the description of the signals with bandwidth upto 100G. This 114 document focuses on only the control of the ODU layer. The control 115 of the OTSi layer is out of scope of this document. But in order to 116 facilitate the description of the challenges brought by 117 [ITU-T_G709_2016] to B100G GMPLS routing and signalling, some general 118 description about OTSi will be included in this draft. 120 2. Terminology 122 2.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2.2. OTN terminology used in this document 130 a. OPUCn: Optical Payload Unit -Cn. 132 b. ODUCn: Optical Data Unit - Cn. 134 c. OTUCn: Fully standardized Optical Transport Unit - Cn. 136 d. OTUCn-M: This signal is an extension of the OTUCn signal 137 introduced above. This signal contains the same amount of 138 overhead as the OTUCn signal, but contains a reduced amount of 139 payload area. Specifically the payload area consists of M 5G 140 tributary slots (where M is strictly less than 20*n). 142 e. PSI: OPU Payload structure Indicator. This is a multi-frame 143 message and describes the composition of the OPU signal. This 144 field is a concatenation of the Payload type (PT) and the 145 Multiplex Structrure Indicator (MSI) defined below. 147 f. MSI: Multiplex Structure Indicator. This structure indicates the 148 grouping of the tributary slots in an OPU payload area to realize 149 a client signal that is multiplexed into an OPU. The individual 150 clients multiplexed into the OPU payload area are distinguished 151 by the Tributary Port number (TPN). 153 g. GMP: Generic Mapping Procedure. 155 h. OTSiG: see [ITU-T_G872] 157 i. OTSiA: see [ITU-T_G872] 159 Detailed description of these terms can be found in 160 [ITU-T_G709_2016]. 162 3. Overview of B100G in G.709 164 This section provides an overview of new features in 165 [ITU-T_G709_2016]. 167 3.1. OTUCn 169 In order to carry client signals with rates greater than 100Gbps, 170 [ITU-T_G709_2016] takes a general and scalable approach that 171 decouples the rates of OTU signals from the client rate evolution. 172 The new OTU signal is called OTUCn; this signal is defined to have a 173 rate of (approximately) n*100G. The following are the key 174 characteristics of the OTUCn signal: 176 a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals 177 perform digital section roles only (see 178 [ITU-T_G709_2016]:Section 6.1.1) 180 b. The OTUCn signals can be viewed as being formed by interleaving n 181 OTUC signals (where are labeled 1, 2, ..., n), each of which has 182 the format of a standard OTUk signal without the FEC columns (per 183 [ITU-T_G709_2016]Figure 7-1). The ODUCn have a similar 184 structure, i.e. they can be seen as being formed by interleaving 185 n instances of ODUC signals (respectively). The OTUC signal 186 contains the ODUC signals, just as in the case of fixed rate OTUs 187 defined in G.709 [ITU-T_G709_2016]. 189 c. Each of the OTUC "slices" have the same overhead (OH) as the 190 standard OTUk signal in G.709 [ITU-T_G709_2016]. The combined 191 signal OTUCn has n instances of OTUC OH, ODUC OH. 193 d. The OTUC signal has a slightly higher rate compared to the OTU4 194 signal (without FEC); this is to ensure that the OPUC payload 195 area can carry an ODU4 signal. 197 3.1.1. Carrying OTUCn between 3R points 199 As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn 200 and OPUCn signal structures are presented in a (physical) interface 201 independent manner, by means of n OTUC, ODUC and OPUC instances that 202 are marked #1 to #n. Specifically, the definition of the OTUCn 203 signal does not cover aspects such as FEC, modulation formats, etc. 204 These details are defined as part of the adaptation of the OTUCn 205 layer to the optical layer(s). The specific interleaving of 206 OTUC/ODUC/OPUC signals onto the optical signals is interface specific 207 and specified for OTN interfaces with standardized application codes 208 in the interface specific recommendations (G.709.x). 210 The following scenarios of OTUCn transport need to be considered (see 211 Figure 1): 213 a. inter-domain interfaces: These types of interfaces are used for 214 connecting OTN edge nodes to (a) client equipment (e.g. routers) 215 or (b) hand-off points from other OTN networks. ITU-T has 216 standardized the Flexible OTN (FlexO) interfaces to support these 217 functions. Recommendation [ITU-T_G709.1] specifies a flexible 218 interoperable short-reach OTN interface over which an OTUCn (n 219 >=1) is transferred, using bonded FlexO interfaces which belong 220 to a FlexO group. In its current form, Recommendation 221 [ITU-T_G709.1] is limited to the case of transporting OTUCn 222 signals using n 100G Ethernet PHY(s). When the PHY(s) for the 223 emerging set of Ethernet signals, e.g. 200GbE and 400GbE, become 224 available, new recommendations can define the required 225 adaptations. 227 b. intra-domain interfaces: In these cases, the OTUCn is transported 228 using a proprietary (vendor specific) encapsulation, FEC etc. In 229 future, it may be possible to transport OTUCn for intra-domain 230 links using future variants of FlexO. 232 ================================================================== 234 +--------------------------------------------------------+ 235 | OTUCn signal | 236 +--------------------------------------------------------+ 237 | Inter+Domain | Intra+Domain | Intra+Domain | 238 | Interface (IrDI)| Interface (IaDI)| Interface | 239 | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | 240 | | (Future) | Encap, FEC etc. | 241 +--------------------------------------------------------+ 243 ================================================================== 245 Figure 1: OTUCn transport possibilities 247 3.2. ODUCn 249 The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by 250 the appropriate interleaving of content from n ODUC signal instances. 251 The ODUC frames have the same structure as a standard ODU -- in the 252 sense that it has the same Overhead (OH) area, and the payload area 253 -- but has a higher rate since its payload area can embed an ODU4 254 signal. 256 The ODUCn signals have a rate that is captured in Table 1. 258 +----------+--------------------------------------------------------+ 259 | ODU Type | ODU Bit Rate | 260 +----------+--------------------------------------------------------+ 261 | ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 | 262 | | kbit/s | 263 +----------+--------------------------------------------------------+ 265 Table 1: ODUCn rates 267 The ODUCn is a multiplex section ODU signal, and is mapped into an 268 OTUCn signal which provides the regenerator section layer. In some 269 scenarios, the ODUCn, and OTUCn signals will be co-terminous, i.e. 270 they will have identical source/sink locations. [ITU-T_G709_2016] 271 and [ITU-T_G872] allow for the ODUCn signal to pass through a digital 272 regenerator node which will terminate the OTUCn layer, but will pass 273 the regenerated (but otherwise untouched) ODUCn towards a different 274 OTUCn interface where a fresh OTUCn layer will be initiated (see 275 Figure 2). In this case, the ODUCn is carried by 3 OTUCn segments. 277 Specifically, the OPUCn signal flows through these regenerators 278 unchanged. That is, the set of client signals, their TPNs, trib-slot 279 allocation remains unchanged. Note however that the ODUCn Overhead 280 (OH) might be modified if TCM sub-layers are instantiated in order to 281 monitor the performance of the repeater hops. In this sense, the 282 ODUCn should not be seen as a general ODU which can be switched via 283 an ODUk cross-connect. 285 ================================================================== 287 +--------+ +--------+ +--------+ +--------+ 288 | +-----------+ | | +----------+ | 289 | OTN |-----------| OTN | | OTN |----------| OTN | 290 | DXC +-----------+ WXC +----------------+ WXC +----------+ DXC | 291 | | | 3R | | 3R | | | 292 +--------+ +--------+ +--------+ +--------+ 293 <--------------------------------ODUCn------------------------------> 294 <------------------> <-----------------------> <------------------> 295 OTUCn OTUCn OTUCn 297 ================================================================== 299 Figure 2: ODUCn signal 301 3.3. OTUCn-M 303 The standard OTUCn signal has the same rate as that of the ODUCn 304 signal as captured in Table 1. This implies that the OTUCn signal 305 can only be transported over wavelength groups which have a total 306 capacity of multiples of (approximately) 100G. Modern DSPs support a 307 variety of bit rates per wavelength, depending on the reach 308 requirements for the optical link. In other words, it is possible to 309 extend the reach of an optical link (i.e. increase the physical 310 distance covered) by lowering the bitrate of the client signal that 311 is modulated onto the carrier(s). By the very nature of the OTUCn 312 signal, it is constrained to rates which are multiples of 313 (approximately) 100G. If it so happens that the total rate of the 314 LO-ODUs carried over the ODUCn is smaller than n X 100G, it is 315 possible to "crunch" the OTUCn to remove the unused capacity. With 316 this in mind, ITU-T supports the notion of a reduced rate OTUCn 317 signal, termed the OTUCn-M. The OTUCn-M signal is derived from the 318 OTUCn signal by retaining all the n instances of overhead (one per 319 OTUC slice) but only M tributary slots of capacity. 321 3.4. Time Slot Granularity 323 [ITU-T_G709_2012] introduced the support for 1.25G granular tributary 324 slots in OPU2, OPU3, and OPU4 signals. With the introduction of 325 higher rate signals, it is no longer practical for the optical 326 networks (and the datapath hardware) to support a very large number 327 of flows at such a fine granularity. ITU-T has defined the OPUC with 328 a tributary slot granularity of 5G. This means that the ODUCn signal 329 has 20*n tributary slots (of 5Gbps capacity). It is worthwhile 330 considering that the range of tributary port number (TPN) is 10*n, 331 and not 20*n which would allow for a different client signal to be 332 carried in each TS. As an example, it will not be possible to embed 333 15 5G ODUflex signals in a ODUC1. 335 3.5. Structure of OPUCn MSI with Payload type 0x22 337 As mentioned above, the OPUCn signal has 20*n 5G tributary slots. 338 The OPUCn contains n PSI structures, one per OPUC instance. The PSI 339 structure consists of the Payload Type (of 0x22), followed by a 340 Reserved Field (1 byte), followed by the MSI. The OPUCn MSI field 341 has a fixed length of 40*n bytes and indicates the availability of 342 each TS. Two bytes are used for each of the 20*n tributary slots, 343 and each such information structure has the following format 344 ([ITU-T_G709_2016] G.709:Section 20.4.1): 346 a. The TS availability bit 1 indicates if the tributary slot is 347 available or unavailable 349 b. The TS occupation bit 9 indicates if the tributary slot is 350 allocated or unallocated 352 c. b.c. The tributary port # in bits 2 to 8 and 10 to 16 indicates 353 the port number of the client that is being carried in this 354 specific TS; a flexible assignment of tributary port to tributary 355 slots is possible. Numbering of tributary ports are is from 1 to 356 10n. 358 3.6. Client Signal Mappings 360 The approach taken by the ITU-T to map non-OTN client signals to the 361 appropriate ODU containers is as follows: 363 a. All client signals with rates less than 100G are mapped as 364 specified in [ITU-T_G709_2016]:Clause 17. These mappings are 365 identical to those specified in the earlier revision of G.709 366 [ITU-T_G709_2012]. Thus, for example, the 1000BASE-X/10GBASE-R 367 signals are mapped to ODU0/ODU2e respectively (see Table 2 -- 368 based on Table 7-2 in [ITU-T_G709_2016]) 370 b. Always map the new and emerging client signals to ODUflex signals 371 of the appropriate rates (see Table 2 -- based on Table 7-2 in 372 [ITU-T_G709_2016]) 374 c. Drop support for ODU Virtual Concatenation. This simplifies the 375 network, and the supporting hardware since multiple different 376 mappings for the same client are no longer necessary. Note that 377 legacy implementations that transported sub-100G clients using 378 ODU VCAT shall continue to be supported. 380 d. ODUflex signals are low-order signals only. If the ODUflex 381 entities have rates of 100G or less, they can be transported 382 using either an ODUk (k=1..4) or an ODUCn server layer. On the 383 other hand, ODUflex connections with rates greater than 100G will 384 require the server layer to be ODUCn. The ODUCn signals must be 385 adapted to an OTUCn signal. Figure 3 illstrates the hierarchy of 386 the digital signals defined in [ITU-T_G709_2016]. 388 +----------------+--------------------------------------------------+ 389 | ODU Type | ODU Bit Rate | 390 +----------------+--------------------------------------------------+ 391 | ODU0 | 1,244,160 Kbps | 392 | ODU1 | 239/238 x 2,488,320 Kbps | 393 | ODU2 | 239/237 x 9,953,280 Kbps | 394 | ODU2e | 239/237 x 10,312,500 Kbps | 395 | ODU3 | 239/236 x 39,813,120 Kbps | 396 | ODU4 | 239/227 x 99,532,800 Kbps | 397 | ODUflex for | 239/238 x Client signal Bit rate | 398 | CBR client | | 399 | signals | | 400 | ODUflex for | Configured bit rate | 401 | GFP-F mapped | | 402 | packet traffic | | 403 | ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= | 404 | IMP mapped | 1 | 405 | packet traffic | | 406 | ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is | 407 | FlexE aware | total number of available tributary slots among | 408 | transport | all PHYs which have been crunched and combined. | 409 +----------------+--------------------------------------------------+ 411 Note that this table doesn't include ODUCn -- since it cannot be 412 generated by mapping a non-OTN signal. An ODUCn is always formed by 413 multiplexing multiple LO-ODUs. 415 Table 2: Types and rates of ODUs usable for client mappings 417 ================================================================== 419 Clients (e.g. SONET/SDH, Ethernet) 420 + + + 421 | | | 422 +------------------+-------+------+------------------------+ 423 | OPUk | 424 +----------------------------------------------------------+ 425 | ODUk | 426 +-----------------------+---------------------------+------+ 427 | OTUk, OTUk.V, OTUkV | OPUk | | 428 +----------+----------------------------------------+ | 429 | OTLk.n | | ODUk | | 430 +----------+ +---------------------+-----+ | 431 | OTUk, OTUk.V, OTUkV | OPUCn | 432 +----------+-----------------------+ 433 | OTLk.n | | ODUCn | 434 +----------+ +------------+ 435 | OTUCn | 436 +------------+ 438 ================================================================== 440 Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 442 4. Applicability and GMPLS Implications 444 4.1. Applicability and Challenges 446 Two typical scenarios are depicted in Appendix XIII of 447 [ITU-T_G709_2016], which are also introduced into this document to 448 help analyze the potential extension to GMPLS needed. Though these 449 two scenarios are mainly introduced in G.709 to describe OTUCn sub 450 rates application, they can also be used to describe general OTUCn 451 application. One thing that should be note is these two scenarios 452 are a little different from those described in [ITU-T_G709_2016], as 453 the figure in this section include the OTSi(G) in to facilitate the 454 description of the challenge brought by [ITU-T_G709_2016]. 456 The first scenarios is depicted in Figure 4. This scenario deploys 457 OTUCn/OTUCn-M between two line ports connecting two L1/L0 ODU cross 458 connects (XC) within one optical transport network. One OTUCn is 459 actually carried by one OTSi(G) or OTSiA. 461 As defined in [ITU-T_G872], OTSiG is used to represent one or more 462 OTSi as a group to carry a single client signal (e.g., OTUCn). The 463 OTSiG may have non-associated overhead, the combination of the OTSiG 464 and OTSiG-O is represented by the OTSiA management/control 465 abstraction. 467 In this scenario, it is clear that the OTUCn and ODUCn link can be 468 automatically established, after/together with the setup of OTSi(G) 469 or OTSiA, as both OTUCn and ODUCn perform section layer only. One 470 client OTUCn signal is carried by one single huge OTSi signal or a 471 group of OTSi. There is a 1:1 mapping relationship between OTUCn and 472 OTSi(G) or OTSiA. 474 For example, one 400G OTUCn signal can be carried by one single 400G 475 OTSi signal or one 400G OTUCn signal can be split into 4 different 476 OTUC instances, with each instances carried by one OTSi. Those four 477 OTSi function as a group to carry a single 400G OTUCn signal. 479 ================================================================== 481 +--------+ +--------+ 482 | +---------------------+ | 483 | OTN |---------------------| OTN | 484 | XC +---------------------+ XC | 485 | | | | 486 +--------+ +--------+ 487 <---------- ODUk/ODUflex -----------> 488 <------------ ODUCn --------------> 489 <------- OTUCn/OTUCn-M ---------> 490 <--------OTSi(G)/OTSiA---------> 492 ================================================================== 494 Figure 4: Scenario A 496 The second scenarios is depicted in Figure 4. This scenario deploys 497 OTUCn/OTUCn-M between transponders which are in a different domain B, 498 which are separated from the L1 ODU XCs in domain A and/or C. one 499 end-to-end ODUCn is actually supported by three different OTUCn or 500 OTUCn-M segments, which are in turn carried by OTSi(G) or OTSiA. 502 In the second scenario, OTUCn links will be established automatically 503 after/together with the setup of OTSi(G) or OTSiA, while there are 504 still some doubts about how the ODUCn link is established. In 505 principle, it could/should be possible but it is not yet clear in 506 details how the ODUCn link can be automatically setup. 508 ================================================================== 510 +--------------------------------------+ 511 A | B | A or C 512 | | | | 513 +--------+ | +--------+ +--------+ | +--------+ 514 | +----------|-+ | | +-|--------+ | 515 | OTN |----------|-| Transp | | Transp |-|--------| OTN | 516 | XC +----------|-+ onder +----------------+ onder +-|--------+ XC | 517 | | | | | | | | | | 518 +--------+ | +--------+ +--------+ | +--------+ 519 | | 520 +--------------------------------------+ 522 <-----------------------------ODUk/ODUflex----------------------------> 523 <----------------------------- ODUCn -------------------------------> 524 <-------OTUCn-------><-----OTUCn/OTUCn-M-----><-------OTUCn-------> 525 <--OTSi(G)/OTSiA--> <----OTSi(G)/OTSiA----> <--OTSi(G)/OTSiA--> 527 ================================================================== 529 Figure 5: Scenario B 531 According to the above description, it can be concluded that some 532 uncertainty about setup of ODUCn link still exist, and this 533 uncertainty may have relationship with the progress in ITU-T. Based 534 on the analysis, it is suggested that the scope of this draft should 535 mainly focus on how to set up ODUk/ODUflex LSPs over ODUCn links, as 536 also indicated in the figure above. 538 4.2. GMPLS Implications and Applicability 540 4.2.1. TE-Link Representation 542 Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with 543 TE-Links in GMPLS. Similar to that, ODUCn links can also be 544 represented as TE-Links, which can be seen in the figure below. 546 ================================================================== 548 3R 3R 549 +--------+ +--------+ +--------+ +--------+ 550 | | | | | | | | 551 | node A |<-OTUCn Link->| node B |<-OTUCn Link->| node C |<-OTUCn Link->| node D | 552 | | | | | | | | 553 +--------+ +--------+ +--------+ +--------+ 554 |<--------------------------- ODUCn Link -------------------------->| 555 |<----------------------------- TE-Link --------------------------->| 557 ================================================================== 559 Figure 6: telink 561 Two ends of a TE-Link is able to know whether the TE-Link is 562 supported by an ODUCn or an ODUk or an OTUk, as well as the resource 563 related information (e.g., slot granularity, number of tributary slot 564 available). 566 4.2.2. Implications and Applicability for GMPLS Signalling 568 Once the ODUCn link is configured, the GMPLS mechanisms defined in 569 RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes. 570 As the resource on the ODUCn link which can be seen by the client 571 ODUk/ODUflex is a serial of 5G slots, the label defined in RFC7139 is 572 able to accommodate the requirement of the setup of ODUk/ODUflex over 573 ODUCn link. The OTN-TDM GENERALIZED_LABEL object is used to indicate 574 how the LO ODUj signal is multiplexed into the HO ODUk link. The LO 575 ODUj Signal Type is indicated by Traffic Parameters, while the type 576 of HO ODUk link is identified by the selected interface carried in 577 the IF_ID RSVP_HOP object. IF_ID RSVP_HOP object provides a pointer 578 to the interface associated with TE-Link and therefore the two nodes 579 terminating the TE-link know (by internal/local configuration) the 580 attributes of ODUCn TE-Link. 582 One thing should be note is the TPN used in RFC7139 and defined in 583 G.709-2016 for ODUCn link. Since the TPN currently defined in G.709 584 for ODUCn link has 14 bits, while this field in RFC7139 only has 12 585 bits, some extension work is needed, but this is not so urgent since 586 for today networks scenarios 12 bits are enough, as it can support a 587 single ODUCn link up to n=400, namely 40Tbit. 589 An example is given below to illustrate the label format defined in 590 RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G 591 slots, and twenty of them are allocated to the ODU4. Along with the 592 increase of "n", the label may become lengthy, an optimized label 593 format may be needed. 595 ================================================================== 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | TPN = 3 | Reserved | Length = 200 | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 |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| 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |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| 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 |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| 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |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| 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 |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| 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |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| 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |0 0 0 0 0 0 0 0| Padding Bits(0) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 ================================================================== 619 Figure 7: Label format 621 4.2.3. Implications and Applicability for GMPLS Routing 623 For routing, we think that no extension to current mechanisms defined 624 in RFC7138 are needed. Because, once one ODUCn link is up, we need 625 to advertise only the resources that can be used on this ODUCn link 626 and the multiplexing hierarchy on this link. Considering ODUCn link 627 is already configured, it's the ultimate hierarchy of this 628 multiplexing, there is no need to explicitly extent the ODUCn signal 629 type in the routing. 631 The OSPF-TE extension defined in section 4 of RFC7138 can be used to 632 advertise the resource information on the ODUCn link to direct the 633 setup of ODUk/ODUflex. 635 5. Acknowledgements 637 6. Authors (Full List) 639 Qilei Wang (editor) 641 ZTE 643 Nanjing, China 645 Email: wang.qilei@zte.com.cn 647 Radha Valiveti (editor) 649 Infinera Corp 651 Sunnyvale, CA, USA 653 Email: rvaliveti@infinera.com 655 Haomian Zheng (editor) 657 Huawei 659 CN 661 EMail: zhenghaomian@huawei.com 663 Huub van Helvoort 665 Hai Gaoming B.V 667 EMail: huubatwork@gmail.com 669 Sergio Belotti 671 Nokia 673 EMail: sergio.belotti@nokia.com 674 Iftekhar Hussain 676 Infinera Corp 678 Sunnyvale, CA, USA 680 Email: IHussain@infinera.com 682 Daniele Ceccarelli 684 Ericsson 686 Email: daniele.ceccarelli@ericsson.com 688 7. Contributors 690 Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com 692 Fatai Zhang, Huawei,zhangfatai@huawei.com 694 Italo Busi, Huawei,italo.busi@huawei.com 696 Zheyu Fan, Individual, zheyu2008@gmail.com 698 Dieter Beller, Nokia, Dieter.Beller@nokia.com 700 Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn 702 Zafar Ali, Cisco Systems, zali@cisco.com 704 Daniel King, d.king@lancaster.ac.uk 706 Manoj Kumar, Cisco Systems, manojk2@cisco.com 708 Antonello Bonfanti, Cisco Systems, abonfant@cisco.com 710 Akshaya Nadahalli, Individual, nadahalli@gmail.com 712 8. IANA Considerations 714 This memo includes no request to IANA. 716 9. Security Considerations 718 None. 720 10. References 722 10.1. Normative References 724 [ITU-T_G709.1] 725 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 726 2016", , 2016. 728 [ITU-T_G709_2012] 729 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 730 02/2012", http://www.itu.int/rec/T-REC- 731 G..709-201202-S/en, February 2012. 733 [ITU-T_G709_2016] 734 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 735 07/2016", http://www.itu.int/rec/T-REC- 736 G..709-201606-P/en, July 2016. 738 [ITU-T_G872] 739 ITU-T, "ITU-T G.872: The Architecture of Optical Transport 740 Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en, 741 January 2017. 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, 745 DOI 10.17487/RFC2119, March 1997, 746 . 748 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 749 Switching (GMPLS) Signaling Extensions for G.709 Optical 750 Transport Networks Control", RFC 4328, 751 DOI 10.17487/RFC4328, January 2006, 752 . 754 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 755 J. Drake, "Traffic Engineering Extensions to OSPF for 756 GMPLS Control of Evolving G.709 Optical Transport 757 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 758 . 760 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 761 and K. Pithewan, "GMPLS Signaling Extensions for Control 762 of Evolving G.709 Optical Transport Networks", RFC 7139, 763 DOI 10.17487/RFC7139, March 2014, 764 . 766 10.2. Informative References 768 [I-D.izh-ccamp-flexe-fwk] 769 Hussain, I., Valiveti, R., Pithewan, K., Wang, Q., 770 Andersson, L., Zhang, F., Chen, M., Dong, J., Du, Z., 771 zhenghaomian@huawei.com, z., Zhang, X., Huang, J., and Q. 772 Zhong, "GMPLS Routing and Signaling Framework for Flexible 773 Ethernet (FlexE)", draft-izh-ccamp-flexe-fwk-00 (work in 774 progress), October 2016. 776 Authors' Addresses 778 Qilei Wang (editor) 779 ZTE 780 Nanjing 781 CN 783 Email: wang.qilei@zte.com.cn 785 Radha Valiveti (editor) 786 Infinera Corp 787 Sunnyvale 788 USA 790 Email: rvaliveti@infinera.com 792 Haomian Zheng (editor) 793 Huawei 794 CN 796 Email: zhenghaomian@huawei.com 798 Huub van Helvoort 799 Hai Gaoming B.V 801 Email: huubatwork@gmail.com 802 Sergio Belotti 803 Nokia 805 Email: sergio.belotti@nokia.com