idnits 2.17.1 draft-ietf-ccamp-optical-impairment-topology-yang-06.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 is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 625: '...ting. Each mode MUST follow only one ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 969 has weird spacing: '...variety str...' == Line 996 has weird spacing: '...variety str...' == Line 1005 has weird spacing: '...ro loss dec...' == Line 1009 has weird spacing: '...roup-id int...' == Line 1020 has weird spacing: '...nder-id uin...' == (2 more instances...) -- The document date (February 22, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 187, but not defined == Missing Reference: 'RFC3688' is mentioned on line 2591, but not defined == Unused Reference: 'I-D.ietf-ccamp-wson-yang' is defined on line 2695, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-layer0-types' is defined on line 2701, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-dwdm-if-param-yang-05 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Y. Lee 3 Internet-Draft SKKU (Sung Kyun Kwan University) 4 Intended status: Standards Track JL. Auge 5 Expires: August 26, 2021 Orange 6 V. Lopez 7 Telefonica 8 G. Galimberti 9 Cisco 10 D. Beller 11 Nokia 12 February 22, 2021 14 A YANG Data Model for Optical Impairment-aware Topology 15 draft-ietf-ccamp-optical-impairment-topology-yang-06 17 Abstract 19 In order to provision an optical connection through optical networks, 20 a combination of path continuity, resource availability, and 21 impairment constraints must be met to determine viable and optimal 22 paths through the network. The determination of appropriate paths is 23 known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) 24 for WSON, while it is known as Impairment-Aware Routing and Spectrum 25 Assigment (IA-RSA) for SSON. 27 This document provides a YANG data model for the impairment-aware TE 28 topology in optical networks. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 26, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 68 2. Reference Architecture . . . . . . . . . . . . . . . . . . . 5 69 2.1. Control Plane Architecture . . . . . . . . . . . . . . . 5 70 2.2. Transport Data Plane . . . . . . . . . . . . . . . . . . 6 71 2.3. OMS Media Links . . . . . . . . . . . . . . . . . . . . . 7 72 2.3.1. Optical Tributary Signal (OTSi) . . . . . . . . . . . 8 73 2.3.2. Optical Tributary Signal Group (OTSiG) . . . . . . . 8 74 2.3.3. Media Channel (MC) . . . . . . . . . . . . . . . . . 9 75 2.3.4. Media Channel Group (MCG) . . . . . . . . . . . . . . 10 76 2.4. Amplifiers . . . . . . . . . . . . . . . . . . . . . . . 11 77 2.5. Transponders . . . . . . . . . . . . . . . . . . . . . . 12 78 2.5.1. Standard Modes . . . . . . . . . . . . . . . . . . . 12 79 2.5.2. Organizational Modes . . . . . . . . . . . . . . . . 13 80 2.5.3. Explicit Modes . . . . . . . . . . . . . . . . . . . 14 81 2.5.4. Transponder Capabilities and Current Configuration . 15 82 2.6. WSS/Filter . . . . . . . . . . . . . . . . . . . . . . . 16 83 2.7. Optical Fiber . . . . . . . . . . . . . . . . . . . . . . 16 84 2.8. ROADM Node Architectures . . . . . . . . . . . . . . . . 16 85 2.8.1. Integrated ROADM Architecture with Integrated Optical 86 Transponders . . . . . . . . . . . . . . . . . . . . 17 87 2.8.2. Integrated ROADMs with Integrated Optical 88 Transponders and Single Channel Add/Drop Interfaces 89 for Remote Optical Transponders . . . . . . . . . . . 18 90 2.8.3. Disaggregated ROADMs Subdivided into Degree, 91 Add/Drop, and Optical Transponder Subsystems . . . . 19 92 2.8.4. Optical Impairments Imposed by ROADM Nodes . . . . . 20 93 3. YANG Model (Tree Structure) . . . . . . . . . . . . . . . . . 22 94 4. Optical Impairment Topology YANG Model . . . . . . . . . . . 27 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 56 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 97 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 57 100 8.2. Informative References . . . . . . . . . . . . . . . . . 57 101 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 59 102 Appendix B. Additional Authors . . . . . . . . . . . . . . . . . 59 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 105 1. Introduction 107 In order to provision an optical connection (an optical path) through 108 a wavelength switched optical networks (WSONs) or spectrum switched 109 optical networks (SSONs), a combination of path continuity, resource 110 availability, and impairment constraints must be met to determine 111 viable and optimal paths through the network. The determination of 112 appropriate paths is known as Impairment-Aware Routing and Wavelength 113 Assignment (IA-RWA) [RFC6566] for WSON, while it is known as IA- 114 Routing and Spectrum Assigment (IA-RSA) for SSON. 116 This document provides a YANG data model for the impairment-aware 117 Traffic Engineering (TE) topology in WSONs and SSONs. The YANG model 118 described in this document is a WSON/SSON technology-specific Yang 119 model based on the information model developed in [RFC7446] and the 120 two encoding documents [RFC7581] and [RFC7579] that developed 121 protocol independent encodings based on [RFC7446]. 123 The intent of this document is to provide a YANG data model, which 124 can be utilized by a Multi-Domain Service Coordinator (MDSC) to 125 collect states of WSON impairment data from the Transport PNCs to 126 enable impairment-aware optical path computation according to the 127 ACTN Architecture [RFC8453]. The communication between controllers 128 is done via a NETCONF [RFC8341] or a RESTCONF [RFC8040]. 129 Similarly,this model can also be exported by the MDSC to a Customer 130 Network Controller (CNC), which can run an offline planning process 131 to map latter the services in the network. 133 It is worth noting that optical data plane interoperability is a 134 complex topic especially in a multi vendor environment and usually 135 requires joint engineering, which is independent from control plane 136 and management plane capabilities. The YANG data model defined in 137 this draft is providing sufficient information to enable optical 138 impairment aware path computation. 139 Optical data plane interoperability is outside the scope of this 140 draft. 142 This document augments the generic TE topology draft [RFC8795] where 143 possible. 145 This document defines one YANG module: ietf-optical-impairment- 146 topology (Section 3) according to the new Network Management 147 Datastore Architecture [RFC8342]. 149 1.1. Terminology 151 Refer to [RFC6566], [RFC7698], and [G.807] for the key terms used in 152 this document. 154 The following terms are defined in [RFC7950] and are not redefined 155 here: 157 o client 158 o server 159 o augment 160 o data model 161 o data node 163 The following terms are defined in [RFC6241] and are not redefined 164 here: 166 o configuration data 167 o state data 169 The terminology for describing YANG data models is found in 170 [RFC7950]. 172 1.2. Tree Diagram 174 A simplified graphical representation of the data model is used in 175 Section 2 of this this document. The meaning of the symbols in these 176 diagrams is defined in [RFC8340]. 178 1.3. Prefixes in Data Node Names 180 In this document, names of data nodes and other data model objects 181 are prefixed using the standard prefix associated with the 182 corresponding YANG imported modules, as shown in Table 1. 184 +--------------+--------------------------+-------------------------+ 185 | Prefix | YANG module | Reference | 186 +--------------+--------------------------+-------------------------+ 187 | optical-imp- | ietf-optical-impairment- | [RFCXXXX] | 188 | topo | topology | | 189 | layer0-types | ietf-layer0-types | [I-D.ietf-ccamp-layer0- | 190 | | | types] | 191 | nw | ietf-network | [RFC8345] | 192 | nt | ietf-network-topology | [RFC8345] | 193 | tet | ietf-te-topology | [RFC8795] | 194 +--------------+--------------------------+-------------------------+ 196 Table 1: Prefixes and corresponding YANG modules 198 [Editor's note: The RFC Editor will replace XXXX with the number 199 assigned to the RFC once this draft becomes an RFC.] 201 2. Reference Architecture 203 2.1. Control Plane Architecture 205 Figure 1 shows the control plane architecture. 207 +--------+ 208 | MDSC | 209 +--------+ 210 Scope of this ID -------> || 211 | || 212 | +------------------------+ 213 | | OPTICAL | 214 +---------+ | | DOMAIN | +---------+ 215 | Device | | | CONTROLLER | | Device | 216 | config. | | +------------------------+ | config. | 217 +---------+ v // || \\ +---------+ 218 ______|______ // || \\ ______|______ 219 / OT \ // || \\ / OT \ 220 | +--------+ |// __--__ \\| +--------+ | 221 | |Vend. A |--|----+ ( ) +----|--| Vend. A| | 222 | +--------+ | | ~-( )-~ | | +--------+ | 223 | +--------+ | +---/ \---+ | +--------+ | 224 | |Vend. B |--|--+ / \ +--|--| Vend. B| | 225 | +--------+ | +---( OLS Segment )---+ | +--------+ | 226 | +--------+ | +---( )---+ | +--------+ | 227 | |Vend. C |--|--+ \ / +--|--| Vend. C| | 228 | +--------+ | +---\ /---+ | +--------+ | 229 | +--------+ | | ~-( )-~ | | +--------+ | 230 | |Vend. D |--|----+ (__ __) +----|--| Vend. D| | 231 | +--------+ | -- | +--------+ | 232 \_____________/ \_____________/ 233 ^ ^ 234 | | 235 | | 236 Scope of [I-D.ietf-ccamp-dwdm-if-param-yang] 238 Figure 1: Scope of draft-ietf-ccamp-dwdm-if-param-yang 240 The models developed in this document is an abstracted YANG model 241 that may be used in the interfaces between the MDSC and the Optical 242 Domain Controller (aka MPI) and between the Optical Domain Controller 243 and the Optical Device (aka SBI) in Figure 1. It is not intended to 244 support a detailed low-level DWDM interface model. DWDM interface 245 model is supported by the models presented in 246 [I-D.ietf-ccamp-dwdm-if-param-yang]. 248 2.2. Transport Data Plane 250 This section provides the description of the reference optical 251 network architecture and its relevant components to support optical 252 impairment-aware path computation. 254 Figure 2 shows the reference architecture. 256 +-------------------+ +-------------------+ 257 | ROADM Node | | ROADM Node | 258 | | | | 259 | PA +-------+ BA | ILA | PA +-------+ BA | 260 | +-+ | WSS/ | +-+ | _____ +--+ _____ | +-+ | WSS/ | +-+ | 261 --|-| |-|Filter |-| |-|-()____)-| |-()____)-|-| |-|Filter |-| |-|-- 262 | +-+ | | +-+ | +--+ | +-+ | | +-+ | 263 | +-------+ | optical | +-------+ | 264 | | | | | fiber | | | | | 265 | o o o | | o o o | 266 | transponders | | transponders | 267 +-------------------+ +-------------------+ 268 OTS Link OTS Link 269 <---------> <---------> 270 OMS Link 271 <--------------------------------> 273 PA: Pre-Amplifieror 274 BA: Booster Amplifier 275 ILA: In-Line Amplifier 277 Figure 2: Reference Architecture for Optical Transport Network 279 BA (on the left side ROADM) is the ingress Amplifier and PA (on the 280 right side ROADM is the egress amplifier for the OMS link shown in 281 Figure 2. 283 2.3. OMS Media Links 285 According to [G.872], OMS Media Link represents a media link between 286 two ROADMs. Specifically, it originates at the ROADM's Filter in the 287 source ROADM and terminates at the ROADM's Filter in the destination 288 ROADM. 290 OTS Media Link represents a media link: 292 (i) between ROADM's BA and ILA; 293 (ii) between a pair of ILAs; 294 (iii) between ILA and ROADM's PA. 296 OMS Media link can be decomposed in a sequence of OTS links type (i), 297 (ii), and (iii) as discussed above. OMS Media link would give an 298 abstracted view of impairment data (e.g., power, OSNR, etc.) to the 299 network controller. 301 For the sake of optical impairment evaluation OMS Media link can be 302 also decomposed in a sequence of elements such as BA, fiber section, 303 ILA, concentrated loss and PA. 305 [Editor's note: text below related to [G.807] needs to be revised! 306 [G.807] is now in publication process.] 308 2.3.1. Optical Tributary Signal (OTSi) 310 The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4 311 [G.959.1]. The YANG model defined below assumes that a single OTSi 312 consists of a single modulated optical carrier. This single 313 modulated optical carrier conveys digital information. 314 Characteristics of the OTSi signal are modulation scheme (e.g. QPSK, 315 8-QAM, 16-QAM, etc.), baud rate (measure of the symbol rate), pulse 316 shaping (e.g. raised cosine - complying with the Nyquist inter symbol 317 interference criterion), etc. 319 2.3.2. Optical Tributary Signal Group (OTSiG) 321 The definition of the OTSiG is currently being moved from ITU-T 322 Recommendation G.709 [G.709] to the new draft Recommendation G.807 323 (still work in progress) [G.807]. The OTSiG is an electrical signal 324 that is carried by one or more OTSi's. The relationship between the 325 OTSiG and the the OTSi's is described in ITU-T draft Recommendation 326 G.807, section 10.2 [G.807]. The YANG model below supports both 327 cases: the single OTSi case where the OTSiG contains a single OTSi 328 (see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple 329 OTSi case where the OTSiG consists of more than one OTSi (see ITU-T 330 draft Recommendation G.807, Figure 10-3). From a layer 0 topology 331 YANG model perspective, the OTSiG is a logical construct that 332 associates the OTSi's, which belong to the same OTSiG. The typical 333 application of an OTSiG consisting of more than one OTSi is inverse 334 multiplexing. Constraints exist for the OTSi's belonging to the same 335 OTSiG such as: (i) all OTSi's must be co-routed over the same optical 336 fibers and nodes and (ii) the differential delay between the 337 different OTSi's may not exceed a certain limit. Example: a 400Gbps 338 client signal may be carried by 4 OTSi's where each OTSi carries 339 100Gbps of client traffic. 341 OTSiG 342 _________________________/\__________________________ 343 / \ 344 m=7 345 - - - +---------------------------X---------------------------+ - - - 346 / / / | | / / / 347 / / /| OTSi OTSi OTSi OTSi |/ / / 348 / / / | ^ ^ ^ ^ | / / / 349 / / /| | | | | |/ / / 350 / / / | | | | | | / / / 351 / / /| | | | | |/ / / 352 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 353 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- 354 n = 4 355 K1 K2 K3 K4 357 Figure 3: MC Example containing all 4 OTSi signals of an OTSiG 359 2.3.3. Media Channel (MC) 361 The definition of the MC is currently being moved from ITU-T 362 Recommendation G.872 [G.872] to the new draft Recommendation G.807 363 (still work in progress) [G.807]. Section 3.2.2 defines the term MC 364 and section 7.1.2 provides a more detailed description with some 365 examples. The definition of the MC is very generic (see ITU-T draft 366 Recommendation G.807, Figure 7-1). In the YANG model below, the MC 367 is used with the following semantics: 369 The MC is an end-to-end topological network construct and can be 370 considered as an "optical pipe" with a well-defined frequency slot 371 between one or more optical transmitters each generating an OTSi and 372 the corresponding optical receivers terminating the OTSi's. If the 373 MC carries more than one OTSi, it is assumed that these OTSi's belong 374 to the same OTSiG. 376 m=8 377 +-------------------------------X-------------------------------+ 378 | | | 379 | +----------X----------+ | +----------X----------+ | 380 | | OTSi | | OTSi | | 381 | | ^ | | | ^ | | 382 | | | | | | | | 383 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 384 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 385 | n=4 | 386 K1 K2 388 <------------------------ Media Channel -----------------------> 390 Figure 4: Figure Caption TBA 392 The frequency slot of the MC is defined by the n value defining the 393 central frequency of the MC and the m value that defines the width of 394 the MC following the flexible grid definition in ITU-T Recommendation 395 G.694.1 [G.694.1]. In this model, the effective frequency slot as 396 defined in ITU-T draft Recommendation G.807 is equal to the frequency 397 slot of this end-to-end MC. It is also assumed that ROADM devices 398 can switch MCs. For various reasons (e.g. differential delay), it 399 is preferred to use a single MC for all OTSi's of the same OTSiG. It 400 may however not always be possible to find a single MC for carrying 401 all OTSi's of an OTSiG due to spectrum occupation along the OTSiG 402 path. 404 2.3.4. Media Channel Group (MCG) 406 The definition of the MCG is currently work in progress in ITU-T and 407 is defined in section 7.1.3 of the new ITU-T draft Recommendation 408 G.807 (still work in progress) [G.807]. The YANG model below assumes 409 that the MCG is a logical grouping of one or more MCs that are used 410 to to carry all OTSi's belonging to the same OTSiG. 412 The MCG can be considered as an association of MCs without defining a 413 hierarchy where each MC is defined by its (n,m) value pair. An MCG 414 consists of more than one MC when no single MC can be found from 415 source to destination that is wide enough to accommodate all OTSi's 416 (modulated carriers) that belong to the same OTSiG. In such a case 417 the set of OTSi's belonging to a single OTSiG have to be split across 418 2 or more MCs. 420 MCG1 = {M1.1, M1.2} 421 __________________________/\________________________ 422 / \ 423 M1.1 M2 M1.2 424 ____________/\____________ _____/\_____ ____/\____ 425 / \/ \/ \ 426 - - - +---------------------------+-------------+-----------+ - - - 427 / / / | | / / / / / / | | / / / 428 / / /| OTSi OTSi OTSi |/ / / / / / /| OTSi |/ / / 429 / / / | ^ ^ ^ | / / / / / / | ^ | / / / 430 / / /| | | | |/ / / / / / /| | |/ / / 431 / / / | | | | | / / / / / / | | | / / / 432 / / /| | | | |/ / / / / / /| | |/ / / 433 -7 -4 -1 0 1 2 3 4 5 6 7 8 ... 14 17 20 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 n=0 n=17 436 K1 K2 K3 K4 438 Figure 5: Figure Caption TBA 440 The MCG is relevant for path computation because all end-to-end MCs 441 belonging to the same MCG have to be co-routed, i.e., have to follow 442 the same path. Additional constraints may exist (e.g. differential 443 delay). 445 2.4. Amplifiers 447 Optical amplifiers are in charge of amplifying the optical signal in 448 the optical itself without any electrical conversion. There are 449 three main technologies to build amplifiers: Erbium Doped Fiber 450 Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor 451 Optical Amplifier (SOA). Nowadays, most of optical networks uses 452 EDFAs. However, RFA has an attractive feature that it works in any 453 wavelength band with a similar or lower noise figures compared to 454 EDFA. On the other hand, RFAs consumes more power and are more 455 expensive than EDFAs. 457 Amplifiers can be classified according to their location in the 458 communication link. There are three basic types of amplifiers: ILA, 459 Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a 460 separate node type while Pre-Amplifier and Booster Amplifier are 461 integral elements of ROADM node. From a data modeling perspective, 462 Pre-Amplifier and Booster Amplifier are internal functions of a ROADM 463 node and as such these elements are hidden within ROADM node. In 464 this document, we would avoid internal node details, but attempt to 465 abstract as much as possible. 467 One modeling consideration of the ROADM internal is to model power 468 parameter through the ROADM, factoring the output power from the Pre- 469 Amplifier minus the ROADM power loss would give the input power to 470 the Booster Amplifier. In other words, Power_in (@ ROADM Booster) = 471 Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM WSS/Filter). 473 2.5. Transponders 475 [Editor's note: The relationship between the transponder and the OTSi 476 in the YANG model described in Section 3 needs further clarification 477 and refinement.] 479 A Transponder is the element that sends and receives the optical 480 signal from a DWDM network. A transponder can comprise one or more 481 transceivers. A transceiver can be seen as a pair of transmitter and 482 receiver, as defined in ITU-T Recommendation G.698.2 [G.698.2]. 484 A transponder is typically characterized by its data/symbol rate and 485 the maximum distance the signal can travel. Other transponder 486 properties are: carrier frequency for the optical channels, output 487 power per channel, measured input power, modulation scheme, FEC, etc. 489 From a path computation perspective, the selection of the compatible 490 configuration of the source and the destination transceivers is an 491 important factor for optical signals to traverse through the DWDM 492 network. 494 The YANG model defines three different approaches to describe the 495 transceiver capabilities (called "modes") that are needed to 496 determine optical signal compatibility: 498 o Standard Modes 499 o Organizational Modes 500 o Explicit Modes 502 2.5.1. Standard Modes 504 A standard mode is related to an optical specification developed by 505 an SDO organization. Currently, the "Standard Modes" can only be 506 referred to ITU-T G.698.2 [G.698.2] since G.698.2 is the only 507 specification defining "Standard Modes" today. Nothing is 508 precluding, however, to consider other specifications provided by any 509 other SDO in the Standard Mode context as soon as such sepcifications 510 will be available. An application code as defined in ITU-T G.698.2 511 [G.698.2] is representing a standard ITU-T G.698.2 optical interface 512 specification towards the realization of transversely compatible DWDM 513 systems. Two transceivers supporting the same application code and a 514 line system matching the constraints, defined in ITU-T G.698.2, for 515 that application code will interoperate. As the characteristics are 516 encoded in the application code, the YANG model in this document only 517 defines a string, which represents that application code. 519 2.5.2. Organizational Modes 521 Organizations like operator groups, industry fora, or equipment 522 vendors can define their own optical interface specifications and 523 make use of transceiver capabilities going beyond existing standards. 525 An organizational mode is identified by the organization-identifier 526 attribute defining the scope and an operational-mode that is 527 meaningful within the scope of the organization. Hence, the two 528 attributes must always be considered together. It is the 529 responsibility of the organization to assign operational modes and to 530 ensure that operational modes are unique and unambiguous within the 531 scope of the organization. 533 Two transceivers can be interconnected, if they have at least one 534 (organization-identifier, operational-mode) pair in common and if the 535 supported carrier frequency and power attributes have a matching 536 range. This is a necessary condition for path computation in the 537 context of organizational modes. 539 An operational mode is a transceiver preset (a configuration with 540 well-defined parameter values) subsuming several transceiver 541 properties defined by the optical interface specification - these 542 properties are not provided for anoperational mode and are therefore 543 not defined in the YANG model. Examples of these properties are: 545 o FEC type 546 o Modulation scheme 547 o Encoding (mapping of bit patterns (code words) to symbols in the 548 constellation diagram) 549 o Baud rate (symbol rate) 550 o Carrier bandwidth (typically measured in GHz) 552 The major reason for these transceiver presets is the fact that the 553 attribute values typically cannot be configured independently and are 554 therefore advertised as supported operational mode capabilities. It 555 is the responsibility of the organization to assign operational modes 556 and to ensure that operational modes are unique and not ambiguous 557 within the scope of the organization. 559 In addition to the transceiver properties subsumed by the operational 560 mode, optical power and carrier frequency related properties are 561 modeled separately, i.e., outside of the operational mode. This 562 modeling approach allows transponders using different transceiver 563 variants (e.g. optical modules) with slightly different power and/or 564 frequency range properties to interoperate without defining separate 565 operational modes. Different optical modules (pluggables) from 566 different suppliers typically have slightly different input and 567 output power ranges or may have slightly different carrier frequency 568 tuning ranges. 570 The received channel power and the received total power are two 571 parameters that can be measured by the receiver and can be provided 572 by the transceiver in order to allow a controller to determine the 573 expected performance of the end-to-end service taking into account 574 the optical impairments along the path. 576 An organization may define the operational modes to include the 577 optical power and carrier frequency related properties following the 578 application code approach as defined in ITU-T Recommendation G.698.2 579 [G.698.2]. In such a case, the explicit optical power and carrier 580 frequency related optional attributes shall be omitted in order to 581 avoid redundant information in the description of the transceiver 582 capabilities. If these attributes are provided in addition to the 583 operational modes including these attribute values implicitly, the 584 parameter values provided explicitly replace the implicit values and 585 take precedence. This shall, however, only be an done in exceptional 586 cases and shall be avoided whenever possible. In case an implicitly 587 given range is extended utilizing the explicit optional attributes, a 588 path computation policy rule may be applied to select a value 589 preferably from the range defined implicitly and to only select a 590 value from the extended range if no path can be found for values in 591 the implicitly defined range. Path computation policy is outside the 592 scope of this topology YANG model. 594 In summary, the optical power and carrier frequency related 595 attributes shall either be described implicitly by the operational 596 mode following the definition provided by that organization or shall 597 be described explicitly when the optical power and carrier frequency 598 related properties are not included in the operational mode 599 definition. 601 2.5.3. Explicit Modes 603 The explicit mode allows to encode, explicitly, any subset of 604 parameters e.g., FEC type, Modulation type, etc, to enable a 605 controller entity to check for interoperability by means outside of 606 this draft. It shall be noted that using the explicit encoding does 607 not guarantee interoperability between two transceivers even in case 608 of identical parameter definitions. The explicit mode shall 609 therefore be used with care, but it could be useful when no common 610 Application Codes or Organizational Modes exist or the constraints of 611 common Application Codes or Organizational Modes cannot be met by the 612 line system. 614 2.5.4. Transponder Capabilities and Current Configuration 616 The YANG model described in Section 3 defines the optical transceiver 617 properties. They are divided between: 619 a. Optical transceiver capabilities, describing how it can be 620 configured 621 b. Current transceiver setting, indicating how it is currently 622 configured 624 The transceiver capabilities are described by the set of modes the 625 transceiver is supporting. Each mode MUST follow only one of the 626 three mode options defined above (choice in the YANG model). The 627 YANG model allows to describe the transceiver capabilities by mixing 628 different modes. A transceiver may support some ITU-T application 629 codes and in addition some organizational or explicit modes. 631 A transceiver mode description comprises the following properties: 633 o Supported transmitter tuning range with min/max nominal carrier 634 frequency [f_tx_min, f_tx_max] 635 o Supported transmitter tunability grid, the distance between two 636 adjacent carrier frequencies (in GHz) 637 o Supported transmitter power range [p_tx-min, p_tx_max] 638 o Supported receiver channel power range [p_rx-min, p_rx_max] 639 o Supported maximum total power, rx power for all channels fed into 640 the receiver 642 These optical transceiver properties are explicitly defined in the 643 model for explicit and organizational modes, while they are 644 implicitly defined for the application codes (see ITU-T G698.2 645 [G.698.2]). 647 The set of optical impairment limits, e.g., min OSNR, max PMD, max 648 CD, max PDL, Q-factor limit, are explicitly defined for the explicit 649 modes while they are defined implicitly for the application codes and 650 organizational modes. 652 It is possible that the set of parameter values defined for an 653 explicit mode may also be represented in form of an organizational 654 mode or one or more application codes. The "supported-mode" 655 container may provide two different lists with pointers to 656 application codes and organizational modes, respectively. 658 The current transponder configuration describes the properties of the 659 OTSi transmitted or received by the transceiver attached to a 660 specific transponder port. 662 Each OTSi has the following three pointer attributes modeled as 663 leafrefs: 665 o Pointer to the transponder instance containing the transceiver 666 terminating the OTSi 667 o Pointer to the transceiver instance terminating the OTSi 668 o Pointer to the currently configured transceiver mode 670 Additionally, the OTSi is described by the following frequency and 671 optical power related attributes: 673 o current carrier-frequency 674 o currently transmitted channel power 675 o currently received channel power 676 o currently received total power 678 2.6. WSS/Filter 680 WSS separates the incoming light input spectrally as well as 681 spatially, then chooses the wavelength that is of interest by 682 deflecting it from the original optical path and then couple it to 683 another optical fibre port. WSS/Filter is internal to ROADM. So 684 this document does not model the inside of ROADM. 686 2.7. Optical Fiber 688 There are various optical fiber types defined by ITU-T. There are 689 several fiber-level parameters that need to be factored in, such as, 690 fiber-type, length, loss coefficient, pmd, connectors (in/out). 692 ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted 693 Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero 694 Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive 695 Fiber. There may be other fiber-types that need to be considered. 697 2.8. ROADM Node Architectures 699 The ROADM node architectures in today's dense wavelength division 700 multiplexing (DWDM) networks can be categorized as follows: 702 o Integrated ROADM architecture with integrated optical transponders 704 o Integrated ROADM architecture with integrated optical transponders 705 and single channel add/drop ports for remote optical transponders 707 o Disaggregated ROADM architecture where the ROADM is subdivided 708 into degree, add/drop, and optical transponder subsystems handled 709 as separate network elements 711 The TE topology YANG model augmentations including optical 712 impairments for DWDM networks defined below intend to cover all the 3 713 categories of ROADM architectures listed above. In the case of a 714 disaggregated ROADM architecture, it is assumed that optical domain 715 controller already performs some form of abstraction and presents the 716 TE-node representing the disaggregated ROADM in the same way as an 717 integrated ROADM with integrated optical transponders if the optical 718 transponder subsystems and the add/drop subsystems are collocated 719 (short fiber links not imposing significant optical impairments). 721 The different ROADM architectures are briefly described and 722 illustrated in the following subsections. 724 [Editor's note: The modeling of remote optical transponders located 725 for example in the client device with a single channel link between 726 the OT and the add/drop port of the ROADM requires further 727 investigations and will be addressed in a future revision of this 728 document.] 730 2.8.1. Integrated ROADM Architecture with Integrated Optical 731 Transponders 733 Figure 2 and Figure 6 below show the typical architecture of an 734 integrated ROADM node, which contains the optical transponders as an 735 integral part of the ROADM node. Such an integrated ROADM node 736 provides DWDM interfaces as external interfaces for interconnecting 737 the device with its neighboring ROADMs (see OTS link above). The 738 number of these interfaces denote also the degree of the ROADM. A 739 degree 3 ROADM for example has 3 DWDM links that interconnect the 740 ROADM node with 3 neighboring ROADMs. Additionally, the ROADM 741 provides client interfaces for interconnecting the ROADM with client 742 devices such as IP routers or Ethernet switches. These client 743 interfaces are the client interfaces of the integrated optical 744 transponders. 746 . . . . . . . . . . . . . . . . . . 747 +-----.-------------------------------- .-----+ 748 | . ROADM . | 749 | . /| +-----------------+ |\ . | 750 Line | . / |--| |--| \ . | Line 751 WEST | /| . | |--| |--| | . |\ | EAST 752 ------+-/ |-.-| |--| OCX |--| |-.-| \-+----- 753 ------+-\ |-.-| |--| |--| |-.-| /-+----- 754 | \| . | |--| |--| | . |/ | 755 | . \ |--| |--| / . | 756 | . \| +-----------------+ |/ . | 757 | . . | 758 | . +---+ +---+ +---+ +---+ . | 759 | . | O | | O | | O | | O | . | 760 | . | T | | T | | T | | T | . | 761 | . +---+ +---+ +---+ +---+ . | 762 | . | | | | | | | | . | 763 +-----.------+-+---+-+---+-+---+-+------.-----+ 764 . . . .|.| . |.| . |.| . |.|. . . . 765 | | | | | | | | TE Node 766 Client Interfaces 768 Figure 6: ROADM Architectiure with Integrated Transponders 770 2.8.2. Integrated ROADMs with Integrated Optical Transponders and 771 Single Channel Add/Drop Interfaces for Remote Optical 772 Transponders 774 Figure 7 below shows the extreme case where all optical transponders 775 are not integral parts of the ROADM but are separate devices that are 776 interconnected with add/drop ports of the ROADM. If the optical 777 transponders and the ROADM are collocated and if short single channel 778 fiber links are used to interconnect the optical transponders with an 779 add/drop port of the ROADM, the optical domain controller may present 780 these optical transponders in the same way as integrated optical 781 transponders. If, however, the optical impairments of the single 782 channel fiber link between the optical transponder and the add/drop 783 port of the ROADM cannot be neglected, it is necessary to represent 784 the fiber link with its optical impairments in the topology model 785 This also implies that the optical transponders belong to a separate 786 TE node 788 [Editor's note: this requires further study]. 790 . . . . . . . . . . . . . . . . . . 791 . Abstracted ROADM . 792 +-----.-------------------------------- .-----+ 793 | . ROADM . | 794 | . /| +-----------------+ |\ . | 795 Line | . / |--| |--| \ . | Line 796 WEST | /| . | |--| |--| | . |\ | EAST 797 ------+-/ |-.-| |--| OCX |--| |-.-| \-+----- 798 ------+-\ |-.-| |--| |--| |-.-| /-+----- 799 | \| . | |--| |--| | . |/ | 800 | . \ |--| |--| / . | 801 | . \| +-----------------+ |/ . | 802 +-----.---------|----|---|----|---------.-----| 803 Colored OT . +-+ ++ ++ +-+ . 804 line I/F . | | | | . 805 . +---+ +---+ +---+ +---+ . 806 . | O | | O | | O | | O | . 807 . | T | | T | | T | | T | . 808 . +---+ +---+ +---+ +---+ . 809 . . . .|.| . |.| . |.| . |.|. . . . 810 | | | | | | | | TE Node 811 Client Interfaces 813 Figure 7: ROADM Architectiure with Remote Transponders 815 2.8.3. Disaggregated ROADMs Subdivided into Degree, Add/Drop, and 816 Optical Transponder Subsystems 818 Recently, some DWDM network operators started demanding ROADM 819 subsystems from their vendors. An example is the OpenROADM project 820 where multiple operators and vendors are developing related YANG 821 models. The subsystems of a disaggregated ROADM are: single degree 822 subsystems, add/drop subsystems and optical transponder subsystems. 823 These subsystems separate network elements and each network element 824 provides a separate management and control interface. The subsystems 825 are typically interconnected using short fiber patch cables and form 826 together a disaggregated ROADM node. This disaggregated ROADM 827 architecture is depicted in Figure 8 below. 829 As this document defines TE topology YANG model augmentations 830 [RFC8795] for the TE topology YANG model provided at the north-bound 831 interface of the optical domain controller, it is a valid assumption 832 that the optical domain controller abstracts the subsystems of a 833 disaggregated ROADM and presents the disaggregated ROADM in the same 834 way as an integrated ROADM hiding all the interconnects that are not 835 relevant from an external TE topology view. 837 . . . . . . . . . . . . . . . . . . 838 . Abstracted ROADM . 839 +-----.----------+ +----------.-----+ 840 | Degree 1 | | Degree 2 | 841 Line | . +-----+ | + +-----+ . | Line 842 1 | /| . | W |-|------------|-| W | . |\ | 2 843 -----+-/ |-.--| S ******** ******** S |--.-| \-+----- 844 -----+-\ |-.--| S | | * * | | S |--.-| /-+----- 845 | \| . | |-|-+ * * +-|-| | . |/ | 846 | . +-+-+-+ | | * * | | +-+-+-+ . | 847 +-----.----|-----+ | * * | +-----|----.-----+ 848 . | | * * | | . 849 +-----.----|-----+ | * * | +-----|----.-----+ 850 | Degree 4 | | | * * | | | Degree 3 | 851 Line | . +-----+ | | * * | | +-----+ . | Line 852 4 | /| . | W |-|-|--*--*--+ | | W | . |\ | 3 853 -----+-/ |-.--| S | | +--*--*----|-| S |--.-| \-+----- 854 -----+-\ |-.--| S |-|----*--*----|-| S |--.-| /-+----- 855 | \| . | | | * * | | | . |/ | 856 | . +--*--+ | * * | +--*--+ . | 857 +-----.-----*----+ * * +----*-----.-----+ 858 . * * * * . 859 . +--*---------*--*---------*--+ . 860 . | ADD | . 861 . | DROP | . 862 . +----------------------------+ . 863 Colored OT . | | | | . 864 Line I/F . +---+ +---+ +---+ +---+ . 865 . | O | | O | | O | | O | . 866 . | T | | T | | T | | T | . 867 . +---+ +---+ +---+ +---+ . 868 . . .|.| . |.| . |.| . |.|. . . 869 | | | | | | | | TE Node 870 Client Interfaces 872 Figure 8: Disaggregated ROADM Architecture with Remote Transponders 874 2.8.4. Optical Impairments Imposed by ROADM Nodes 876 When an optical OTSi signal traverses a ROADM node, optical 877 impairments are imposed on the signal by various passive or active 878 optical components inside the ROADM node. Examples of optical 879 impairments are: 881 o Chromatic dispersion (CD) 882 o Polarization mode dispersion (PMD) 883 o Polarization dependent loss (PDL) 884 o Optical amplifier noise due to amplified spontaneous emission 885 (ASE) 886 o In-band cross-talk 887 o Filtering effects (for further study) 889 A ROADM node contains a wavelength selective photonic switching 890 function (WSS)that is capable of switching media channels (MCs) 891 described in Section 2.3.4. These MCs can be established between two 892 line ports of the ROADM or between a line port and an Add/Drop port 893 of the ROADM. The Add/Drop ports of a ROADM are those ports to which 894 optical transponders are connected. Typically, this is a single 895 channel signal (single OTSi), but principally this could also be a 896 group of OTSi signals. The optical impairments associated with these 897 MCs are different and the paths of the MCs inside the ROADM node can 898 be categorized as follows: 900 o Express path: MC path between two line ports of the ROADM 901 (unidirectional) 903 o Add Path: MC path from an Add port to a line port of the ROADM 905 o Drop path: MC path from a line port to a Drop port of the ROADM 907 Due to the symmetrical architecture of the ROADM node, the optical 908 impairments associated with the express path are typically the same 909 between any two line ports of the ROADM whereas the optical 910 impairments for the add and drop paths are different and therefore 911 have to be modeled separately. 913 The optical impairments associated with each of the three types of 914 ROADM-node-internal paths described above are modeled as optical 915 impairment parameter sets. These parameter sets are modeled as an 916 augmentation of the te-node-attributes defined in [RFC8795]. The te- 917 node-attributes are augmented with a list of roadm-path-impairments 918 for the three ROADM path types distinguished by the impairment-type. 919 Each roadm-path-impairments list entry contains the set of optical 920 impairment parameters for one of the three path types indicated by 921 the impairment-type. For the optical feasibility calculation based 922 on the optical impairments, it is necessary to know whether the 923 optical power of the OTSi stays within a certain power window. This 924 is reflected by some optical power related parameters such as loss 925 parameters or power parameters, which are included in the optical 926 impairment parameter sets (see tree view in Section 3). 928 [RFC8795] defines a connectivity matrix and a local link connectivity 929 list for the TE node. The connectivity matrix describes the 930 connectivity for the express paths between the different lines of the 931 ROADM and the local link connectivity list describes the connectivity 932 for the Add and Drop paths of the ROADM. These matrices are 933 augmented with a new roadm-path-impairment matrix element, an add- 934 path-impairment, and drop-path-impairment matrix element, 935 respectively, which are defined as a pointer to the corresponding 936 entry in the roadm-path-impairments list (leaf-ref). 938 [Editor's note: this section is still work in progress] 940 3. YANG Model (Tree Structure) 942 module: ietf-optical-impairment-topology 944 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 945 +--rw optical-impairment-topology! 946 augment /nw:networks/nw:network/nt:link/tet:te 947 /tet:te-link-attributes: 948 +--ro OMS-attributes 949 +--ro generalized-snr? l0-types-ext:snr 950 +--ro equalization-mode identityref 951 +--ro (power-param)? 952 | +--:(channel-power) 953 | | +--ro nominal-channel-power? decimal64 954 | +--:(power-spectral-density) 955 | +--ro nominal-power-spectral-density? decimal64 956 +--ro media-channel-group* [i] 957 | +--ro i int16 958 | +--ro media-channels* [flexi-n] 959 | +--ro flexi-n l0-types:flexi-n 960 | +--ro flexi-m? l0-types:flexi-m 961 | +--ro OTSiG-ref? leafref 962 | +--ro OTSi-ref? leafref 963 +--ro OMS-elements* [elt-index] 964 +--ro elt-index uint16 965 +--ro oms-element-uid? string 966 +--ro (element) 967 +--:(amplifier) 968 | +--ro amplifier 969 | +--ro type-variety string 970 | +--ro operational 971 | +--ro amplifier-element* [] 972 | +--ro name? 973 | | string 974 | +--ro frequency-range 975 | | +--ro lower-frequency? 976 | | | l0-types-ext:frequency-thz 977 | | +--ro upper-frequency? 978 | | l0-types-ext:frequency-thz 979 | +--ro actual-gain 980 | | decimal64 981 | +--ro tilt-target 982 | | decimal64 983 | +--ro out-voa 984 | | decimal64 985 | +--ro in-voa 986 | | decimal64 987 | +--ro (power-param)? 988 | +--:(channel-power) 989 | | +--ro nominal-channel-power? 990 | | decimal64 991 | +--:(power-spectral-density) 992 | +--ro nominal-power-spectral-density? 993 | decimal64 994 +--:(fiber) 995 | +--ro fiber 996 | +--ro type-variety string 997 | +--ro length decimal64 998 | +--ro loss-coef decimal64 999 | +--ro total-loss decimal64 1000 | +--ro pmd? decimal64 1001 | +--ro conn-in? decimal64 1002 | +--ro conn-out? decimal64 1003 +--:(concentratedloss) 1004 +--ro concentratedloss 1005 +--ro loss decimal64 1006 augment /nw:networks/nw:network/nw:node/tet:te 1007 /tet:tunnel-termination-point: 1008 +--ro otsi-group* [otsi-group-id] 1009 | +--ro otsi-group-id int16 1010 | +--ro otsi* [otsi-carrier-id] 1011 | +--ro otsi-carrier-id int16 1012 | +--ro transponder-ref? leafref 1013 | +--ro transceiver-ref? leafref 1014 | +--ro configured-mode? leafref 1015 | +--ro OTSi-carrier-frequency? frequency-thz 1016 | +--ro tx-channel-power? dbm-t 1017 | +--ro rx-channel-power? dbm-t 1018 | +--ro rx-total-power? dbm-t 1019 +--ro transponder* [transponder-id] 1020 +--ro transponder-id uint32 1021 +--ro transceiver* [transceiver-id] 1022 +--ro transceiver-id uint32 1023 +--ro supported-modes 1024 +--ro supported-mode* [mode-id] 1025 +--ro mode-id string 1026 +--ro (mode) 1027 +--:(G.698.2) 1028 | +--ro standard-mode? standard-mode 1029 +--:(organizational-mode) 1030 | +--ro organizational-mode 1031 | +--ro operational-mode? 1032 | | operational-mode 1033 | +--ro organization-identifier? 1034 | | organization-identifier 1035 | +--ro min-central-frequency? 1036 | | frequency-thz 1037 | +--ro max-central-frequency? 1038 | | frequency-thz 1039 | +--ro minimum-channel-spacing? 1040 | | frequency-ghz 1041 | +--ro tx-channel-power-min? dbm-t 1042 | +--ro tx-channel-power-max? dbm-t 1043 | +--ro rx-channel-power-min? dbm-t 1044 | +--ro rx-channel-power-max? dbm-t 1045 | +--ro rx-total-power-max? dbm-t 1046 +--:(explicit-mode) 1047 +--ro explicit-mode 1048 +--ro supported-modes 1049 | +--ro supported-application-codes* 1050 | | -> ../../../mode-id 1051 | +--ro supported-organizational-modes* 1052 | -> ../../../mode-id 1053 +--ro line-coding-bitrate? 1054 | identityref 1055 +--ro max-polarization-mode-dispersion? 1056 | decimal64 1057 +--ro max-chromatic-dispersion? 1058 | decimal64 1059 +--ro chromatic-and-polarization-dispersion-penalty* [] 1060 | +--ro chromatic-dispersion 1061 | | decimal64 1062 | +--ro polarization-mode-dispersion 1063 | | decimal64 1064 | +--ro penalty 1065 | decimal64 1066 +--ro max-diff-group-delay? 1067 | int32 1068 +--ro max-polarization-dependent-loss? 1069 | decimal64 1070 +--ro available-modulation-type? 1071 | identityref 1072 +--ro OTSi-carrier-bandwidth? 1073 | frequency-ghz 1074 +--ro min-OSNR? 1075 | snr 1076 +--ro min-Q-factor? 1077 | int32 1078 +--ro available-baud-rate? 1079 | uint32 1080 +--ro available-fec-type? 1081 | identityref 1082 +--ro fec-code-rate? 1083 | decimal64 1084 +--ro fec-threshold? 1085 | decimal64 1086 +--ro min-central-frequency? 1087 | frequency-thz 1088 +--ro max-central-frequency? 1089 | frequency-thz 1090 +--ro minimum-channel-spacing? 1091 | frequency-ghz 1092 +--ro tx-channel-power-min? 1093 | dbm-t 1094 +--ro tx-channel-power-max? 1095 | dbm-t 1096 +--ro rx-channel-power-min? 1097 | dbm-t 1098 +--ro rx-channel-power-max? 1099 | dbm-t 1100 +--ro rx-total-power-max? 1101 dbm-t 1102 augment /nw:networks/nw:network/nw:node/tet:te 1103 /tet:tunnel-termination-point: 1104 +--ro sliceable-transponder-list* [carrier-id] 1105 +--ro carrier-id uint32 1106 augment /nw:networks/nw:network/nw:node/tet:te 1107 /tet:te-node-attributes: 1108 +--ro roadm-path-impairments* [roadm-path-impairments-id] 1109 +--ro roadm-path-impairments-id uint32 1110 +--ro (impairment-type)? 1111 +--:(roadm-express-path) 1112 | +--ro roadm-express-path 1113 | +--ro roadm-pmd? decimal64 1114 | +--ro roadm-cd? decimal64 1115 | +--ro roadm-pdl? decimal64 1116 | +--ro roadm-inband-crosstalk? decimal64 1117 | +--ro roadm-maxloss? decimal64 1118 +--:(roadm-add-path) 1119 | +--ro roadm-add-path 1120 | +--ro roadm-pmd? decimal64 1121 | +--ro roadm-cd? decimal64 1122 | +--ro roadm-pdl? decimal64 1123 | +--ro roadm-inband-crosstalk? decimal64 1124 | +--ro roadm-maxloss? decimal64 1125 | +--ro roadm-pmax? decimal64 1126 | +--ro roadm-osnr? l0-types-ext:snr 1127 | +--ro roadm-noise-figure? decimal64 1128 +--:(roadm-drop-path) 1129 +--ro roadm-drop-path 1130 +--ro roadm-pmd? decimal64 1131 +--ro roadm-cd? decimal64 1132 +--ro roadm-pdl? decimal64 1133 +--ro roadm-inband-crosstalk? decimal64 1134 +--ro roadm-maxloss? decimal64 1135 +--ro roadm-minloss? decimal64 1136 +--ro roadm-typloss? decimal64 1137 +--ro roadm-pmin? decimal64 1138 +--ro roadm-pmax? decimal64 1139 +--ro roadm-ptyp? decimal64 1140 +--ro roadm-osnr? l0-types-ext:snr 1141 +--ro roadm-noise-figure? decimal64 1142 augment /nw:networks/nw:network/nw:node/tet:te 1143 /tet:information-source-entry/tet:connectivity-matrices: 1144 +--ro roadm-path-impairments? leafref 1145 augment /nw:networks/nw:network/nw:node/tet:te 1146 /tet:information-source-entry/tet:connectivity-matrices 1147 /tet:connectivity-matrix: 1148 +--ro roadm-path-impairments? leafref 1149 augment /nw:networks/nw:network/nw:node/tet:te 1150 /tet:te-node-attributes/tet:connectivity-matrices: 1151 +--ro roadm-path-impairments? 1152 -> ../../roadm-path-impairments/roadm-path-impairments-id 1153 augment /nw:networks/nw:network/nw:node/tet:te 1154 /tet:te-node-attributes/tet:connectivity-matrices 1155 /tet:connectivity-matrix: 1156 +--ro roadm-path-impairments? leafref 1157 augment /nw:networks/nw:network/nw:node/tet:te 1158 /tet:tunnel-termination-point 1159 /tet:local-link-connectivities: 1160 +--ro add-path-impairments? leafref 1161 +--ro drop-path-impairments? leafref 1162 augment /nw:networks/nw:network/nw:node/tet:te 1163 /tet:tunnel-termination-point 1164 /tet:local-link-connectivities 1165 /tet:local-link-connectivity: 1166 +--ro add-path-impairments? leafref 1167 +--ro drop-path-impairments? leafref 1169 4. Optical Impairment Topology YANG Model 1171 [Editor's note: YANG code below may have to be updated before 1172 submission!] 1174 1175 module ietf-optical-impairment-topology { 1176 yang-version 1.1; 1178 namespace "urn:ietf:params:xml" 1179 +":ns:yang:ietf-optical-impairment-topology"; 1181 prefix "optical-imp-topo"; 1183 import ietf-network { 1184 prefix "nw"; 1185 } 1187 import ietf-network-topology { 1188 prefix "nt"; 1189 } 1191 import ietf-te-topology { 1192 prefix "tet"; 1193 } 1195 import ietf-layer0-types { 1196 prefix "l0-types"; 1197 } 1199 import ietf-layer0-types-ext { 1200 prefix "l0-types-ext"; 1201 } 1203 organization 1204 "IETF CCAMP Working Group"; 1206 contact 1207 "Editor: Young Lee 1208 Editor: Haomian Zheng 1209 Editor: Nicola Sambo 1210 Editor: Victor Lopez 1211 Editor: Gabriele Galimberti 1212 Editor: Giovanni Martinelli 1213 Editor: Jean-Luc Auge 1214 Editor: Le Rouzic Esther 1215 Editor: Julien Meuric 1216 Editor: Italo Busi 1217 Editor: Dieter Beller 1218 Editor: Sergio Belotti 1219 Editor: Griseri Enrico 1220 Editor: Gert Grammel "; 1222 description 1223 "This module contains a collection of YANG definitions for 1224 impairment-aware optical networks. 1226 Copyright (c) 2021 IETF Trust and the persons identified as 1227 authors of the code. All rights reserved. 1229 Redistribution and use in source and binary forms, with or 1230 without modification, is permitted pursuant to, and subject 1231 to the license terms contained in, the Simplified BSD 1232 License set forth in Section 4.c of the IETF Trust's Legal 1233 Provisions Relating to IETF Documents 1234 (http://trustee.ietf.org/license-info). 1235 This version of this YANG module is part of RFC XXXX; see 1236 the RFC itself for full legal notices."; 1238 // RFC Ed.: replace XXXX with actual RFC number and remove 1239 // this note 1241 // replace the revision date with the module publication date 1242 // the format is (year-month-day) 1244 revision 2021-02-16 { 1245 description 1246 "Initial Version"; 1247 reference 1248 "RFC XXXX: A Yang Data Model for Impairment-aware 1249 Optical Networks"; 1250 } 1252 // grouping 1254 grouping transponder-attributes { 1255 description "Configuration of an optical transponder"; 1257 leaf-list available-modulation-types { 1258 type identityref { 1259 base l0-types-ext:modulation; 1260 } 1261 config false; 1262 description 1263 "List of modulation types the OTSi supports"; 1265 } 1267 leaf configured-modulation-type { 1268 type identityref { 1269 base l0-types-ext:modulation; 1270 } 1271 config false; 1272 description 1273 "Currently configured OTSi modulation type"; 1274 } 1276 leaf-list available-baud-rates { 1277 type uint32; 1278 units Bd; 1279 config false; 1280 description 1281 "list of available baud-rates. 1282 Baud-rate is the unit for 1283 symbol rate or modulation rate 1284 in symbols per second or 1285 pulses per second. 1286 It is the number of distinct symbol 1287 changes (signal events) made to the 1288 transmission medium 1289 per second in a digitally 1290 modulated signal or a line code"; 1291 } 1293 leaf configured-baud-rate { 1294 type uint32; 1295 units Bd; 1296 config false; 1297 description "configured baud-rate"; 1298 } 1300 leaf-list available-FEC-types { 1301 type identityref { 1302 base l0-types-ext:fec-type; 1303 } 1304 config false; 1305 description "List determining all the available FEC"; 1306 } 1308 leaf configured-FEC-type { 1309 type identityref { 1310 base l0-types-ext:fec-type; 1311 } 1312 config false; 1314 description 1315 "FEC type configured for the transponder"; 1316 } 1318 leaf FEC-code-rate { 1319 type decimal64 { 1320 fraction-digits 8; 1321 range "0..max"; 1322 } 1323 config false; 1324 description "FEC-code-rate"; 1325 } 1327 leaf FEC-threshold { 1328 type decimal64 { 1329 fraction-digits 8; 1330 range "0..max"; 1331 } 1332 config false; 1333 description 1334 "Threshold on the BER, for which FEC 1335 is able to correct errors"; 1336 } 1338 } 1340 grouping sliceable-transponder-attributes { 1341 description 1342 "Configuration of a sliceable transponder."; 1343 list sliceable-transponder-list { 1344 key "carrier-id"; 1345 config false; 1346 description "List of carriers"; 1347 leaf carrier-id { 1348 type uint32; 1349 config false; 1350 description "Identifier of the carrier"; 1351 } 1352 } 1353 } 1355 grouping optical-fiber-data { 1356 description 1357 "optical link (fiber) attributes with impairment data"; 1358 leaf fiber-type { 1359 type fiber-type; 1360 config false; 1361 description "fiber-type"; 1363 } 1365 leaf span-length { 1366 type decimal64 { 1367 fraction-digits 2; 1368 } 1369 units "km"; 1370 config false; 1371 description "the lenght of the fiber span in km"; 1372 } 1374 leaf input-power { 1375 type decimal64 { 1376 fraction-digits 2; 1377 } 1378 units "dBm"; 1379 config false; 1380 description 1381 "Average input power level estimated at the receiver 1382 of the link"; 1383 } 1385 leaf output-power { 1386 type decimal64 { 1387 fraction-digits 2; 1388 } 1389 units "dBm"; 1390 description 1391 "Mean launched power at the transmitter of the link"; 1392 } 1394 leaf pmd { 1395 type decimal64 { 1396 fraction-digits 8; 1397 range "0..max"; 1398 } 1399 units "ps/(km)^0.5"; 1400 config false; 1401 description 1402 "Polarization Mode Dispersion"; 1403 } 1405 leaf cd { 1406 type decimal64 { 1407 fraction-digits 5; 1408 } 1409 units "ps/nm/km"; 1410 config false; 1411 description 1412 "Cromatic Dispersion"; 1413 } 1415 leaf osnr { 1416 type l0-types-ext:snr; 1417 config false; 1418 description 1419 "Optical Signal-to-Noise Ratio (OSNR) estimated 1420 at the receiver"; 1421 } 1423 leaf sigma { 1424 type decimal64 { 1425 fraction-digits 5; 1426 } 1427 units "dB"; 1428 config false; 1429 description 1430 "sigma in the Gausian Noise Model"; 1431 } 1432 } 1434 grouping optical-channel-data { 1435 description 1436 "optical impairment data per channel/wavelength"; 1437 leaf bit-rate { 1438 type decimal64 { 1439 fraction-digits 8; 1440 range "0..max"; 1441 } 1442 units "Gbit/s"; 1443 config false; 1444 description 1445 "Gross bit rate"; 1446 } 1448 leaf BER { 1449 type decimal64 { 1450 fraction-digits 18; 1451 range "0..max"; 1452 } 1453 config false; 1454 description 1455 "BER (Bit Error Rate)"; 1456 } 1458 leaf ch-input-power { 1459 type decimal64 { 1460 fraction-digits 2; 1461 } 1462 units "dBm"; 1463 config false; 1464 description 1465 "Per channel average input power level 1466 estimated at the receiver of the link"; 1467 } 1469 leaf ch-pmd { 1470 type decimal64 { 1471 fraction-digits 8; 1472 range "0..max"; 1473 } 1474 units "ps/(km)^0.5"; 1475 config false; 1476 description 1477 "per channel Polarization Mode Dispersion"; 1478 } 1480 leaf ch-cd { 1481 type decimal64 { 1482 fraction-digits 5; 1483 } 1484 units "ps/nm/km"; 1485 config false; 1486 description 1487 "per channel Cromatic Dispersion"; 1488 } 1490 leaf ch-osnr { 1491 type l0-types-ext:snr; 1492 config false; 1493 description 1494 "per channel Optical Signal-to-Noise Ratio 1495 (OSNR) estimated at the receiver"; 1496 } 1498 leaf q-factor { 1499 type decimal64 { 1500 fraction-digits 5; 1501 } 1502 units "dB"; 1503 config false; 1504 description 1505 "q-factor estimated at the receiver"; 1506 } 1508 } 1510 /* 1511 * Identities 1512 */ 1514 identity type-power-mode { 1515 description 1516 "power equalization mode used within the 1517 OMS and its elements"; 1518 } 1520 identity power-spectral-density { 1521 base type-power-mode; 1522 description 1523 "all elements must use power spectral density (W/Hz)"; 1524 } 1526 identity channel-power { 1527 base type-power-mode; 1528 description 1529 "all elements must use power (dBm)"; 1530 } 1532 /* 1533 * Typedefs 1534 */ 1536 typedef fiber-type { 1537 type enumeration { 1538 enum G.652 { 1539 description "G.652 Standard Singlemode Fiber"; 1540 } 1541 enum G.654 { 1542 description "G.654 Cutoff Shifted Fiber"; 1543 } 1544 enum G.653 { 1545 description "G.653 Dispersion Shifted Fiber"; 1546 } 1547 enum G.655 { 1548 description "G.655 Non-Zero Dispersion Shifted Fiber"; 1549 } 1550 enum G.656 { 1551 description "G.656 Non-Zero Dispersion for Wideband 1552 Optical Transport"; 1553 } 1554 enum G.657 { 1555 description "G.657 Bend-Insensitive Fiber"; 1557 } 1558 } 1559 description 1560 "ITU-T based fiber-types"; 1561 } 1563 /* 1564 * Groupings 1565 */ 1567 grouping amplifier-params { 1568 description "describes parameters for an amplifier"; 1569 container amplifier{ 1570 description 1571 "amplifier type, operatonal parameters are described."; 1572 leaf type-variety { 1573 type string ; 1574 mandatory true ; 1575 description 1576 "String identifier of amplifier type referencing 1577 a specification in a separate equipment catalog"; 1578 } 1579 container operational { 1580 description "amplifier operational parameters"; 1581 list amplifier-element { 1582 description 1583 "The list of parallel amplifier elements within an 1584 amplifier used to amplify different frequency ranges."; 1585 leaf name { 1586 type string; 1587 description 1588 "The name of the amplifier element as specified in 1589 the vendor's specification associated with the 1590 type-variety."; 1591 } 1592 container frequency-range { 1593 description 1594 "The frequency range amplified by the amplifier 1595 element."; 1596 leaf lower-frequency { 1597 type l0-types-ext:frequency-thz; 1598 description 1599 "The lower frequency boundary of the 1600 frequency range."; 1601 } 1602 leaf upper-frequency { 1603 type l0-types-ext:frequency-thz; 1604 description 1605 "The upper frequency boundary of the 1606 frequency range."; 1607 } 1608 } 1609 leaf actual-gain { 1610 type decimal64 { 1611 fraction-digits 2; 1612 } 1613 units dB ; 1614 mandatory true ; 1615 description ".."; 1616 } 1617 leaf tilt-target { 1618 type decimal64 { 1619 fraction-digits 2; 1620 } 1621 mandatory true ; 1622 description ".."; 1623 } 1624 leaf out-voa { 1625 type decimal64 { 1626 fraction-digits 2; 1627 } 1628 units dB; 1629 mandatory true; 1630 description ".."; 1631 } 1632 leaf in-voa { 1633 type decimal64 { 1634 fraction-digits 2; 1635 } 1636 units dB; 1637 mandatory true; 1638 description ".."; 1639 } 1640 uses power-param; 1641 } // list amplifier-element 1642 } // container operational 1643 } // container amplifier 1644 } // grouping amplifier-params 1646 grouping fiber-params { 1647 description 1648 "String identifier of fiber type referencing a 1649 specification in a separate equipment catalog"; 1650 container fiber { 1651 description "fiber characteristics"; 1652 leaf type-variety { 1653 type string ; 1654 mandatory true ; 1655 description "fiber type"; 1656 } 1657 leaf length { 1658 type decimal64 { 1659 fraction-digits 2; 1660 } 1661 units km; 1662 mandatory true ; 1663 description "length of fiber"; 1664 } 1665 leaf loss-coef { 1666 type decimal64 { 1667 fraction-digits 2; 1668 } 1669 units dB/km; 1670 mandatory true ; 1671 description "loss coefficient of the fiber"; 1672 } 1673 leaf total-loss { 1674 type decimal64 { 1675 fraction-digits 2; 1676 } 1677 units dB; 1678 mandatory true ; 1679 description 1680 "includes all losses: fiber loss and conn-in and 1681 conn-out losses"; 1682 } 1683 leaf pmd{ 1684 type decimal64 { 1685 fraction-digits 2; 1686 } 1687 units sqrt(ps); 1688 description "pmd of the fiber"; 1689 } 1690 leaf conn-in{ 1691 type decimal64 { 1692 fraction-digits 2; 1693 } 1694 units dB; 1695 description "connector-in"; 1696 } 1697 leaf conn-out{ 1698 type decimal64 { 1699 fraction-digits 2; 1700 } 1701 units dB; 1702 description "connector-out"; 1703 } 1704 } 1705 } 1707 grouping roadm-express-path { 1708 description "roadm express path optical impairments"; 1710 container roadm-express-path { 1711 description "roadm parameters per express path"; 1713 leaf roadm-pmd { 1714 type decimal64 { 1715 fraction-digits 8; 1716 range "0..max"; 1717 } 1718 units "ps/(km)^0.5"; 1719 description 1720 "Polarization Mode Dispersion"; 1721 } 1722 leaf roadm-cd { 1723 type decimal64 { 1724 fraction-digits 5; 1725 } 1726 units "ps/nm"; 1727 description "Chromatic Dispersion"; 1728 } 1729 leaf roadm-pdl { 1730 type decimal64 { 1731 fraction-digits 2; 1732 } 1733 units dB ; 1734 description "Polarization dependent loss"; 1735 } 1736 leaf roadm-inband-crosstalk { 1737 type decimal64 { 1738 fraction-digits 2; 1739 } 1740 units dB; 1741 description 1742 "In-band crosstalk, or coherent crosstalk, can occur in 1743 components that can have multiple same wavelength inputs 1744 with the inputs either routed to different output ports, 1745 or all but 1 blocked"; 1746 } 1747 leaf roadm-maxloss { 1748 type decimal64 { 1749 fraction-digits 2; 1750 } 1751 units dB; 1752 description 1753 "This is the maximum expected add path loss from the 1754 ROADM ingress to the ROADM egress 1755 assuming no additional add path loss is added"; 1756 } 1757 } 1758 } 1760 grouping roadm-add-path { 1761 description "roadm add block path optical impairments"; 1763 container roadm-add-path { 1764 description "roadm optical impairment parameters 1765 per add path"; 1767 leaf roadm-pmd { 1768 type decimal64 { 1769 fraction-digits 8; 1770 range "0..max"; 1771 } 1772 units "ps"; 1773 description 1774 "Polarization Mode Dispersion"; 1775 } 1776 leaf roadm-cd { 1777 type decimal64 { 1778 fraction-digits 5; 1779 } 1780 units "ps/nm"; 1781 description "Cromatic Dispersion"; 1782 } 1783 leaf roadm-pdl { 1784 type decimal64 { 1785 fraction-digits 2; 1786 } 1787 units dB ; 1788 description "Polarization dependent loss"; 1789 } 1790 leaf roadm-inband-crosstalk { 1791 type decimal64 { 1792 fraction-digits 2; 1793 } 1794 units dB ; 1795 description 1796 "In-band crosstalk, or coherent crosstalk, 1797 can occur in components that can have multiple same 1798 wavelength inputs,with the inputs either 1799 routed to different output ports, 1800 or all but 1 blocked. 1801 In the case of add path it is the total 1802 of the add block 1803 + egress WSS crosstalk contributions."; 1804 } 1805 leaf roadm-maxloss { 1806 type decimal64 { 1807 fraction-digits 2; 1808 } 1809 units dB ; 1810 description 1811 "This is the maximum expected add path loss from 1812 the add/drop port input to the ROADM egress, 1813 assuming no additional add path loss is added. 1814 This is used to establish the minimum required 1815 transponder output power required 1816 to hit the ROADM egress target power 1817 levels and preventing 1818 to hit the WSS attenuation limits. 1819 If the add path contains an internal amplifier 1820 this loss value should be based 1821 on worst case expected amplifier gain due to 1822 ripple or gain uncertainty"; 1823 } 1824 leaf roadm-pmax { 1825 type decimal64 { 1826 fraction-digits 2; 1827 } 1828 units dBm ; 1829 description 1830 "This is the maximum (per carrier) power level 1831 permitted at the add block input ports, 1832 that can be handled by the ROADM node. 1833 This may reflect either add amplifier power 1834 contraints or WSS adjustment limits. 1835 Higher power transponders would need to have 1836 their launch power reduced 1837 to this value or lower"; 1838 } 1839 leaf roadm-osnr { 1840 type l0-types-ext:snr; 1841 description 1842 "Optical Signal-to-Noise Ratio (OSNR). 1843 If the add path contains the ability to adjust the 1844 carrier power levels into an add path amplifier 1845 (if present) to a target value, 1846 this reflects the OSNR contribution of the 1847 add amplifier assuming this target value is obtained. 1848 The worst case OSNR based on the input power and 1849 NF calculation method, and this value, should be used 1850 (if both are defined)."; 1851 } 1852 leaf roadm-noise-figure { 1853 type decimal64 { 1854 fraction-digits 5; 1855 } 1856 units "dB"; 1857 description 1858 "Noise Figure. If the add path contains an amplifier, 1859 this is the noise figure of that amplifier inferred 1860 to the add port. 1861 This permits add path OSNR calculation based 1862 on the input power levels to the add block 1863 without knowing the ROADM path losses to 1864 the add amplifier."; 1865 } 1866 } 1867 } 1869 grouping roadm-drop-path { 1870 description "roadm drop block path optical impairments"; 1872 container roadm-drop-path { 1873 description "roadm optical impairment parameters 1874 per drop path"; 1876 leaf roadm-pmd { 1877 type decimal64 { 1878 fraction-digits 8; 1879 range "0..max"; 1880 } 1881 units "ps/(km)^0.5"; 1882 description 1883 "Polarization Mode Dispersion"; 1884 } 1885 leaf roadm-cd { 1886 type decimal64 { 1887 fraction-digits 5; 1888 } 1889 units "ps/nm"; 1890 description "Chromatic Dispersion"; 1891 } 1892 leaf roadm-pdl { 1893 type decimal64 { 1894 fraction-digits 2; 1895 } 1896 units dB ; 1897 description "Polarization dependent loss"; 1898 } 1899 leaf roadm-inband-crosstalk { 1900 type decimal64 { 1901 fraction-digits 2; 1902 } 1903 units dB; 1904 description 1905 "In-band crosstalk, or coherent crosstalk, can occur in 1906 components that can have multiple same wavelength 1907 inputs,with the inputs either routed to different 1908 output ports,or all but 1 blocked. 1909 In the case of drop path it is the total 1910 of the ingress 1911 to drop e.g. WSS and drop block crosstalk 1912 contributions."; 1913 } 1914 leaf roadm-maxloss { 1915 type decimal64 { 1916 fraction-digits 2; 1917 } 1918 units dB ; 1919 description 1920 "The net loss from the ROADM input,to the output 1921 of the drop block. 1922 If ROADM ingress to drop path includes an amplifier, 1923 the amplifier gain reduces the net loss. 1924 This is before any additional drop path attenuation 1925 that may be required 1926 due to drop amplifier power contraints. 1927 The max value correspond to worst case expected loss, 1928 including amplifier gain ripple or uncertainty. 1929 It is the maximum output power of the drop 1930 amplifier."; 1931 } 1932 leaf roadm-minloss { 1933 type decimal64 { 1934 fraction-digits 2; 1935 } 1936 units dB ; 1937 description 1938 "The net loss from the ROADM input, to the 1939 output of the drop block. 1940 If this ROADM ingress to drop path includes 1941 an amplifier,the amplifier gain reduces the net loss. 1942 This is before any additional drop path attenuation 1943 that may be required due to drop amplifier power 1944 contraints. 1945 The min value correspond to best case expected loss, 1946 including amplifier gain ripple or uncertainty."; 1947 } 1948 leaf roadm-typloss { 1949 type decimal64 { 1950 fraction-digits 2; 1951 } 1952 units dB ; 1953 description 1954 "The net loss from the ROADM input, 1955 to the output of the drop block. 1956 If this ROADM ingress to drop path 1957 includes an amplifier, 1958 the amplifier gain reduces the net loss. 1959 This is before any additional drop path 1960 attenuation 1961 that may be required due to drop amplifier 1962 power contraints. 1963 The typ value correspond to typical case 1964 expected loss."; 1965 } 1966 leaf roadm-pmin { 1967 type decimal64 { 1968 fraction-digits 2; 1969 } 1970 units dBm ; 1971 description 1972 "If the drop path has additional loss 1973 that is added, for example, 1974 to hit target power levels into a 1975 drop path amplifier, or simply, to reduce the 1976 power of a strong carrier 1977 (due to ripple,for example), 1978 then the use of the ROADM input power levels and 1979 the above drop losses is not appropriate. 1980 This parameter corresponds to the min per 1981 carrier power levels 1982 expected at the output of the drop block. 1983 A detail example of the comparison using 1984 these parameters is 1985 detailed in section xxx of the document yyy."; 1986 } 1987 leaf roadm-pmax { 1988 type decimal64 { 1989 fraction-digits 2; 1990 } 1991 units dBm ; 1992 description 1993 "If the drop path has additional loss that is added, 1994 for example, to hit target power levels into a 1995 drop path amplifier,or simply,to reduce the power 1996 of a strong carrier(due to ripple,for example), 1997 then the use of the ROADM input power levels and the 1998 above drop losses is not appropriate. 1999 This parameter corresponds to the best case per 2000 carrier power levels expected at the output of the 2001 drop block. 2002 A detail example of the comparison using 2003 these parameters 2004 is detailed in section xxx of the document yyy"; 2005 } 2006 leaf roadm-ptyp { 2007 type decimal64 { 2008 fraction-digits 2; 2009 } 2010 units dBm ; 2011 description 2012 "If the drop path has additional loss that is added, 2013 for example, to hit target power levels into a 2014 drop path amplifier,or simply,to reduce the 2015 power of a strong carrier(due to ripple,for example), 2016 then the use of the ROADM input power levels and 2017 the above drop losses is not appropriate. 2018 This parameter corresponds to the typical case 2019 per carrier power levels expected 2020 at the output of the drop block."; 2021 } 2022 leaf roadm-osnr { 2023 type l0-types-ext:snr; 2024 description 2025 "Optical Signal-to-Noise Ratio (OSNR). 2026 Expected OSNR contribution of the drop path 2027 amplifier(if present) 2028 for the case of additional drop path loss 2029 (before this amplifier) 2030 in order to hit a target power level (per carrier). 2031 If both, the OSNR based on the ROADM 2032 input power level 2033 (Pcarrier = 2034 Pref+10Log(carrier-baudrate/ref-baud) + delta-power) 2035 and the input inferred NF(NF.drop), 2036 and this OSNR value, are defined, 2037 the minimum value between these two should be used"; 2038 } 2039 leaf roadm-noise-figure { 2040 type decimal64 { 2041 fraction-digits 5; 2042 } 2043 units "dB"; 2044 description 2045 "Drop path Noise Figure. 2046 If the drop path contains an amplifier, 2047 this is the noise figure 2048 of that amplifier, inferred to the 2049 ROADM ingress port. 2050 This permits to determine 2051 amplifier OSNR contribution 2052 without having to specify the 2053 ROADM node's losses to that amplifier. 2054 This applies for the case of no 2055 additional drop path loss, 2056 before the amplifier, in order to reduce the power 2057 of the carriers to a target value"; 2058 } 2059 } 2060 } 2062 grouping concentratedloss-params{ 2063 description "concentrated loss"; 2064 container concentratedloss{ 2065 description "concentrated loss"; 2066 leaf loss { 2067 type decimal64 { 2068 fraction-digits 2; 2069 } 2070 units dB ; 2071 mandatory true; 2072 description ".."; 2073 } 2074 } 2075 } 2077 grouping power-param{ 2078 description 2079 "optical power or PSD after the ROADM or after the out-voa"; 2080 choice power-param { 2081 description 2082 "select the mode: channel power or power spectral density"; 2083 case channel-power { 2084 /* when "equalization-mode='channel-power'"; */ 2085 leaf nominal-channel-power{ 2086 type decimal64 { 2087 fraction-digits 1; 2088 } 2089 units dBm ; 2090 description 2091 " Reference channel power after the ROADM or after 2092 the out-voa. "; 2093 } 2094 } 2095 case power-spectral-density{ 2096 /* when "equalization-mode='power-spectral-density'"; */ 2097 leaf nominal-power-spectral-density{ 2098 type decimal64 { 2099 fraction-digits 16; 2100 } 2101 units W/Hz ; 2102 description 2103 " Reference power spectral density after 2104 the ROADM or after the out-voa. 2105 Typical value : 3.9 E-14, resolution 0.1nW/MHz"; 2106 } 2107 } 2108 } 2109 } 2111 grouping oms-general-optical-params { 2112 description "OMS link optical parameters"; 2113 leaf generalized-snr { 2114 type l0-types-ext:snr; 2115 description "generalized snr"; 2116 } 2117 leaf equalization-mode{ 2118 type identityref { 2119 base type-power-mode; 2120 } 2121 mandatory true; 2122 description "equalization mode"; 2123 } 2124 uses power-param; 2125 } 2127 grouping OTSiG { 2128 description "OTSiG definition , representing client 2129 digital information stream supported by 1 or more OTSi"; 2131 list otsi { 2132 key "otsi-carrier-id"; 2133 config false; 2134 description 2135 "list of OTSi contained in 1 OTSiG. 2136 The list could also be of only 1 element"; 2137 leaf otsi-carrier-id { 2138 type int16; 2139 description "OTSi carrier-id"; 2140 } 2142 /*any OTSi as signal generated by transceiver and*/ 2143 /* attached to a transponder.*/ 2145 leaf transponder-ref { 2146 type leafref { 2147 path "/nw:networks/nw:network/nw:node/tet:te" + 2148 "/tet:tunnel-termination-point" + 2149 "/transponder/transponder-id"; 2150 } 2151 description 2152 "Reference to the configured transponder"; 2153 } 2154 leaf transceiver-ref { 2155 type leafref { 2156 path "/nw:networks/nw:network/nw:node/tet:te" + 2157 "/tet:tunnel-termination-point/" 2158 +"transponder[transponder-id=current()" 2159 +"/../transponder-ref]/" 2160 + "transceiver/transceiver-id" ; 2161 } 2162 description 2163 "Reference to the configured transceiver " ; 2164 } 2165 leaf configured-mode { 2166 type leafref { 2167 path "/nw:networks/nw:network/nw:node/tet:te" + 2168 "/tet:tunnel-termination-point/" 2169 +"transponder[transponder-id=current()" 2170 +"/../transponder-ref]/"+ 2171 "transceiver[transceiver-id=current()/"+ 2172 "../transceiver-ref]/supported-modes/"+ 2173 "supported-mode/mode-id"; 2174 } 2175 description 2176 "Reference to the configured mode for transceiver 2177 compatibility approach"; 2178 } 2179 uses l0-types-ext:common-transceiver-configured-param; 2181 } // OTSi list 2182 } // OTSiG grouping 2184 grouping media-channel-groups { 2185 description "media channel groups"; 2186 list media-channel-group { 2187 key "i"; 2188 description 2189 "list of media channel groups"; 2190 leaf i { 2191 type int16; 2192 description "index of media channel group member"; 2193 } 2195 list media-channels { 2196 key "flexi-n"; 2197 description 2198 "list of media channels represented as (n,m)"; 2200 // this grouping add both n.m values 2201 uses l0-types:flexi-grid-frequency-slot; 2203 leaf OTSiG-ref { 2204 type leafref { 2205 path "/nw:networks/nw:network/nw:node/tet:te" + 2206 "/tet:tunnel-termination-point" + 2207 "/otsi-group/otsi-group-id" ; 2209 } 2210 description 2211 "Reference to the otsi-group list to get otsi-group 2212 identifier of the 2213 OTSiG carried by this media channel 2214 that reports the transient stat"; 2215 } 2216 leaf OTSi-ref { 2217 type leafref { 2218 path "/nw:networks/nw:network/nw:node/tet:te" + 2219 "/tet:tunnel-termination-point/" 2220 +"otsi-group[otsi-group-id=current()" 2221 +"/../OTSiG-ref]/" 2222 + "otsi/otsi-carrier-id" ; 2223 } 2224 description 2225 "Reference to the otsi list supporting 2226 the related OTSiG to get otsi identifier"; 2227 } 2229 } // media channels list 2230 } // media-channel-groups list 2231 } // media media-channel-groups grouping 2233 grouping oms-element { 2234 description "OMS description"; 2235 list OMS-elements { 2236 key "elt-index"; 2237 description 2238 "defines the spans and the amplifier blocks of 2239 the amplified lines"; 2240 leaf elt-index { 2241 type uint16; 2242 description 2243 "ordered list of Index of OMS element 2244 (whether it's a Fiber, an EDFA or a 2245 Concentratedloss)"; 2246 } 2247 leaf oms-element-uid { 2248 type string; 2249 description 2250 "unique id of the element if it exists"; 2251 } 2253 choice element { 2254 mandatory true; 2255 description "OMS element type"; 2256 case amplifier { 2257 uses amplifier-params ; 2258 } 2259 case fiber { 2260 uses fiber-params ; 2261 } 2262 case concentratedloss { 2263 uses concentratedloss-params ; 2264 } 2265 } 2267 } 2268 } 2270 /* Data nodes */ 2272 augment "/nw:networks/nw:network/nw:network-types" 2273 + "/tet:te-topology" { 2274 description "optical-impairment topology augmented"; 2275 container optical-impairment-topology { 2276 presence "indicates an impairment-aware topology of 2277 optical networks"; 2278 description 2279 "Container to identify impairment-aware topology type"; 2280 } 2281 } 2283 augment "/nw:networks/nw:network/nt:link/tet:te" 2284 + "/tet:te-link-attributes" { 2285 when "/nw:networks/nw:network/nw:network-types" 2286 +"/tet:te-topology/" 2287 +"optical-imp-topo:optical-impairment-topology" { 2288 description 2289 "This augment is only valid for Optical Impairment."; 2290 } 2291 description "Optical Link augmentation for impairment data."; 2292 container OMS-attributes { 2293 config false; 2294 description "OMS attributes"; 2295 uses oms-general-optical-params; 2296 uses media-channel-groups; 2297 uses oms-element; 2298 } 2299 } 2301 augment "/nw:networks/nw:network/nw:node/tet:te" 2302 + "/tet:tunnel-termination-point" { 2303 when "/nw:networks/nw:network/nw:network-types" 2304 +"/tet:te-topology/optical-imp-topo:optical-impairment-topology"{ 2305 description 2306 "This augment is only valid for Impairment with non-sliceable 2307 transponder model"; 2308 } 2309 description 2310 "Tunnel termination point augmentation for non-sliceable 2311 transponder model."; 2313 list otsi-group { 2314 key "otsi-group-id"; 2315 config false; 2316 description 2317 "the list of possible OTSiG representing client digital 2318 stream"; 2320 leaf otsi-group-id { 2321 type int16; 2322 description "index of otsi-group element"; 2323 } 2324 uses OTSiG; 2326 } // list of OTSiG 2328 list transponder { 2329 key "transponder-id"; 2330 config false; 2331 description "list of transponder"; 2332 leaf transponder-id { 2333 type uint32; 2334 description "transponder identifier"; 2335 } 2337 list transceiver { 2338 key "transceiver-id"; 2339 config false; 2340 description "list of transceiver related to a transponder"; 2341 leaf transceiver-id { 2342 type uint32; 2343 description "transceiver identifier"; 2344 } 2345 uses l0-types-ext:transceiver-capabilities; 2346 } // end of list of transceiver 2348 } // end list of transponder 2350 } // end of augment 2352 augment "/nw:networks/nw:network/nw:node/tet:te" 2353 + "/tet:tunnel-termination-point" { 2354 when "/nw:networks/nw:network/nw:network-types" 2355 +"/tet:te-topology/" 2356 + "optical-imp-topo:optical-impairment-topology" { 2357 description 2358 "This augment is only valid for optical impairment 2359 with sliceable transponder model"; 2360 } 2361 description 2362 "Tunnel termination point augmentation for sliceable 2363 transponder model."; 2364 uses sliceable-transponder-attributes; 2365 } 2367 augment "/nw:networks/nw:network/nw:node/tet:te" 2368 + "/tet:te-node-attributes" { 2369 when "/nw:networks/nw:network/nw:network-types" 2370 + "/tet:te-topology" 2371 + "/optical-imp-topo:optical-impairment-topology" { 2373 description 2374 "This augment is only valid for Optical Impairment 2375 topology"; 2376 } 2377 description 2378 "node attributes augmentantion for optical-impairment ROADM 2379 node"; 2381 list roadm-path-impairments { 2382 key "roadm-path-impairments-id"; 2383 config false; 2384 description "list of set of optical impairments related 2385 to ROADM "; 2387 leaf roadm-path-impairments-id { 2388 type uint32; 2389 description "index of the ROADM path-impairment list"; 2390 } 2391 choice impairment-type { 2392 description "type path impairment"; 2393 case roadm-express-path { 2394 uses roadm-express-path; 2395 } 2396 case roadm-add-path { 2397 uses roadm-add-path; 2398 } 2399 case roadm-drop-path { 2400 uses roadm-drop-path; 2401 } 2402 } 2403 } // list path impairments 2404 } // augmentation for optical-impairment ROADM 2406 augment "/nw:networks/nw:network/nw:node/tet:te/" 2407 + "tet:information-source-entry/tet:connectivity-matrices"{ 2408 when "/nw:networks/nw:network/nw:network-types" 2409 + "/tet:te-topology/" 2410 + "optical-imp-topo:optical-impairment-topology" { 2411 description 2412 "This augment is only valid for Optical Impairment 2413 topology "; 2414 } 2416 description 2417 "Augment default TE node connectivity matrix information 2418 source."; 2420 leaf roadm-path-impairments { 2421 type leafref { 2422 path "../../../tet:te-node-attributes/" 2423 + "roadm-path-impairments/roadm-path-impairments-id"; 2424 } 2425 description "pointer to the list set of ROADM optical 2426 impairments"; 2427 } 2428 } // augmentation connectivity-matrices information-source 2430 augment "/nw:networks/nw:network/nw:node/tet:te/" 2431 + "tet:information-source-entry/tet:connectivity-matrices/" 2432 + "tet:connectivity-matrix" { 2433 when "/nw:networks/nw:network/nw:network-types" 2434 + "/tet:te-topology/" 2435 + "optical-imp-topo:optical-impairment-topology" { 2436 description 2437 "This augment is only valid for Optical Impairment 2438 topology "; 2439 } 2441 description 2442 "Augment TE node connectivity matrix entry information 2443 source."; 2445 leaf roadm-path-impairments { 2446 type leafref { 2447 path "../../../../tet:te-node-attributes/" 2448 + "roadm-path-impairments/roadm-path-impairments-id"; 2449 } 2450 description "pointer to the list set of ROADM optical 2451 impairments"; 2452 } 2453 } // augmentation connectivity-matrix information-source 2455 augment "/nw:networks/nw:network/nw:node/tet:te/" 2456 + "tet:te-node-attributes/tet:connectivity-matrices" { 2457 when "/nw:networks/nw:network/nw:network-types" 2458 + "/tet:te-topology/" 2459 + "optical-imp-topo:optical-impairment-topology" { 2460 description 2461 "This augment is only valid for Optical Impairment 2462 topology "; 2463 } 2465 description 2466 "Augment default TE node connectivity matrix."; 2467 leaf roadm-path-impairments { 2468 type leafref { 2469 path "../../roadm-path-impairments/" 2470 + "roadm-path-impairments-id"; 2471 } 2472 config false; /*the identifier in the list */ 2473 /*"roadm-path-impairments" of ROADM optical impairment*/ 2474 /*is read-only as the rest of attributes*/ 2475 description "pointer to the list set of ROADM optical 2476 impairments"; 2477 } 2478 } // augmentation connectivity-matrices 2480 augment "/nw:networks/nw:network/nw:node/tet:te/" 2481 + "tet:te-node-attributes/" 2482 + "tet:connectivity-matrices/tet:connectivity-matrix" { 2483 when "/nw:networks/nw:network/nw:network-types" 2484 + "/tet:te-topology/" 2485 + "optical-imp-topo:optical-impairment-topology" { 2486 description 2487 "This augment is only valid for 2488 Optical Impairment topology "; 2489 } 2491 description 2492 "Augment TE node connectivity matrix entry."; 2494 leaf roadm-path-impairments { 2495 type leafref { 2496 path "../../../roadm-path-impairments/" 2497 + "roadm-path-impairments-id"; 2498 } 2499 config false; 2500 description "pointer to the list set of ROADM optical 2501 impairments"; 2502 } 2503 } // augmentation connectivity-matrix 2505 augment "/nw:networks/nw:network/nw:node/tet:te/" 2506 + "tet:tunnel-termination-point/" 2507 + "tet:local-link-connectivities" { 2509 when "/nw:networks/nw:network/nw:network-types" 2510 + "/tet:te-topology/" 2511 + "optical-imp-topo:optical-impairment-topology" { 2512 description 2513 "This augment is only valid for Optical Impairment topology "; 2514 } 2516 description 2517 "Augment default TTP LLC."; 2518 leaf add-path-impairments { 2519 type leafref { 2520 path "../../../tet:te-node-attributes/" 2521 + "roadm-path-impairments/roadm-path-impairments-id" ; 2522 } 2523 config false; 2524 description "pointer to the list set of ROADM optical 2525 impairments"; 2526 } 2527 leaf drop-path-impairments { 2528 type leafref { 2529 path "../../../tet:te-node-attributes/" 2530 + "roadm-path-impairments/roadm-path-impairments-id" ; 2531 } 2532 config false; 2533 description "pointer to the list set of ROADM 2534 optical impairments"; 2535 } 2536 } // augmentation local-link-connectivities 2538 augment "/nw:networks/nw:network/nw:node/tet:te/" 2539 + "tet:tunnel-termination-point/" 2540 + "tet:local-link-connectivities/" 2541 + "tet:local-link-connectivity" { 2543 when "/nw:networks/nw:network/nw:network-types" 2544 + "/tet:te-topology/" 2545 + "optical-imp-topo:optical-impairment-topology" { 2546 description 2547 "This augment is only valid for 2548 Optical Impairment topology "; 2549 } 2551 description 2552 "Augment TTP LLC entry."; 2553 leaf add-path-impairments { 2554 type leafref { 2555 path "../../../../tet:te-node-attributes/" 2556 + "roadm-path-impairments/roadm-path-impairments-id" ; 2557 } 2558 config false; 2559 description "pointer to the list set of ROADM optical 2560 impairments"; 2561 } 2562 leaf drop-path-impairments { 2563 type leafref { 2564 path "../../../../tet:te-node-attributes/" 2565 + "roadm-path-impairments/roadm-path-impairments-id" ; 2566 } 2567 config false; 2568 description "pointer to the list set of ROADM optical 2569 impairments"; 2570 } 2571 } // augmentation local-link-connectivity 2572 } 2573 2575 5. Security Considerations 2577 The configuration, state, and action data defined in this document 2578 are designed to be accessed via a management protocol with a secure 2579 transport layer, such as NETCONF [RFC6241]. The NETCONF access 2580 control model [RFC8341] provides the means to restrict access for 2581 particular NETCONF users to a preconfigured subset of all available 2582 NETCONF protocol operations and content. 2584 A number of configuration data nodes defined in this document are 2585 read-only; however, these data nodes may be considered sensitive or 2586 vulnerable in some network environments (TBD). 2588 6. IANA Considerations 2590 This document registers the following namespace URIs in the IETF XML 2591 registry [RFC3688]: 2593 -------------------------------------------------------------------- 2594 URI: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology 2595 Registrant Contact: The IESG. 2596 XML: N/A, the requested URI is an XML namespace. 2597 -------------------------------------------------------------------- 2599 This document registers the following YANG modules in the YANG Module 2600 Names registry [RFC7950]: 2602 -------------------------------------------------------------------- 2603 name: ietf-optical-impairment-topology 2604 namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment- 2605 topology 2606 prefix: optical-imp-topo 2607 reference: RFC XXXX (TDB) 2608 -------------------------------------------------------------------- 2610 7. Acknowledgments 2612 We thank Daniele Ceccarelli and Oscar G. De Dios for useful 2613 discussions and motivation for this work. 2615 8. References 2617 8.1. Normative References 2619 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2620 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2621 . 2623 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2624 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2625 . 2627 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2628 Access Control Model", STD 91, RFC 8341, 2629 DOI 10.17487/RFC8341, March 2018, 2630 . 2632 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2633 O. Gonzalez de Dios, "YANG Data Model for Traffic 2634 Engineering (TE) Topologies", RFC 8795, 2635 DOI 10.17487/RFC8795, August 2020, 2636 . 2638 8.2. Informative References 2640 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2641 and A. Bierman, Ed., "Network Configuration Protocol 2642 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2643 . 2645 [RFC6566] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and G. 2646 Martinelli, "A Framework for the Control of Wavelength 2647 Switched Optical Networks (WSONs) with Impairments", 2648 RFC 6566, DOI 10.17487/RFC6566, March 2012, 2649 . 2651 [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, 2652 "Routing and Wavelength Assignment Information Model for 2653 Wavelength Switched Optical Networks", RFC 7446, 2654 DOI 10.17487/RFC7446, February 2015, 2655 . 2657 [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and 2658 J. Han, "General Network Element Constraint Encoding for 2659 GMPLS-Controlled Networks", RFC 7579, 2660 DOI 10.17487/RFC7579, June 2015, 2661 . 2663 [RFC7581] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and 2664 J. Han, "Routing and Wavelength Assignment Information 2665 Encoding for Wavelength Switched Optical Networks", 2666 RFC 7581, DOI 10.17487/RFC7581, June 2015, 2667 . 2669 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 2670 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 2671 Requirements for GMPLS-Based Control of Flexi-Grid Dense 2672 Wavelength Division Multiplexing (DWDM) Networks", 2673 RFC 7698, DOI 10.17487/RFC7698, November 2015, 2674 . 2676 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2677 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2678 . 2680 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2681 and R. Wilton, "Network Management Datastore Architecture 2682 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2683 . 2685 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2686 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2687 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2688 2018, . 2690 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2691 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2692 DOI 10.17487/RFC8453, August 2018, 2693 . 2695 [I-D.ietf-ccamp-wson-yang] 2696 Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A 2697 YANG Data Model for WSON (Wavelength Switched Optical 2698 Networks)", draft-ietf-ccamp-wson-yang-28 (work in 2699 progress), December 2020. 2701 [I-D.ietf-ccamp-layer0-types] 2702 Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A 2703 YANG Data Model for Layer 0 Types", draft-ietf-ccamp- 2704 layer0-types-09 (work in progress), December 2020. 2706 [I-D.ietf-ccamp-dwdm-if-param-yang] 2707 Galimberti, G., Kunze, R., Burk, A., Hiremagalur, D., and 2708 G. Grammel, "A YANG model to manage the optical interface 2709 parameters for an external transponder in a WDM network", 2710 draft-ietf-ccamp-dwdm-if-param-yang-05 (work in progress), 2711 November 2020. 2713 [G.807] "Generic functional architecture of the optical media 2714 network", ITU-T Recommendation G.807 - in publication 2715 process, February 2020. 2717 [G.709] "Interfaces for the Optical Transport Network (OTN)", 2718 ITU-T Recommendation G.709, June 2016. 2720 [G.694.1] "Spectral grids for WDM applications: DWDM frequency 2721 grid", ITU-T Recommendation G.694.1, February 2012. 2723 [G.959.1] "Optical transport network physical layer interfaces", 2724 ITU-T Recommendation G.959.1, February 2012. 2726 [G.872] "Architecture of optical transport networks", 2727 ITU-T Recommendation G.872, January 2017. 2729 [G.698.2] "Amplified multichannel dense wavelength division 2730 multiplexing applications with single channel optical 2731 interfaces", ITU-T Recommendation G.698.2, November 2018. 2733 Appendix A. Contributors 2735 Aihua Guo 2736 Huawei Technologies 2738 Email: aguo@futurewei.com 2740 Jonas Martensson 2741 RISE 2743 Email: jonas.martensson@ri.se 2745 Appendix B. Additional Authors 2747 Haomian Zheng 2748 Huawei Technologies 2750 Email: zhenghaomian@huawei.com 2751 Italo Busi 2752 Huawei Technologies 2754 Email: Italo.Busi@huawei.com 2756 Nicola Sambo 2757 Scuola Superiore Sant'Anna 2759 Email: nicosambo@gmail.com 2761 Giovanni Martinelli 2762 Cisco 2764 Email: giomarti@cisco.com 2766 Esther Le Rouzic 2767 Orange 2769 Email: esther.lerouzic@orange.com 2771 Julien Meuric 2772 Orange 2774 Email: julien.meuric@orange.com 2776 Sergio Belotti 2777 Nokia 2779 Email: Sergio.belotti@nokia.com 2781 Griseri Enrico 2782 Nokia 2784 Email: Enrico.Griseri@nokia.com 2786 Gert Grammel 2787 Juniper 2789 Email: ggrammel@juniper.net 2791 Authors' Addresses 2793 Young Lee 2794 SKKU (Sung Kyun Kwan University) 2796 Email: younglee.tx@gmail.com 2798 Jean-Luc Auge 2799 Orange 2801 Email: jeanluc.auge@orange.com 2803 Victor Lopez 2804 Telefonica 2806 Email: victor.lopezalvarez@telefonica.com 2808 G. Galimberti 2809 Cisco 2811 Email: ggalimbe@cisco.com 2813 Dieter Beller 2814 Nokia 2816 Email: Dieter.Beller@nokia.com