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