idnits 2.17.1 draft-ietf-ccamp-gmpls-otn-b100g-applicability-03.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 (November 1, 2020) is 1271 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: May 5, 2021 Infinera Corp 6 H. Zheng, Ed. 7 Huawei 8 H. Helvoort 9 Hai Gaoming B.V 10 S. Belotti 11 Nokia 12 November 1, 2020 14 Applicability of GMPLS for B100G Optical Transport Network 15 draft-ietf-ccamp-gmpls-otn-b100g-applicability-03 17 Abstract 19 This document examines the applicability of using current existing 20 GMPLS routing and signalling mechanisms to set up ODUk (e.g., 21 ODUflex) LSP over ODUCn links, as defined in the 2016 version of 22 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 May 5, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 2. OTN terminology used in this document . . . . . . . . . . . . 3 60 3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 3 61 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Time Slot Granularity . . . . . . . . . . . . . . . . . . 7 65 3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 7 66 3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 8 67 4. GMPLS Implications and Applicability . . . . . . . . . . . . 9 68 4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 9 69 4.2. Implications and Applicability for GMPLS Signalling . . . 10 70 4.3. Implications and Applicability for GMPLS Routing . . . . 11 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 12 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 The current GMPLS routing [RFC7138] and signalling [RFC7139] 84 extensions support the control of OTN signals and capabilities that 85 were defined in the 2012 version of G.709 [ITU-T_G709_2012]. 87 In 2016 a new version of G.709 was published: [ITU-T_G709_2016]. 88 This version introduces new higher rate OTU and ODU signals, termed 89 OTUCn and ODUCn respectively, which have a nominal rate of n x 100 90 Gbit/s. According to the definition in G.709 [ITU-T_G709_2016], 91 OTUCn and ODUCn perform only section layer role and ODUCn supports 92 only ODUk clients. This document focuses on the use of existing 93 GMPLS mechanisms to set up ODUk (e.g., ODUflex) LSP over ODUCn links, 94 independently from how these links have been set up 95 This document presents an overview of the OTUCn and ODUCn signals 96 introduced in [ITU-T_G709_2016] and analyses how the current GMPLS 97 routing and signalling mechanisms can be utilized to setup ODUk 98 (e.g., ODUflex) LSPs over ODUCn links. 100 Note: after discussion, the authors did not see any impact of 2020 101 version of G.709 on this draft. 103 2. OTN terminology used in this document 105 a. OPUCn: Optical Payload Unit - Cn. Where Cn = number of n-bit 106 client data entities. 108 b. ODUCn: Optical Data Unit - Cn. 110 c. OTUCn: Fully standardized Optical Transport Unit - Cn. 112 d. OTUCn-M: This signal is an extension of the OTUCn signal 113 introduced above. This signal contains the same amount of 114 overhead as the OTUCn signal, but contains a reduced amount of 115 payload area. Specifically, the payload area consists of M 5G 116 tributary slots (where M is strictly less than 20*n). 118 e. PSI: OPU Payload Structure Indicator. This is a 256-byte signal 119 that describes the composition of the OPU signal. This field is 120 a concatenation of the Payload type (PT) and the Multiplex 121 Structure Indicator (MSI) defined below. 123 f. MSI: Multiplex Structure Indicator. This structure indicates the 124 grouping of the tributary slots in an OPU payload area that 125 realizes a client signal which is multiplexed into an OPU. The 126 individual clients multiplexed into the OPU payload area are 127 distinguished by the Tributary Port number (TPN). 129 Detailed description of these terms can be found in 130 [ITU-T_G709_2016]. 132 3. Overview of the OTUCn/ODUCn in G.709 134 This section provides an overview of OTUCn/ODUCn signals defined in 135 [ITU-T_G709_2016]. 137 3.1. OTUCn 139 In order to carry client signals with rates greater than 100 Gbit/s, 140 [ITU-T_G709_2016] takes a general and scalable approach that 141 decouples the rates of OTU signals from the client rate. The new OTU 142 signal is called OTUCn, and this signal is defined to have a rate of 143 (approximately) n*100G. The following are the key characteristics of 144 the OTUCn signal: 146 a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals 147 perform digital section roles only (see 148 [ITU-T_G709_2016]:Section 6.1.1) 150 b. The OTUCn signals can be viewed as being formed by interleaving n 151 OTUC signals (which are labeled 1, 2, ..., n), each of which has 152 the format of a standard OTUk signal without the FEC columns (per 153 [ITU-T_G709_2016]Figure 7-1). The ODUCn have a similar 154 structure, i.e. they can be seen as being formed by interleaving 155 n instances of ODUC signals (respectively). The OTUC signal 156 contains the ODUC signals, just as in the case of fixed rate OTUs 157 defined in G.709 [ITU-T_G709_2016]. 159 c. Each of the OTUC "slices" have the same overhead as the standard 160 OTUk signal in G.709 [ITU-T_G709_2016]. The combined signal 161 OTUCn has n instances of OTUC overhead, ODUC overhead. 163 d. The OTUC signal has a slightly higher rate compared to the OTU4 164 signal (without FEC); this is to ensure that the OPUC payload 165 area can carry an ODU4 signal. 167 As explained above, within G.709 [ITU-T_G709_2016], the OTUCn, ODUCn 168 and OPUCn signal structures are presented in a (physical) interface 169 independent manner, by means of n OTUC, ODUC and OPUC instances that 170 are marked #1 to #n. Specifically, the definition of the OTUCn 171 signal does not cover aspects such as FEC, modulation formats, etc. 172 These details are defined as part of the adaptation of the OTUCn 173 layer to the optical layer(s). The specific interleaving of 174 OTUC/ODUC/OPUC signals onto the optical signals is interface specific 175 and specified for OTN interfaces with standardized application codes 176 in the interface specific recommendations (G.709.x). 178 OTUCn interfaces can be categorized as follows, based on the type of 179 peer network element (see Figure 1): 181 a. inter-domain interfaces: These types of interfaces are used for 182 connecting OTN edge nodes to (a) client equipment (e.g. routers) 183 or (b) hand-off points from other OTN networks. ITU-T has 184 standardized the Flexible OTN (FlexO) interfaces to support these 185 functions. For example, Recommendation [ITU-T_G709.1] specifies 186 a flexible interoperable short-reach OTN interface over which an 187 OTUCn (n >=1) is transferred, using bonded FlexO interfaces which 188 belong to a FlexO group. 190 b. intra-domain interfaces: In these cases, the OTUCn is transported 191 using a proprietary (vendor specific) encapsulation, FEC etc. It 192 may also be possible to transport OTUCn for intra-domain links 193 using FlexO. 195 ================================================================== 197 +--------------------------------------------------------+ 198 | OTUCn signal | 199 +--------------------------------------------------------+ 200 | Inter+Domain | Intra+Domain | Intra+Domain | 201 | Interface (IrDI)| Interface (IaDI)| Interface | 202 | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | 203 | | (Future) | Encap, FEC etc. | 204 +--------------------------------------------------------+ 206 ================================================================== 208 Figure 1: OTUCn transport possibilities 210 3.1.1. OTUCn-M 212 The standard OTUCn signal has the same rate as that of the ODUCn 213 signal as shown in Table 1. This implies that the OTUCn signal can 214 only be transported over wavelength groups which have a total 215 capacity of multiples of (approximately) 100G. Modern DSPs support a 216 variety of bit rates per wavelength, depending on the reach 217 requirements for the optical path. In other words, it is possible to 218 extend the reach of an optical path (i.e. increase the physical 219 distance covered) by lowering the bitrate of the digital signal that 220 is modulated onto the optical signals. If the total rate of the ODUk 221 LSPs planned to be carried over an ODUCn link is smaller than n*100G, 222 it is possible to "crunch" the OTUCn not to transmit some of unused 223 timeslots. With this in mind, ITU-T supports the notion of a reduced 224 rate OTUCn signal, termed the OTUCn-M. The OTUCn-M signal is derived 225 from the OTUCn signal by retaining all the n instances of overhead 226 (one per OTUC slice) but with only M (M is less than 20*n) OPUCn 227 tributary slots available to carry ODUk LSPs. 229 As the "crunching" algorithm is not standardized, knowing the value 230 of M is not enough to decide the timeslot availability. 232 3.2. ODUCn 234 The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by 235 the appropriate interleaving of content from n ODUC signal instances. 236 The ODUC frames have the same structure as a standard ODU -- in the 237 sense that it has the same Overhead area, and the payload area -- but 238 has a higher rate since its payload area can embed an 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_2016] 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_2016] G.709: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_2016]. 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 One thing should be note is the TPN used in RFC7139 and defined in 426 G.709-2016 for ODUCn link. Since the TPN currently defined in G.709 427 for ODUCn link has 14 bits, while this field in RFC7139 only has 12 428 bits, some extension work is needed, but this is not so urgent since 429 for today networks scenarios 12 bits are enough, as it can support a 430 single ODUCn link up to n=400, namely 40 Tbit/s. 432 An example is given below to illustrate the label format defined in 433 RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G 434 slots, and twenty of them are allocated to the ODU4. Along with the 435 increase of "n", the label may become lengthy, an optimized label 436 format may be needed. 438 ================================================================== 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | TPN = 3 | Reserved | Length = 200 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |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| 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |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| 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |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| 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |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| 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |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| 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |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| 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |0 0 0 0 0 0 0 0| Padding Bits(0) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 ================================================================== 462 Figure 5: Label format 464 4.3. Implications and Applicability for GMPLS Routing 466 For routing, it is deemed that no extension to current mechanisms 467 defined in RFC7138 are needed. Because, once an ODUCn link is up, 468 the resources that need to be advertised are the resources that 469 exposed by this ODUCn link and the multiplexing hierarchy on this 470 link. Since the ODUCn link is the ultimate hierarchy of the ODU 471 multiplexing, there is no need to explicitly define a new value to 472 represent the ODUCn signal type in the OSPF-TE routing 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 551 8. IANA Considerations 553 This memo includes no request to IANA. 555 9. Security Considerations 557 None. 559 10. References 561 10.1. Normative References 563 [ITU-T_G709_2012] 564 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 565 02/2012", http://www.itu.int/rec/T-REC- 566 G..709-201202-S/en, February 2012. 568 [ITU-T_G709_2016] 569 ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 570 07/2016", http://www.itu.int/rec/T-REC- 571 G..709-201606-P/en, July 2016. 573 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 574 J. Drake, "Traffic Engineering Extensions to OSPF for 575 GMPLS Control of Evolving G.709 Optical Transport 576 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 577 . 579 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 580 and K. Pithewan, "GMPLS Signaling Extensions for Control 581 of Evolving G.709 Optical Transport Networks", RFC 7139, 582 DOI 10.17487/RFC7139, March 2014, 583 . 585 10.2. Informative References 587 [ITU-T_G709.1] 588 ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 589 2016", , 2016. 591 Authors' Addresses 593 Qilei Wang (editor) 594 ZTE Corporation 595 Nanjing 596 China 598 Email: wang.qilei@zte.com.cn 599 Radha Valiveti (editor) 600 Infinera Corp 601 Sunnyvale 602 USA 604 Email: rvaliveti@infinera.com 606 Haomian Zheng (editor) 607 Huawei 608 China 610 Email: zhenghaomian@huawei.com 612 Huub van Helvoort 613 Hai Gaoming B.V 614 Almere 615 Netherlands 617 Email: huubatwork@gmail.com 619 Sergio Belotti 620 Nokia 622 Email: sergio.belotti@nokia.com