idnits 2.17.1 draft-ietf-ccamp-gmpls-otn-b100g-applicability-07.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 (June 14, 2021) is 1040 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Corporation 4 Intended status: Informational R. Valiveti, Ed. 5 Expires: December 16, 2021 Infinera Corp 6 H. Zheng, Ed. 7 Huawei 8 H. Helvoort 9 Hai Gaoming B.V 10 S. Belotti 11 Nokia 12 June 14, 2021 14 Applicability of GMPLS for B100G Optical Transport Network 15 draft-ietf-ccamp-gmpls-otn-b100g-applicability-07 17 Abstract 19 This document examines the applicability of using existing GMPLS 20 routing and signalling mechanisms to set up ODUk (e.g., ODUflex) LSP 21 over ODUCn links, as defined in the 2020 version of G.709. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 16, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. OTN terminology used in this document . . . . . . . . . . . . 3 59 3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 3 60 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Time Slot Granularity . . . . . . . . . . . . . . . . . . 7 64 3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 7 65 3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 8 66 4. GMPLS Implications and Applicability . . . . . . . . . . . . 9 67 4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 9 68 4.2. Implications and Applicability for GMPLS Signalling . . . 10 69 4.3. Implications and Applicability for GMPLS Routing . . . . 11 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 12 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 10.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 The current GMPLS routing [RFC7138] and signalling [RFC7139] 83 extensions support the control of OTN signals and capabilities that 84 were defined in the 2012 version of G.709 [ITU-T_G709_2012]. 86 In 2016 a new version of G.709 was published: [ITU-T_G709_2016]. 87 This version introduces new higher rate OTU and ODU signals, termed 88 OTUCn and ODUCn respectively, which have a nominal rate of n x 100 89 Gbit/s. According to the definition in [ITU-T_G709_2016], OTUCn and 90 ODUCn perform only section layer role and ODUCn supports only ODUk 91 clients. This document focuses on the use of existing GMPLS 92 mechanisms to set up ODUk (e.g., ODUflex) LSP over ODUCn links, 93 independently from how these links have been set up. 95 Since the [ITU-T_G709_2020] does not introduce any new features to 96 OTUCn and ODUCn comparing to [ITU-T_G709_2016], this document starts 97 with [ITU-T_G709_2020] by first presenting an overview of the OTUCn 98 and ODUCn signals, and then analysing how the current GMPLS routing 99 and signalling mechanisms can be utilized to setup ODUk (e.g., 100 ODUflex) LSPs over ODUCn links. 102 2. OTN terminology used in this document 104 a. OPUCn: Optical Payload Unit - Cn. Where Cn indicates that the 105 bit rate is approximately n*100G. 107 b. ODUCn: Optical Data Unit - Cn. 109 c. OTUCn: Fully standardized Optical Transport Unit - Cn. 111 d. OTUCn-M: This signal is an extension of the OTUCn signal 112 introduced above. This signal contains the same amount of 113 overhead as the OTUCn signal, but contains a reduced amount of 114 payload area. Specifically, the payload area consists of M 5G 115 tributary slots (where M is strictly less than 20*n). 117 e. PSI: OPU Payload Structure Indicator. This is a 256-byte signal 118 that describes the composition of the OPU signal. This field is 119 a concatenation of the Payload type (PT) and the Multiplex 120 Structure Indicator (MSI) defined below. 122 f. MSI: Multiplex Structure Indicator. This structure indicates the 123 grouping of the tributary slots in an OPU payload area that 124 realizes a client signal which is multiplexed into an OPU. The 125 individual clients multiplexed into the OPU payload area are 126 distinguished by the Tributary Port number (TPN). 128 Detailed description of these terms can be found in 129 [ITU-T_G709_2020]. 131 3. Overview of the OTUCn/ODUCn in G.709 133 This section provides an overview of OTUCn/ODUCn signals defined in 134 [ITU-T_G709_2020]. 136 3.1. OTUCn 138 In order to carry client signals with rates greater than 100 Gbit/s, 139 [ITU-T_G709_2020] takes a general and scalable approach that 140 decouples the rates of OTU signals from the client rate. The new OTU 141 signal is called OTUCn, and this signal is defined to have a rate of 142 (approximately) n*100G. The following are the key characteristics of 143 the OTUCn signal: 145 a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals 146 perform digital section roles only (see 147 [ITU-T_G709_2020]:Section 6.1.1) 149 b. The OTUCn signals can be viewed as being formed by interleaving n 150 OTUC signals (which are labeled 1, 2, ..., n), each of which has 151 the format of a standard OTUk signal without the FEC columns (per 152 [ITU-T_G709_2020] Figure 7-1). The ODUCn have a similar 153 structure, i.e. they can be seen as being formed by interleaving 154 n instances of ODUC signals (respectively). The OTUC signal 155 contains the ODUC signals, just as in the case of fixed rate OTUs 156 defined in [ITU-T_G709_2020]. 158 c. Each of the OTUC "slices" have the same overhead as the standard 159 OTUk signal in [ITU-T_G709_2020]. The combined signal OTUCn has 160 n instances of OTUC overhead, ODUC overhead. 162 d. The OTUC signal has a slightly higher rate compared to the OTU4 163 signal (without FEC); this is to ensure that the OPUC payload 164 area can carry an ODU4 signal. 166 As explained above, within [ITU-T_G709_2020], the OTUCn, ODUCn and 167 OPUCn signal structures are presented in a (physical) interface 168 independent manner, by means of n OTUC, ODUC and OPUC instances that 169 are marked #1 to #n. Specifically, the definition of the OTUCn 170 signal does not cover aspects such as FEC, modulation formats, etc. 171 These details are defined as part of the adaptation of the OTUCn 172 layer to the optical layer(s). The specific interleaving of 173 OTUC/ODUC/OPUC signals onto the optical signals is interface specific 174 and specified for OTN interfaces with standardized application codes 175 in the interface specific recommendations (G.709.x). 177 OTUCn interfaces can be categorized as follows, based on the type of 178 peer network element (see Figure 1): 180 a. inter-domain interfaces: These types of interfaces are used for 181 connecting OTN edge nodes to (a) client equipment (e.g. routers) 182 or (b) hand-off points from other OTN networks. ITU-T has 183 standardized the Flexible OTN (FlexO) interfaces to support these 184 functions. For example, Recommendation [ITU-T_G709.1] specifies 185 a flexible interoperable short-reach OTN interface over which an 186 OTUCn (n >=1) is transferred, using bonded FlexO interfaces which 187 belong to a FlexO group. 189 b. intra-domain interfaces: In these cases, the OTUCn is transported 190 using a proprietary (vendor specific) encapsulation, FEC etc. It 191 may also be possible to transport OTUCn for intra-domain links 192 using FlexO. 194 ================================================================== 196 +--------------------------------------------------------+ 197 | OTUCn signal | 198 +--------------------------------------------------------+ 199 | Inter+Domain | Intra+Domain | Intra+Domain | 200 | Interface (IrDI)| Interface (IaDI)| Interface | 201 | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | 202 | | (Future) | Encap, FEC etc. | 203 +--------------------------------------------------------+ 205 ================================================================== 207 Figure 1: OTUCn transport possibilities 209 3.1.1. OTUCn-M 211 The standard OTUCn signal has the same rate as that of the ODUCn 212 signal as shown in Table 1. This implies that the OTUCn signal can 213 only be transported over wavelength groups which have a total 214 capacity of multiples of (approximately) 100G. Modern DSPs support a 215 variety of bit rates per wavelength, depending on the reach 216 requirements for the optical path. In other words, it is possible to 217 extend the reach of an optical path (i.e. increase the physical 218 distance covered) by lowering the bitrate of the digital signal that 219 is modulated onto the optical signals. If the total rate of the ODUk 220 LSPs planned to be carried over an ODUCn link is smaller than n*100G, 221 it is possible to "crunch" the OTUCn not to transmit some of unused 222 timeslots. With this in mind, ITU-T supports the notion of a reduced 223 rate OTUCn signal, termed the OTUCn-M. The OTUCn-M signal is derived 224 from the OTUCn signal by retaining all the n instances of overhead 225 (one per OTUC slice) but with only M (M is less than 20*n) OPUCn 226 tributary slots available to carry ODUk LSPs. 228 As the "crunching" algorithm is not standardized, knowing the value 229 of M is not enough to decide the timeslot availability. 231 3.2. ODUCn 233 The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being 234 formed by the appropriate interleaving of content from n ODUC signal 235 instances. The ODUC frames have the same structure as a standard ODU 236 -- in the sense that it has the same Overhead area, and the payload 237 area -- but has a higher rate since its payload area can embed an 238 ODU4 signal. 240 The ODUCn signals have a rate that is captured in Table 1. 242 +----------+--------------------------------------------------------+ 243 | ODU Type | ODU Bit Rate | 244 +----------+--------------------------------------------------------+ 245 | ODUCn | n x 239/226 x 99,532,800 Kbit/s = n x 105,258,138.053 | 246 | | Kbit/s | 247 +----------+--------------------------------------------------------+ 249 Table 1: ODUCn rates 251 The ODUCn is a multiplex section ODU signal, and is mapped into an 252 OTUCn signal which provides the regenerator section layer. In some 253 scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e. 254 they will have identical source/sink locations. [ITU-T_G709_2020] 255 allows for the ODUCn signal to pass through a digital regenerator 256 node which will terminate the OTUCn layer, but will pass the 257 regenerated (but otherwise untouched) ODUCn towards a different OTUCn 258 interface where a fresh OTUCn layer will be initiated (see Figure 2). 259 In this case, the ODUCn is carried by 3 OTUCn segments. 261 Specifically, the OPUCn signal flows through these regenerators 262 unchanged. That is, the set of client signals, their TPNs, trib-slot 263 allocation remains unchanged. The ODUCn Overhead might be modified 264 if TCM sub-layers are instantiated in order to monitor the 265 performance of the regenerator hops. In this sense, the ODUCn should 266 NOT be seen as a general ODU which can be switched via an ODUk cross- 267 connect. 269 ================================================================== 271 +--------+ +--------+ 272 | +-----------+ | 273 | OTN |-----------| OTN | 274 | DXC +-----------+ DXC + 275 | | | | 276 +--------+ +--------+ 277 <--------ODUCn-------> 278 <-------OTUCn------> 280 +--------+ +--------+ +--------+ +--------+ 281 | +--------+ | | +----------+ | 282 | OTN |--------| OTN | | OTN |----------| OTN | 283 | DXC +--------+ WXC +--------+ WXC +----------+ DXC | 284 | | | 3R | | 3R | | | 285 +--------+ +--------+ +--------+ +--------+ 286 <-------------------------ODUCn--------------------------> 287 <---------------> <---------------> <------------------> 288 OTUCn OTUCn OTUCn 290 ================================================================== 292 Figure 2: ODUCn signal 294 3.3. Time Slot Granularity 296 [ITU-T_G709_2012] has introduced the support for 1.25G granular 297 tributary slots in OPU2, OPU3, and OPU4 signals. With the 298 introduction of higher rate signals, it is not practical for the 299 optical networks (and the data plane hardware) to support a very 300 large number of connections at such a fine granularity. [ITU- 301 T_G709_2012] has defined the OPUC with a 5G tributary slot 302 granularity. This means that the ODUCn signal has 20*n tributary 303 slots (of 5 Gbit/s capacity). It is worthwhile considering that the 304 range of tributary port number (TPN) is 10*n instead of 20*n, which 305 restricts the maximum client signals that could be carried over one 306 single ODUC1. 308 3.4. Structure of OPUCn MSI with Payload type 0x22 310 As mentioned above, the OPUCn signal has 20*n 5G tributary slots. 311 The OPUCn MSI field has a fixed length of 40*n bytes and indicates 312 the availability and occupation of each TS. Two bytes are used for 313 each of the 20*n tributary slots, and each such information structure 314 has the following format ([ITU-T_G709_2020]:Section 20.4.1): 316 a. The TS availability bit indicates if the tributary slot is 317 available or unavailable 319 b. The TS occupation bit indicates if the tributary slot is 320 allocated or unallocated 322 c. The tributary port number (14 bits) of the client signal that is 323 being carried in this specific TS. A flexible assignment of 324 tributary port to tributary slots is possible. Numbering of 325 tributary ports is from 1 to 10*n. 327 3.5. Client Signal Mappings 329 The approach taken by the ITU-T to map non-OTN client signals to the 330 appropriate ODU containers is as follows: 332 a. All client signals are mapped into an ODUk (e.g., ODUflex) as 333 specified in clause 17 of [ITU-T_G709_2020]. 335 b. ODU Virtual Concatenation has been deprecated. This simplifies 336 the network, and the supporting hardware since multiple different 337 mappings for the same client are no longer necessary. Note that 338 legacy implementations that transported sub-100G clients using 339 ODU VCAT shall continue to be supported. 341 c. ODUflex signals are low-order signals only. If the ODUflex 342 entities have rates of 100G or less, they can be transported over 343 either an ODUk (k=1..4) or an ODUCn. For ODUflex connections 344 with rates greater than 100G, ODUCn is required. 346 ================================================================== 348 Clients (e.g. SONET/SDH, Ethernet) 349 + + + 350 | | | 351 +------------------+-------+------+------------------------+ 352 | OPUk | 353 +----------------------------------------------------------+ 354 | ODUk | 355 +-----------------------+---------------------------+------+ 356 | OTUk, OTUk.V, OTUkV | OPUk | | 357 +----------+----------------------------------------+ | 358 | OTLk.n | | ODUk | | 359 +----------+ +---------------------+-----+ | 360 | OTUk, OTUk.V, OTUkV | OPUCn | 361 +----------+-----------------------+ 362 | OTLk.n | | ODUCn | 363 +----------+ +------------+ 364 | OTUCn | 365 +------------+ 367 ================================================================== 369 Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 371 4. GMPLS Implications and Applicability 373 4.1. TE-Link Representation 375 Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with 376 TE-Links in GMPLS. Similar to that, ODUCn links can also be 377 represented as TE-Links, which can be seen in the figure below. 379 ================================================================== 381 +-----+ +-----+ 382 | | | | 383 | A |<-OTUCn Link->| B | 384 | | | | 385 +-----+ +-----+ 386 |<--- ODUCn Link -->| 387 |<---- TE-Link ---->| 389 3R 3R 390 +-----+ +-----+ +-----+ +-----+ 391 | | | | | | | | 392 | A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D | 393 | | | | | | | | 394 +-----+ +-----+ +-----+ +-----+ 395 |<----------------------- ODUCn Link ------------------------>| 396 |<------------------------ TE-Link -------------------------->| 398 ================================================================== 400 Figure 4: ODUCn TE-Links 402 Two endpoints of a TE-Link are configured with the supported resource 403 information, which may include whether the TE-Link is supported by an 404 ODUCn or an ODUk or an OTUk, as well as the link attribute 405 information (e.g., slot granularity, list of available tributary 406 slot). 408 4.2. Implications and Applicability for GMPLS Signalling 410 Once the ODUCn TE-Link is configured, the GMPLS mechanisms defined in 411 RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes. 412 As the resource on the ODUCn link which can be seen by the client 413 ODUk/ODUflex is a set of 5G slots, the label defined in RFC7139 is 414 able to accommodate the requirement of the setup of ODUk/ODUflex over 415 ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is 416 used to indicate how the LO ODUj signal is multiplexed into the HO 417 ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object 418 is used to indicate how the ODUk signal is multiplexed into the ODUCn 419 link. The ODUk Signal Type is indicated by Traffic Parameters. The 420 IF_ID RSVP_HOP object provides a pointer to the interface associated 421 with TE-Link and therefore the two nodes terminating the TE-link know 422 (by internal/local configuration) the attributes of the ODUCn TE 423 Link. 425 Since the TPN currently defined in G.709 for ODUCn link has 14 bits, 426 while this field in RFC7139 only has 12 bits, some extension work is 427 needed. Given that a 12-bit TPN field can support ODUCn links with 428 up to n=400 (i.e. 40Tbit/s links), this extension is not urgently 429 needed. 431 An example is given below to illustrate the label format defined in 432 RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G 433 slots, and twenty of them are allocated to the ODU4. Along with the 434 increase of "n", the label may become lengthy, an optimized label 435 format may be needed. 437 ================================================================== 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | TPN = 3 | Reserved | Length = 200 | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |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| 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |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| 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |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| 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |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| 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |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| 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 |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| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |0 0 0 0 0 0 0 0| Padding Bits(0) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 ================================================================== 461 Figure 5: Label format 463 4.3. Implications and Applicability for GMPLS Routing 465 For routing, it is deemed that no extension to current mechanisms 466 defined in RFC7138 are needed. Because, once an ODUCn link is up, 467 the resources that need to be advertised are the resources that 468 exposed by this ODUCn link and the multiplexing hierarchy on this 469 link. Since the ODUCn link is the lowest layer of the ODU 470 multiplexing hierarchy, there is no need to explicitly define a new 471 value to represent the ODUCn signal type in the OSPF-TE routing 472 protocol. 474 The OSPF-TE extension defined in section 4 of RFC7138 can be reused 475 to advertise the resource information on the ODUCn link to help 476 finish the setup of ODUk/ODUflex. 478 5. Acknowledgements 480 6. Authors (Full List) 482 Qilei Wang (editor) 484 ZTE 486 Nanjing, China 488 Email: wang.qilei@zte.com.cn 490 Radha Valiveti (editor) 492 Infinera Corp 494 Sunnyvale, CA, USA 496 Email: rvaliveti@infinera.com 498 Haomian Zheng (editor) 500 Huawei 502 CN 504 EMail: zhenghaomian@huawei.com 506 Huub van Helvoort 508 Hai Gaoming B.V 509 EMail: huubatwork@gmail.com 511 Sergio Belotti 513 Nokia 515 EMail: sergio.belotti@nokia.com 517 Iftekhar Hussain 519 Infinera Corp 521 Sunnyvale, CA, USA 523 Email: IHussain@infinera.com 525 Daniele Ceccarelli 527 Ericsson 529 Email: daniele.ceccarelli@ericsson.com 531 7. Contributors 533 Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com 535 Fatai Zhang, Huawei,zhangfatai@huawei.com 537 Italo Busi, Huawei,italo.busi@huawei.com 539 Dieter Beller, Nokia, Dieter.Beller@nokia.com 541 Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn 543 Zafar Ali, Cisco Systems, zali@cisco.com 545 Daniel King, d.king@lancaster.ac.uk 547 Manoj Kumar, Cisco Systems, manojk2@cisco.com 549 Antonello Bonfanti, Cisco Systems, abonfant@cisco.com 550 Yuji Tochio, Fujitsu, tochio@fujitsu.com 552 8. IANA Considerations 554 This memo includes no request to IANA. 556 9. Security Considerations 558 None. 560 10. References 562 10.1. Normative References 564 [ITU-T_G709_2020] 565 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 566 06/2020", https://www.itu.int/rec/T-REC- 567 G.709-202006-I/en, June 2020. 569 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 570 J. Drake, "Traffic Engineering Extensions to OSPF for 571 GMPLS Control of Evolving G.709 Optical Transport 572 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 573 . 575 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 576 and K. Pithewan, "GMPLS Signaling Extensions for Control 577 of Evolving G.709 Optical Transport Networks", RFC 7139, 578 DOI 10.17487/RFC7139, March 2014, 579 . 581 10.2. Informative References 583 [ITU-T_G709.1] 584 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 585 2018", , 2018. 587 [ITU-T_G709_2012] 588 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 589 02/2012", http://www.itu.int/rec/T-REC- 590 G..709-201202-S/en, February 2012. 592 [ITU-T_G709_2016] 593 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 594 07/2016", http://www.itu.int/rec/T-REC- 595 G..709-201606-P/en, July 2016. 597 Authors' Addresses 599 Qilei Wang (editor) 600 ZTE Corporation 601 Nanjing 602 China 604 Email: wang.qilei@zte.com.cn 606 Radha Valiveti (editor) 607 Infinera Corp 608 Sunnyvale 609 USA 611 Email: rvaliveti@infinera.com 613 Haomian Zheng (editor) 614 Huawei 615 China 617 Email: zhenghaomian@huawei.com 619 Huub van Helvoort 620 Hai Gaoming B.V 621 Almere 622 Netherlands 624 Email: huubatwork@gmail.com 626 Sergio Belotti 627 Nokia 629 Email: sergio.belotti@nokia.com