idnits 2.17.1 draft-ietf-ccamp-optical-impairment-topology-yang-02.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 15 instances of too long lines in the document, the longest one being 13 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 691 has weird spacing: '...t-index uin...' == Line 698 has weird spacing: '...variety str...' == Line 717 has weird spacing: '...variety str...' == Line 730 has weird spacing: '...ntifier int...' == Line 762 has weird spacing: '...rier-id uin...' -- The document date (November 4, 2019) is 1635 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 178, but not defined == Missing Reference: 'OTSiG-identifier' is mentioned on line 729, but not defined == Missing Reference: 'OTSi-carrier-id' is mentioned on line 732, but not defined == Missing Reference: 'RFC6536' is mentioned on line 1723, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 1734, but not defined == Unused Reference: 'WSON-Topo' is defined on line 1815, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-13 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Y. Lee 2 Internet Draft SKKU (Sung Kyun Kwan University) 3 Intended Status: Standard Track 4 Expires: May 7, 2020 V. Lopez 5 Telefonica 7 G. Galimberti 8 Cisco 10 Jean Luc Auge 11 Orange 13 D. Beller 14 Nokia 16 November 4, 2019 18 A Yang Data Model for Optical Impairment-aware Topology 20 draft-ietf-ccamp-optical-impairment-topology-yang-02 22 Abstract 24 In order to provision an optical connection through optical 25 networks, a combination of path continuity, resource availability, 26 and impairment constraints must be met to determine viable and 27 optimal paths through the network. The determination of appropriate 28 paths is known as Impairment-Aware Routing and Wavelength Assignment 29 (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and 30 Spectrum Assigment (IA-RSA) for SSON. 32 This document provides a YANG data model for the impairment-aware TE 33 topology in optical networks. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with 38 the provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on May 7, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction ................................................ 3 75 1.1. Terminology ............................................ 4 76 1.2. Tree diagram ........................................... 4 77 1.3. Prefixes in Data Node Names............................. 4 78 2. Reference Architecture....................................... 5 79 2.1. Control Plane Architecture.............................. 5 80 2.2. Transport Data Plane.................................... 6 81 2.3. OMS Media Links......................................... 7 82 2.3.1. Optical Tributary Signal (OTSi) ................... 7 83 2.3.2. Optical Tributary Signal Group (OTSiG) ............ 8 84 2.3.3. Media Channel Group (MCG) ........................ 10 85 2.4. Amplifiers ............................................ 11 86 2.5. Transponders .......................................... 11 87 2.6. WSS/Filter ............................................ 12 88 2.7. Optical Fiber ......................................... 12 89 3. YANG Model (Tree Structure)................................. 17 90 4. Optical Impairment Topology YANG Model ..................... 19 91 5. Security Considerations..................................... 38 92 6. IANA Considerations ........................................ 38 93 7. Acknowledgments ............................................ 39 94 8. References ................................................. 40 95 8.1. Normative References................................... 40 96 8.2. Informative References................................. 40 97 9. Contributors ............................................... 42 98 Authors' Addresses ............................................ 42 100 1. Introduction 102 In order to provision an optical connection (an optical path) 103 through a wavelength switched optical networks (WSONs) or spectrum 104 switched optical networks (SSONs), a combination of path continuity, 105 resource availability, and impairment constraints must be met to 106 determine viable and optimal paths through the network. The 107 determination of appropriate paths is known as Impairment-Aware 108 Routing and Wavelength Assignment (IA-RWA) [RFC6566] for WSON, while 109 it is known as IA-Routing and Spectrum Assigment (IA-RSA) for SSON. 111 This document provides a YANG data model for the impairment-aware 112 Traffic Engineering (TE) topology in WSONs and SSONs. The YANG model 113 described in this document is a WSON/SSON technology-specific Yang 114 model based on the information model developed in [RFC7446] and the 115 two encoding documents [RFC7581] and [RFC7579] that developed 116 protocol independent encodings based on [RFC7446]. 118 The intent of this document is to provide a Yang data model, which 119 can be utilized by a Multi-Domain Service Coordinator (MDSC) to 120 collect states of WSON impairment data from the Transport PNCs to 121 enable impairment-aware optical path computation according to the 122 ACTN Architecture [RFC8453]. The communication between controllers 123 is done via a NETCONF [RFC8341] or a RESTCONF [RFC8040]. Similarly, 124 this model can also be exported by the MDSC to a Customer Network 125 Controller (CNC), which can run an offline planning process to map 126 latter the services in the network. 128 This document augments the generic TE topology draft [TE-TOPO] where 129 possible. 131 This document defines one YANG module: ietf-optical-impairment- 132 topology (Section 3) according to the new Network Management 133 Datastore Architecture [RFC8342]. 135 1.1. Terminology 137 Refer to [RFC6566], [RFC7698], and [G.807] for the key terms used in 138 this document. 140 The following terms are defined in [RFC7950] and are not redefined 141 here: 143 o client 145 o server 147 o augment 149 o data model 151 o data node 153 The following terms are defined in [RFC6241] and are not redefined 154 here: 156 o configuration data 158 o state data 160 The terminology for describing YANG data models is found in 161 [RFC7950]. 163 1.2. Tree diagram 165 A simplified graphical representation of the data model is used in 166 Section 2 of this this document. The meaning of the symbols in 167 these diagrams is defined in [RFC8340]. 169 1.3. Prefixes in Data Node Names 171 In this document, names of data nodes and other data model objects 172 are prefixed using the standard prefix associated with the 173 corresponding YANG imported modules, as shown in Table 1. 175 +------------------+----------------------------------+------------+ 176 | Prefix | YANG module | Reference | 177 +------------------+----------------------------------+------------+ 178 | optical-imp-topo | ietf-optical-impairment-topology | [RFCXXXX] | 179 | layer0-types | ietf-layer0-types | [L0-Types] | 180 | nw | ietf-network | [RFC8345] | 181 | nt | ietf-network-topology | [RFC8345] | 182 | tet | ietf-te-topology | [TE-TOPO] | 183 +------------------+----------------------------------+------------+ 185 Table 1: Prefixes and corresponding YANG modules 187 Note: The RFC Editor will replace XXXX with the number assigned to 188 the RFC once this draft becomes an RFC. 190 2. Reference Architecture 192 2.1. Control Plane Architecture 194 Figure 1 shows the control plane architecture. 196 +--------+ 197 | MDSC | 198 +--------+ 199 Scope of this ID -------> || 200 | || 201 | +------------------------+ 202 | | OPTICAL | 203 +---------+ | | DOMAIN | +---------+ 204 | Device | | | CONTROLLER | | Device | 205 | config. | | +------------------------+ | config. | 206 +---------+ v // || \\ +---------+ 207 ______|______ // || \\ ______|______ 208 / OT \ // || \\ / OT \ 209 | +--------+ |// __--__ \\| +--------+ | 210 | |Vend. A |--|----+ ( ) +----|--| Vend. A| | 211 | +--------+ | | ~-( )-~ | | +--------+ | 212 | +--------+ | +---/ \---+ | +--------+ | 213 | |Vend. B |--|--+ / \ +--|--| Vend. B| | 214 | +--------+ | +---( OLS Segment )---+ | +--------+ | 215 | +--------+ | +---( )---+ | +--------+ | 216 | |Vend. C |--|--+ \ / +--|--| Vend. C| | 217 | +--------+ | +---\ /---+ | +--------+ | 218 | +--------+ | | ~-( )-~ | | +--------+ | 219 | |Vend. D |--|----+ (__ __) +----|--| Vend. D| | 220 | +--------+ | -- | +--------+ | 221 \_____________/ \_____________/ 222 ^ ^ 223 | | 224 | | 226 Scope of draft-ietf-ccamp-dwdm-if-param-yang 228 Figure 1. Control Plane Architecture 230 The models developed in this document is an abstracted Yang model 231 that may be used in the interfaces between the MDSC and the Optical 232 Domain Controller (aka MPI) and between the Optical Domain 233 Controller and the Optical Device (aka SBI) in Figure 1. It is not 234 intended to support a detailed low-level DWDM interface model. DWDM 235 interface model is supported by the models presented in [draft-ietf- 236 ccamp-dwdm-if-parameter-yang]. 238 2.2. Transport Data Plane 240 This section provides the description of the reference optical 241 network architecture and its relevant components to support optical 242 impairment-aware path computation. 244 Figure 2 shows the reference architecture. 246 +-------------------+ +-------------------+ 247 | ROADM Node | | ROADM Node | 248 | | | | 249 | PA +-------+ BA | ILA | PA +-------+ BA | 250 | +-+ | WSS/ | +-+ | _____ +--+ _____ | +-+ | WSS/ | +-+ | 251 ---|-| |-|Filter |-| |-|-()____)--| |-()____)-|-| |-|Filter |-| |-|--- 252 | +-+ | | +-+ | +--+ | +-+ | | +-+ | 253 | +-------+ | optical | +-------+ | 254 | | | | | fiber | | | | | 255 | | | | | | | | | | 256 | o-o-o | | o-o-o | 257 | transponders | | transponders | 258 +-------------------+ +-------------------+ 259 OTS Link OTS Link 260 --------> --------> 262 OMS Link 263 ----------------------------------> 265 PA: Pre-Amplifier 266 BA: Booster Amplifier 267 ILA: In-Line Amplifier 269 Figure 2. Reference Architecture for Optical Transport Network 271 BA (on the left side ROADM) is the ingress Amplifier and PA (on the 272 right side ROADM is the egress amplifier for the OMS link shown in 273 the Figure. 275 2.3. OMS Media Links 277 According to [G.872], OMS Media Link represents a media link between 278 two ROADMs. Specifically, it originates at the ROADM's Filter in the 279 source ROADM and terminates at the ROADM's Filter in the destination 280 ROADM. 282 OTS Media Link represents a media link: 283 (i) between ROADM's BA and ILA; 284 (ii) between a pair of ILAs; 285 (iii) between ILA and ROADM's PA. 287 OMS Media link can be decomposed in a sequence of OTS links type 288 (i), (ii), and (iii) as discussed above. OMS Media link would give 289 an abstracted view of impairment data (e.g., power, OSNR, etc.) to 290 the network controller. 292 For the sake of optical impairment evaluation OMS Media link can be 293 also decomposed in a sequence of elements such as BA, fiber section, 294 ILA, concentrated loss and PA. 296 2.3.1. Optical Tributary Signal (OTSi) 298 The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4 299 [G.959.1]. The YANG model defined below assumes that a single OTSi 300 consists of a single modulated optical carrier. This single 301 modulated optical carrier conveys digital information. 302 Characteristics of the OTSi signal are modulation scheme (e.g. QPSK, 303 8-QAM, 16-QAM, etc.), baud rate (measure of the symbol rate), pulse 304 shaping (e.g. raised cosine - complying with the Nyquist inter 305 symbol interference criterion), etc. 307 2.3.2. Optical Tributary Signal Group (OTSiG) 309 The definition of the OTSiG is currently being moved from ITU-T 310 Recommendation G.709 [G.709] to the new draft Recommendation G.807 311 (still work in progress) [G.807]. The OTSiG is an electrical signal 312 that is carried by one or more OTSi's. The relationship between the 313 OTSiG and the the OTSi's is described in ITU-T draft Recommendation 314 G.807, section 10.2 [G.807]. The YANG model below supports both 315 cases: the single OTSi case where the OTSiG contains a single OTSi 316 (see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple 317 OTSi case where the OTSiG consists of more than one OTSi (see ITU-T 318 draft Recommendation G.807, Figure 10-3). From a layer 0 topology 319 YANG model perspective, the OTSiG is a logical construct that 320 associates the OTSi's, which belong to the same OTSiG. The typical 321 application of an OTSiG consisting of more than one OTSi is inverse 322 multiplexing. Constraints exist for the OTSi's belonging to the same 323 OTSiG such as: (i) all OTSi's must be co-routed over the same 324 optical fibers and nodes and (ii) the differential delay between the 325 different OTSi's may not exceed a certain limit. Example: a 400Gbps 326 client signal may be carried by 4 OTSi's where each OTSi carries 327 100Gbps of client traffic. 329 OTSiG 330 _________________________/\__________________________ 331 / \ 332 m=7 333 - - - +---------------------------X---------------------------+ - - - 334 / / / | | / / / 335 / / /| OTSi OTSi OTSi OTSi |/ / / 336 / / / | ^ ^ ^ ^ | / / / 337 / / /| | | | | |/ / / 338 / / / | | | | | | / / / 339 / / /| | | | | |/ / / 340 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 341 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- 342 n = ? 343 K1 K2 K3 K4 345 2.3.3 Media Channel (MC) 346 The definition of the MC is currently being moved from ITU-T 347 Recommendation G.872 [G.872] to the new draft Recommendation G.807 348 (still work in progress) [G.807]. Section 3.2.2 defines the term MC 349 and section 7.1.2 provides a more detailed description with some 350 examples. The definition of the MC is very generic (see ITU-T draft 351 Recommendation G.807, Figure 7-1). In the YANG model below, the MC 352 is used with the following semantics: 354 The MC is an end-to-end topological network construct and can be 355 considered as an "optical pipe" with a well-defined frequency slot 356 between one or more optical transmitters each generating an OTSi and 357 the corresponding optical receivers terminating the OTSi's. If the 358 MC carries more than one OTSi, it is assumed that these OTSi's 359 belong to the same OTSiG. 361 m=8 362 +-------------------------------X-------------------------------+ 363 | | | 364 | +----------X----------+ | +----------X----------+ | 365 | | OTSi | | OTSi | | 366 | | ^ | | | ^ | | 367 | | | | | | | | 368 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 369 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 370 | n=4 | 371 K1 K2 373 <------------------------ Media Channel -----------------------> 375 The frequency slot of the MC is defined by the n value defining the 376 central frequency of the MC and the m value that defines the width 377 of the MC following the flexible grid definition in ITU-T 378 Recommendation G.694.1 [G.694.1]. In this model, the effective 379 frequency slot as defined in ITU-T draft Recommendation G.807 is 380 equal to the frequency slot of this end-to-end MC. It is also 381 assumed that ROADM devices can switch MCs. For various reasons (e.g. 382 differential delay), it is preferred to use a single MC for all 383 OTSi's of the same OTSiG. It may however not always be possible to 384 find a single MC for carrying all OTSi's of an OTSiG due to spectrum 385 occupation along the OTSiG path. 387 2.3.3. Media Channel Group (MCG) 389 The definition of the MCG is currently work in progress in ITU-T and 390 is defined in section 7.1.3 of the new ITU-T draft Recommendation 391 G.807 (still work in progress) [G.807]. The YANG model below assumes 392 that the MCG is a logical grouping of one or more MCs that are used 393 to to carry all OTSi's belonging to the same OTSiG. 395 The MCG can be considered as an association of MCs without defining 396 a hierarchy where each MC is defined by its (n,m) value pair. An MCG 397 consists of more than one MC when no single MC can be found from 398 source to destination that is wide enough to accommodate all OTSi's 399 (modulated carriers) that belong to the same OTSiG. In such a case 400 the set of OTSi's belonging to a single OTSiG have to be split 401 across 2 or more MCs. 403 MCG1 = {M1.1, M1.2} 404 __________________________/\__________________________ 405 / \ 406 M1.1 M2 M1.2 407 ____________/\____________ ______/\______ ____/\____ 408 / \/ \/ \ 410 - - - +-------------------------------------------------------+ - - - 411 / / / | | / / / / / / /| | / / / 412 / / /| OTSi OTSi OTSi |/ / / / / / / | OTSi |/ / / 413 / / / | ^ ^ ^ | / / / / / / /| ^ | / / / 414 / / /| | | | |/ / / / / / / | | |/ / / 415 / / / | | | | | / / / / / / /| | | / / / 416 / / /| | | | |/ / / / / / / | | |/ / / 417 -7 -1 0 1 2 3 4 5 6 7 8 9 10 . . . . . 17 . . 21 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- 419 n=0 n=11 n=17 420 K1 K2 K3 K4 422 The MCG is relevant for path computation because all end-to-end MCs 423 belonging to the same MCG have to be co-routed, i.e., have to follow 424 the same path. Additional constraints may exist (e.g. differential 425 delay). 427 2.4. Amplifiers 429 Optical amplifiers are in charge of amplifying the optical signal in 430 the optical itself without any electrical conversion. There are 431 three main technologies to build amplifiers: Erbium Doped Fiber 432 Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor 433 Optical Amplifier (SOA). Nowadays, most of optical networks uses 434 EDFAs. However, RFA has an attractive feature that it works in any 435 wavelength band with a similar or lower noise figures compared to 436 EDFA. On the other hand, RFAs consumes more power and are more 437 expensive than EDFAs. 439 Amplifiers can be classified according to their location in the 440 communication link. There are three basic types of amplifiers: ILA, 441 Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a 442 separate node type while Pre-Amplifier and Booster Amplifier are 443 integral elements of ROADM node. From a data modeling perspective, 444 Pre-Amplifier and Booster Amplifier are internal functions of a 445 ROADM node and as such these elements are hidden within ROADM node. 446 In this document, we would avoid internal node details, but attempt 447 to abstract as much as possible. 449 One modeling consideration of the ROADM internal is to model power 450 parameter through the ROADM, factoring the output power from the 451 Pre-Amplifier minus the ROADM power loss would give the input power 452 to the Booster Amplifier. In other words, Power_in (@ ROADM Booster) 453 = Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM 454 WSS/Filter). 456 2.5. Transponders 458 A Transponder is the element that sends and receives the optical 459 signal from a fiber. A transponder is typically characterized by its 460 data rate and the maximum distance the signal can travel. Channel 461 frequency, per channel input power, FEC and Modulation are also 462 associated with a transponder. From a path computation point of 463 view, the selection of the compatible source and destination 464 transponders is an important factor for optical signal to traverse 465 through the fiber. There are three main approaches to determine 466 optical signal compatibility. Application Code based on G.698.2 is 467 one approach that only checks the code at both ends of the link. 468 Another approach is organization codes that are specific to an 469 organization or a vendor. The third approach is specify all the 470 relevant parameters explicitly, e.g., FEC type, Modulation type, 471 etc. 473 [Editor's Note: The current YANG model described in Section 3 with 474 respect to the relationship between the transponder attributes and 475 the OTSi will need to be investigated in the future revision] 477 2.6. WSS/Filter 479 WSS separates the incoming light input spectrally as well as 480 spatially, then chooses the wavelength that is of interest by 481 deflecting it from the original optical path and then couple it to 482 another optical fibre port. WSS/Filter is internal to ROADM. So this 483 document does not model the inside of ROADM. 485 2.7. Optical Fiber 487 There are various optical fiber types defined by ITU-T. There are 488 several fiber-level parameters that need to be factored in, such as, 489 fiber-type, length, loss coefficient, pmd, connectors (in/out). 491 ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted 492 Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero 493 Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive 494 Fiber. There may be other fiber-types that need to be considered. 496 2.8. ROADM Node Architectures 498 The ROADM node architectures in today's dense wavelength division 499 multiplexing (DWDM) networks can be categorized as follows: 501 o Integrated ROADM architecture with integrated optical transponders 502 o Integrated ROADM architecture with integrated optical transponders 503 and single channel add/drop ports for remote optical transponders 504 o Disaggregated ROADM architecture where the ROADM is subdivided 505 into degree, add/drop, and optical transponder subsystems handled 506 as separate network elements 508 The TE topology YANG model augmentations including optical 509 impairments for DWDM networks defined below intend to cover all the 510 3 categories of ROADM architectures listed above. In the case of a 511 disaggregated ROADM architecture, it is assumed that optical domain 512 controller already performs some form of abstraction and presents 513 the TE-node representing the disaggregated ROADM in the same way as 514 an integrated ROADM with integrated optical transponders if the 515 optical transponder subsystems and the add/drop subsystems are 516 collocated (short fiber links not imposing significant optical 517 impairments). 519 The different ROADM architectures are briefly described and 520 illustrated in the following subsections. 522 [Editor's Note: The modeling of remote optical transponders located 523 for example in the client device with a single channel link between 524 the OT and the add/drop port of the ROADM requires further 525 investigations and will be addressed in a future revision of this 526 document.] 528 2.8.1. Integrated ROADM architecture with integrated transponders 530 Figure 2 and Figure below show the typical architecture of an 531 integrated ROADM node, which contains the optical transponders as an 532 integral part of the ROADM node. Such an integrated ROADM node 533 provides DWDM interfaces as external interfaces for interconnecting 534 the device with its neighboring ROADMs (see OTS link above). The 535 number of these interfaces denote also the degree of the ROADM. A 536 degree 3 ROADM for example has 3 DWDM links that interconnect the 537 ROADM node with 3 neighboring ROADMs. Additionally, the ROADM 538 provides client interfaces for interconnecting the ROADM with client 539 devices such as IP routers or Ethernet switches. These client 540 interfaces are the client interfaces of the integrated optical 541 transponders. 543 . . . . . . . . . . . . . . . . . . 544 +-----.-------------------------------- .-----+ 545 | . ROADM . | 546 | . /| +-----------------+ |\ . | 547 Line | . / |--| |--| \ . | Line 548 WEST | /| . | |--| |--| | . |\ | EAST 549 ------+-/ |-.-| |--| OCX |--| |-.-| \-+----- 550 ------+-\ |-.-| |--| |--| |-.-| /-+----- 551 | \| . | |--| |--| | . |/ | 552 | . \ |--| |--| / . | 553 | . \| +-----------------+ |/ . | 554 | . . | 555 | . +---+ +---+ +---+ +---+ . | 556 | . | O | | O | | O | | O | . | 557 | . | T | | T | | T | | T | . | 558 | . +---+ +---+ +---+ +---+ . | 559 | . | | | | | | | | . | 560 +-----.------+-+---+-+---+-+---+-+------.-----+ 561 . . . .|.| . |.| . |.| . |.|. . . . 562 | | | | | | | | TE Node 563 Client Interfaces 565 Figure : ROADM architectiure with integrated transponders 567 2.8.2. Integrated ROADMs with integrated optical transponders and 568 single channel add/drop interfaces for remote optical transponders 570 Figure below shows the extreme case where all optical 571 transponders are not integral parts of the ROADM but are separate 572 devices that are interconnected with add/drop ports of the ROADM. If 573 the optical transponders and the ROADM are collocated and if short 574 single channel fiber links are used to interconnect the optical 575 transponders with an add/drop port of the ROADM, the optical domain 576 controller may present these optical transponders in the same way as 577 integrated optical transponders. If, however, the optical 578 impairments of the single channel fiber link between the optical 579 transponder and the add/drop port of the ROADM cannot be neglected, 580 it is necessary to represent the fiber link with its optical 581 impairments in the topology model This also implies that the optical 582 transponders belong to a separate TE node [Editor's Note: this 583 requires further study]. 585 . . . . . . . . . . . . . . . . . . 586 . Abstracted ROADM . 587 +-----.-------------------------------- .-----+ 588 | . ROADM . | 589 | . /| +-----------------+ |\ . | 590 Line | . / |--| |--| \ . | Line 591 WEST | /| . | |--| |--| | . |\ | EAST 592 ------+-/ |-.-| |--| OCX |--| |-.-| \-+----- 593 ------+-\ |-.-| |--| |--| |-.-| /-+----- 594 | \| . | |--| |--| | . |/ | 595 | . \ |--| |--| / . | 596 | . \| +-----------------+ |/ . | 597 +-----.---------|----|---|----|---------.-----| 598 Colored OT . +-+ ++ ++ +-+ . 599 line I/F . | | | | . 600 . +---+ +---+ +---+ +---+ . 601 . | O | | O | | O | | O | . 602 . | T | | T | | T | | T | . 603 . +---+ +---+ +---+ +---+ . 604 . . . .|.| . |.| . |.| . |.|. . . . 605 | | | | | | | | TE Node 606 Client Interfaces 608 Figure : ROADM architectiure with remote transponders 610 2.8.3. Disaggregated ROADMs that are subdivided into degree, add/drop, 611 and optical transponder subsystems 613 Recently, some DWDM network operators started demanding ROADM 614 subsystems from their vendors. An example is the OpenROADM project 615 where multiple operators and vendors are developing related YANG 616 models. The subsystems of a disaggregated ROADM are: single degree 617 subsystems, add/drop subsystems and optical transponder subsystems. 618 These subsystems separate network elements and each network element 619 provides a separate management and control interface. The subsystems 620 are typically interconnected using short fiber patch cables and form 621 together a disaggregated ROADM node. This disaggregated ROADM 622 architecture is depicted in Figure below. 624 As this document defines TE topology YANG model augmentations [TE- 625 TOPO] for the TE topology YANG model provided at the north-bound 626 interface of the optical domain controller, it is a valid assumption 627 that the optical domain controller abstracts the subsystems of a 628 disaggregated ROADM and presents the disaggregated ROADM in the same 629 way as an integrated ROADM hiding all the interconnects that are not 630 relevant from an external TE topology view. 632 . . . . . . . . . . . . . . . . . . 633 . Abstracted ROADM . 634 +-----.----------+ +----------.-----+ 635 | Degree 1 | | Degree 2 | 636 Line | . +-----+ | + +-----+ . | Line 637 1 | /| . | W |-|------------|-| W | . |\ | 2 638 -----+-/ |-.--| S ******** ******** S |--.-| \-+----- 639 -----+-\ |-.--| S | | * * | | S |--.-| /-+----- 640 | \| . | |-|-+ * * +-|-| | . |/ | 641 | . +-+-+-+ | | * * | | +-+-+-+ . | 642 +-----.----|-----+ | * * | +-----|----.-----+ 643 . | | * * | | . 644 +-----.----|-----+ | * * | +-----|----.-----+ 645 | Degree 4 | | | * * | | | Degree 3 | 646 Line | . +-----+ | | * * | | +-----+ . | Line 647 4 | /| . | W |-|-|--*--*--+ | | W | . |\ | 3 648 -----+-/ |-.--| S | | +--*--*----|-| S |--.-| \-+----- 649 -----+-\ |-.--| S |-|----*--*----|-| S |--.-| /-+----- 650 | \| . | | | * * | | | . |/ | 651 | . +--*--+ | * * | +--*--+ . | 652 +-----.-----*----+ * * +----*-----.-----+ 653 . * * * * . 654 . +--*---------*--*---------*--+ . 655 . | ADD | . 656 . | DROP | . 657 . +----------------------------+ . 658 Colored OT . | | | | . 659 line I/F . +---+ +---+ +---+ +---+ . 660 . | O | | O | | O | | O | . 661 . | T | | T | | T | | T | . 662 . +---+ +---+ +---+ +---+ . 663 . . .|.| . |.| . |.| . |.|. . . 664 | | | | | | | | TE Node 665 Client Interfaces 667 Figure : ROADM architectiure with remote transponders 669 3. YANG Model (Tree Structure) 671 module: ietf-optical-impairment-topology 672 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 673 +--rw optical-impairment-topology! 674 augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes: 675 +--ro OMS-attributes 676 +--ro generalized-snr? decimal64 677 +--ro equalization-mode identityref 678 +--ro (power-param)? 679 | +--:(channel-power) 680 | | +--ro nominal-channel-power? decimal64 681 | +--:(power-spectral-density) 682 | +--ro nominal-power-spectral-density? decimal64 683 +--ro media-channel-group* [i] 684 | +--ro i int16 685 | +--ro media-channels* [flexi-n] 686 | +--ro flexi-n uint16 687 | +--ro flexi-m? uint16 688 | +--ro OTSiG-ref? leafref 689 | +--ro OTSi-ref? leafref 690 +--ro OMS-elements* [elt-index] 691 +--ro elt-index uint16 692 +--ro uid? string 693 +--ro type identityref 694 +--ro element 695 +--ro (element)? 696 +--:(amplifier) 697 | +--ro amplifier 698 | +--ro type_variety string 699 | +--ro operational 700 | +--ro actual-gain 701 | | decimal64 702 | +--ro tilt-target 703 | | decimal64 704 | +--ro out-voa 705 | | decimal64 706 | +--ro in-voa 707 | | decimal64 708 | +--ro (power-param)? 709 | +--:(channel-power) 710 | | +--ro nominal-channel-power? 711 | | decimal64 712 | +--:(power-spectral-density) 713 | +--ro nominal-power-spectral-density? 714 | decimal64 715 +--:(fiber) 716 | +--ro fiber 717 | +--ro type_variety string 718 | +--ro length decimal64 719 | +--ro loss_coef decimal64 720 | +--ro total_loss decimal64 721 | +--ro pmd? decimal64 722 | +--ro conn_in? decimal64 723 | +--ro conn_out? decimal64 724 +--:(concentratedloss) 725 +--ro concentratedloss 726 +--ro loss? decimal64 727 augment /nw:networks/nw:network/nw:node/tet:te 728 /tet:tunnel-termination-point: 729 +--ro OTSiG-element* [OTSiG-identifier] 730 | +--ro OTSiG-identifier int16 731 | +--ro OTSiG-container 732 | +--ro OTSi* [OTSi-carrier-id] 733 | +--ro OTSi-carrier-id int16 734 | +--ro OTSi-carrier-frequency? decimal64 735 | +--ro OTSi-signal-width? decimal64 736 | +--ro channel-delta-power? decimal64 737 +--ro transponders-list* [transponder-id] 738 +--ro transponder-id uint32 739 +--ro (mode)? 740 | +--:(G.692.2) 741 | | +--ro standard_mode? layer0-types:standard-mode 742 | +--:(organizational_mode) 743 | | +--ro operational-mode? 744 | | | layer0-types:operational-mode 745 | | +--ro organization-identifier? 746 | | layer0-types:vendor-identifier 747 | +--:(explicit_mode) 748 | +--ro available-modulation* identityref 749 | +--ro modulation-type? identityref 750 | +--ro available-baud-rates* uint32 751 | +--ro configured-baud-rate? uint32 752 | +--ro available-FEC* identityref 753 | +--ro FEC-type? identityref 754 | +--ro FEC-code-rate? decimal64 755 | +--ro FEC-threshold? decimal64 756 +--ro power? int32 757 +--ro power-min? int32 758 +--ro power-max? int32 759 augment /nw:networks/nw:network/nw:node/tet:te 760 /tet:tunnel-termination-point: 761 +--ro transponder-list* [carrier-id] 762 +--ro carrier-id uint32 764 4. Optical Impairment Topology YANG Model 766 file ietf-optical-impairment-topology@2018-05-22.yang 767 module ietf-optical-impairment-topology { 768 yang-version 1.1; 770 namespace "urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology"; 772 prefix "optical-imp-topo"; 774 import ietf-network { 775 prefix "nw"; 776 } 778 import ietf-network-topology { 779 prefix "nt"; 780 } 782 import ietf-te-topology { 783 prefix "tet"; 784 } 786 import ietf-layer0-types { 787 prefix "layer0-types"; 788 } 790 organization 791 "IETF CCAMP Working Group"; 793 contact 794 "Editor: Young Lee 795 Editor: Haomian Zheng 796 Editor: Nicola Sambo 797 Editor: Victor Lopez 798 Editor: Gabriele Galimberti 799 Editor: Giovanni Martinelli 800 Editor: Auge Jean-Luc 801 Editor: Le Rouzic Esther 802 Editor: Julien Meuric 803 Editor: Italo Busi 804 Editor: Dieter Beller 805 Editor: Sergio Belotti 806 Editor: Griseri Enrico 807 Editor: Gert Grammel "; 809 description 810 "This module contains a collection of YANG definitions for 811 impairment-aware optical networks. 813 Copyright (c) 2019 IETF Trust and the persons identified as 814 authors of the code. All rights reserved. 816 Redistribution and use in source and binary forms, with or 817 without modification, is permitted pursuant to, and subject 818 to the license terms contained in, the Simplified BSD 819 License set forth in Section 4.c of the IETF Trust's Legal 820 Provisions Relating to IETF Documents 821 (http://trustee.ietf.org/license-info)."; 823 revision 2019-05-22 { 824 description 825 "Initial Version"; 826 reference 827 "RFC XXXX: A Yang Data Model for Impairment-aware 828 Optical Networks"; 829 } 831 identity modulation { 832 description "base identity for modulation type"; 833 } 835 identity QPSK { 836 base modulation; 837 description 838 "QPSK (Quadrature Phase Shift Keying) modulation"; 839 } 841 identity DP_QPSK { 842 base modulation; 843 description 844 "DP-QPSK (Dual Polarization Quadrature 845 Phase Shift Keying) modulation"; 846 } 847 identity QAM8 { 848 base modulation; 849 description 850 "8QAM (8-State Quadrature Amplitude Modulation) modulation"; 851 } 852 identity QAM16 { 853 base modulation; 854 description 855 "QAM16 (Quadrature Amplitude Modulation)"; 856 } 857 identity DP_QAM8 { 858 base modulation; 859 description 860 "DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)"; 861 } 862 identity DC_DP_QAM8 { 863 base modulation; 864 description 865 "DC DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)"; 866 } 867 identity DP_QAM16 { 868 base modulation; 869 description 870 "DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)"; 871 } 872 identity DC_DP_QAM16 { 873 base modulation; 874 description 875 "DC DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)"; 876 } 878 identity FEC { 879 description 880 "Enumeration that defines the type of 881 Forward Error Correction"; 882 } 883 identity reed-solomon { 884 base FEC; 885 description 886 "Reed-Solomon error correction"; 887 } 888 identity hamming-code { 889 base FEC; 890 description 891 "Hamming Code error correction"; 892 } 893 identity golay { 894 base FEC; 895 description "Golay error correction"; 896 } 898 typedef fiber-type { 899 type enumeration { 900 enum G.652 { 901 description "G.652 Standard Singlemode Fiber"; 902 } 903 enum G.654 { 904 description "G.654 Cutoff Shifted Fiber"; 905 } 906 enum G.653 { 907 description "G.653 Dispersion Shifted Fiber"; 908 } 909 enum G.655 { 910 description "G.655 Non-Zero Dispersion Shifted Fiber"; 911 } 912 enum G.656 { 913 description "G.656 Non-Zero Dispersion for Wideband 914 Optical Transport"; 915 } 916 enum G.657 { 917 description "G.657 Bend-Insensitive Fiber"; 918 } 919 } 920 description 921 "ITU-T based fiber-types"; 922 } 924 grouping transponder-attributes { 925 description "Configuration of an optical transponder"; 927 leaf-list available-modulation { 928 type identityref { 929 base modulation; 930 } 931 config false; 932 description 933 "List determining all the available modulations"; 934 } 936 leaf modulation-type { 937 type identityref { 938 base modulation; 939 } 940 config false; 941 description 942 "Modulation configured for the transponder"; 943 } 945 leaf-list available-baud-rates { 946 type uint32; 947 units Bd; 948 config false; 949 description 950 "list of available baud-rates. Baud-rate is the unit for 951 symbol rate or modulation rate in symbols per second or 952 pulses per second. It is the number of distinct symbol 953 changes (signaling events) made to the transmission medium 954 per second in a digitally modulated signal or a line code"; 956 } 958 leaf configured-baud-rate { 959 type uint32; 960 units Bd; 961 config false; 962 description "configured baud-rate"; 963 } 965 leaf-list available-FEC { 966 type identityref { 967 base FEC; 968 } 969 config false; 970 description "List determining all the available FEC"; 971 } 973 leaf FEC-type { 974 type identityref { 975 base FEC; 976 } 977 config false; 978 description 979 "FEC type configured for the transponder"; 980 } 982 leaf FEC-code-rate { 983 type decimal64 { 984 fraction-digits 8; 985 range "0..max"; 986 } 987 config false; 988 description "FEC-code-rate"; 989 } 991 leaf FEC-threshold { 992 type decimal64 { 993 fraction-digits 8; 994 range "0..max"; 995 } 996 config false; 997 description 998 "Threshold on the BER, for which FEC is able to correct errors"; 999 } 1001 } 1003 grouping sliceable-transponder-attributes { 1004 description 1005 "Configuration of a sliceable transponder."; 1006 list transponder-list { 1007 key "carrier-id"; 1008 config false; 1009 description "List of carriers"; 1010 leaf carrier-id { 1011 type uint32; 1012 config false; 1013 description "Identifier of the carrier"; 1014 } 1015 } 1016 } 1018 grouping optical-fiber-data { 1019 description 1020 "optical link (fiber) attributes with impairment data"; 1021 leaf fiber-type { 1022 type fiber-type; 1023 config false; 1024 description "fiber-type"; 1025 } 1027 leaf span-length { 1028 type decimal64 { 1029 fraction-digits 2; 1030 } 1031 units "km"; 1032 config false; 1033 description "the lenght of the fiber span in km"; 1034 } 1036 leaf input-power { 1037 type decimal64 { 1038 fraction-digits 2; 1039 } 1040 units "dBm"; 1041 config false; 1042 description 1043 "Average input power level estimated at the receiver 1044 of the link"; 1045 } 1047 leaf output-power { 1048 type decimal64 { 1049 fraction-digits 2; 1050 } 1051 units "dBm"; 1052 description 1053 "Mean launched power at the transmitter of the link"; 1055 } 1057 leaf pmd { 1058 type decimal64 { 1059 fraction-digits 8; 1060 range "0..max"; 1061 } 1062 units "ps/(km)^0.5"; 1063 config false; 1064 description 1065 "Polarization Mode Dispersion"; 1066 } 1068 leaf cd { 1069 type decimal64 { 1070 fraction-digits 5; 1071 } 1072 units "ps/nm/km"; 1073 config false; 1074 description 1075 "Cromatic Dispersion"; 1076 } 1078 leaf osnr { 1079 type decimal64 { 1080 fraction-digits 5; 1081 } 1082 units "dB"; 1083 config false; 1084 description 1085 "Optical Signal-to-Noise Ratio (OSNR) estimated 1086 at the receiver"; 1087 } 1089 leaf sigma { 1090 type decimal64 { 1091 fraction-digits 5; 1092 } 1093 units "dB"; 1094 config false; 1095 description 1096 "sigma in the Gausian Noise Model"; 1097 } 1098 } 1100 grouping optical-channel-data { 1101 description 1102 "optical impairment data per channel/wavelength"; 1103 leaf bit-rate { 1104 type decimal64 { 1105 fraction-digits 8; 1106 range "0..max"; 1107 } 1108 units "Gbit/s"; 1109 config false; 1110 description 1111 "Gross bit rate"; 1112 } 1114 leaf BER { 1115 type decimal64 { 1116 fraction-digits 18; 1117 range "0..max"; 1118 } 1119 config false; 1120 description 1121 "BER (Bit Error Rate)"; 1122 } 1124 leaf ch-input-power { 1125 type decimal64 { 1126 fraction-digits 2; 1127 } 1128 units "dBm"; 1129 config false; 1130 description 1131 "Per channel average input power level 1132 estimated at the receiver of the link"; 1133 } 1135 leaf ch-pmd { 1136 type decimal64 { 1137 fraction-digits 8; 1138 range "0..max"; 1139 } 1140 units "ps/(km)^0.5"; 1141 config false; 1142 description 1143 "per channel Polarization Mode Dispersion"; 1144 } 1146 leaf ch-cd { 1147 type decimal64 { 1148 fraction-digits 5; 1149 } 1150 units "ps/nm/km"; 1151 config false; 1152 description 1154 "per channel Cromatic Dispersion"; 1155 } 1157 leaf ch-osnr { 1158 type decimal64 { 1159 fraction-digits 5; 1160 } 1161 units "dB"; 1162 config false; 1163 description 1164 "per channel Optical Signal-to-Noise Ratio 1165 (OSNR) estimated at the receiver"; 1166 } 1168 leaf q-factor { 1169 type decimal64 { 1170 fraction-digits 5; 1171 } 1172 units "dB"; 1173 config false; 1174 description 1175 "q-factor estimated at the receiver"; 1176 } 1177 } 1179 grouping standard_mode { 1180 description 1181 "ITU-T G.698.2 standard mode that guarantees interoperability. 1182 It must be an string with the following format: 1183 B-DScW-ytz(v) where all these attributes are conformant 1184 to the ITU-T recomendation"; 1186 leaf standard_mode { 1187 type layer0-types:standard-mode; 1188 config false; 1189 description 1190 "G.698.2 standard mode"; 1191 } 1192 } 1194 grouping organizational_mode { 1195 description 1196 "Transponder operational mode supported by organizations or 1197 vendor"; 1199 leaf operational-mode { 1200 type layer0-types:operational-mode; 1201 config false; 1202 description 1203 "configured organization- or vendor-specific 1204 application identifiers (AI) supported by the transponder"; 1205 } 1207 leaf organization-identifier { 1208 type layer0-types:vendor-identifier; 1209 config false; 1210 description 1211 "organization identifier that uses organizational 1212 mode"; 1214 } 1215 } 1217 /* 1218 * Identities 1219 */ 1220 identity type-element { 1221 description 1222 "Base identity for element type"; 1223 } 1225 identity Fiber { 1226 base type-element; 1227 description 1228 "Fiber element"; 1229 } 1231 identity Roadm { 1232 base type-element; 1233 description 1234 "Roadm element"; 1235 } 1237 identity Edfa { 1238 base type-element; 1239 description 1240 "Edfa element"; 1241 } 1243 identity Concentratedloss { 1244 base type-element; 1245 description 1246 "Concentratedloss element"; 1247 } 1249 identity type-power-mode { 1250 description 1251 "power equalization mode used within the OMS and its elements"; 1253 } 1255 identity power-spectral-density { 1256 base type-power-mode; 1257 description 1258 "all elements must use power spectral density (W/Hz)"; 1259 } 1261 identity channel-power { 1262 base type-power-mode; 1263 description 1264 "all elements must use power (dBm)"; 1265 } 1267 /* 1268 * Groupings 1269 */ 1270 grouping amplifier-params { 1271 description "describes parameters for an amplifier"; 1272 container amplifier{ 1273 description "amplifier type, operatonal parameters are described"; 1274 leaf type_variety { 1275 type string ; 1276 mandatory true ; 1277 description 1278 "String identifier of amplifier type referencing 1279 a specification in a separate equipment catalog"; 1280 } 1281 container operational { 1282 description "amplifier operationnal parameters"; 1283 leaf actual-gain { 1284 type decimal64 { 1285 fraction-digits 2; 1286 } 1287 units dB ; 1288 mandatory true ; 1289 description ".."; 1290 } 1291 leaf tilt-target { 1292 type decimal64 { 1293 fraction-digits 2; 1294 } 1295 mandatory true ; 1296 description ".."; 1297 } 1298 leaf out-voa { 1299 type decimal64 { 1300 fraction-digits 2; 1301 } 1302 units dB; 1303 mandatory true; 1304 description ".."; 1305 } 1306 leaf in-voa { 1307 type decimal64 { 1308 fraction-digits 2; 1309 } 1310 units dB; 1311 mandatory true; 1312 description ".."; 1313 } 1314 uses power-param; 1315 } 1316 } 1317 } 1319 grouping fiber-params { 1320 description "String identifier of fiber type referencing a specification in a 1321 separate equipment catalog"; 1322 container fiber { 1323 description "fiber characteristics"; 1324 leaf type_variety { 1325 type string ; 1326 mandatory true ; 1327 description "fiber type"; 1328 } 1329 leaf length { 1330 type decimal64 { 1331 fraction-digits 2; 1332 } 1333 units km; 1334 mandatory true ; 1335 description "length of fiber"; 1336 } 1337 leaf loss_coef { 1338 type decimal64 { 1339 fraction-digits 2; 1340 } 1341 units dB/km; 1342 mandatory true ; 1343 description "loss coefficient of the fiber"; 1344 } 1345 leaf total_loss { 1346 type decimal64 { 1347 fraction-digits 2; 1348 } 1349 units dB; 1350 mandatory true ; 1351 description 1352 "includes all losses: fiber loss and conn_in and conn_out losses"; 1353 } 1354 leaf pmd{ 1355 type decimal64 { 1356 fraction-digits 2; 1357 } 1358 units sqrt(ps); 1359 description "pmd of the fiber"; 1360 } 1361 leaf conn_in{ 1362 type decimal64 { 1363 fraction-digits 2; 1364 } 1365 units dB; 1366 description "connector-in"; 1367 } 1368 leaf conn_out{ 1369 type decimal64 { 1370 fraction-digits 2; 1371 } 1372 units dB; 1373 description "connector-out"; 1374 } 1375 } 1376 } 1378 grouping roadm-params{ 1379 description "roadm parameters description"; 1380 container roadm{ 1381 description "roadm parameters"; 1382 leaf type_variety { 1383 type string ; 1384 mandatory true ; 1385 description "String identifier of roadm type referencing a specification in a 1386 separate equipment catalog"; 1387 } 1388 leaf loss { 1389 type decimal64 { 1390 fraction-digits 2; 1391 } 1392 units dB ; 1393 description ".."; 1394 } 1395 } 1396 } 1398 grouping concentratedloss-params{ 1399 description "concentrated loss"; 1400 container concentratedloss{ 1401 description "concentrated loss"; 1402 leaf loss { 1403 type decimal64 { 1404 fraction-digits 2; 1405 } 1406 units dB ; 1407 description ".."; 1408 } 1409 } 1410 } 1412 grouping power-param{ 1413 description 1414 "optical power or PSD after the ROADM or after the out-voa"; 1415 choice power-param { 1416 description 1417 "select the mode: channel power or power spectral density"; 1418 case channel-power { 1419 /* when "equalization-mode='channel-power'"; */ 1420 leaf nominal-channel-power{ 1421 type decimal64 { 1422 fraction-digits 1; 1423 } 1424 units dBm ; 1425 description 1426 " Reference channel power after the ROADM or after the out-voa. "; 1427 } 1428 } 1429 case power-spectral-density{ 1430 /* when "equalization-mode='power-spectral-density'"; */ 1431 leaf nominal-power-spectral-density{ 1432 type decimal64 { 1433 fraction-digits 16; 1434 } 1435 units W/Hz ; 1436 description 1437 " Reference power spectral density after the ROADM or after the out-voa. 1438 Typical value : 3.9 E-14, resolution 0.1nW/MHz"; 1439 } 1440 } 1441 } 1442 } 1444 grouping oms-general-optical-params { 1445 description "OMS link optical parameters"; 1446 leaf generalized-snr { 1447 type decimal64 { 1448 fraction-digits 5; 1450 } 1451 units "dB@0.1nm"; 1452 description "generalized snr"; 1453 } 1454 leaf equalization-mode{ 1455 type identityref { 1456 base type-power-mode; 1457 } 1458 mandatory true; 1459 description "equalization mode"; 1460 } 1461 uses power-param; 1462 } 1464 grouping OTSiG { 1465 description "OTSiG definition , representing client digital information stream 1466 supported by 1 or more OTSi"; 1468 container OTSiG-container { 1469 config false; 1470 description 1471 "the container contains the related list of OTSi. 1472 The list could also be of only 1 element"; 1473 list OTSi { 1474 key "OTSi-carrier-id"; 1475 description 1476 "list of OTSi's under OTSi-G"; 1477 leaf OTSi-carrier-id { 1478 type int16; 1479 description "OTSi carrier-id"; 1480 } 1481 leaf OTSi-carrier-frequency { 1482 type decimal64 { 1483 fraction-digits 3; 1484 } 1485 units GHz; 1486 config false; 1487 description 1488 "OTSi carrier frequency"; 1489 } 1490 leaf OTSi-signal-width { 1491 type decimal64 { 1492 fraction-digits 3; 1493 } 1494 units GHz; 1495 config false; 1496 description 1497 "OTSi signal width"; 1498 } 1499 leaf channel-delta-power { 1500 type decimal64 { 1501 fraction-digits 2; 1502 } 1503 units dB; 1504 config false; 1505 description 1506 "optional ; delta power to ref channel input-power applied 1507 to this media channel"; 1508 } 1510 } 1511 } // OTSiG container 1512 } // OTSiG grouping 1514 grouping media-channel-groups { 1515 description "media channel groups"; 1516 list media-channel-group { 1517 key "i"; 1518 description 1519 "list of media channel groups"; 1520 leaf i { 1521 type int16; 1522 description "index of media channel group member"; 1523 } 1525 list media-channels { 1526 key "flexi-n"; 1527 description 1528 "list of media channels represented as (n,m)"; 1529 uses layer0-types:flexi-grid-channel; 1530 leaf OTSiG-ref { 1531 type leafref { 1532 path "/nw:networks/nw:network/nw:node/tet:te" + 1533 "/tet:tunnel-termination-point/OTSiG-element/OTSiG-identifier" ; 1535 } 1536 description 1537 "Reference to the OTSiG list to get OTSiG identifier of the 1538 OSiG carried by this media channel that reports the transient stat"; 1539 } 1540 leaf OTSi-ref { 1541 type leafref { 1542 path "/nw:networks/nw:network/nw:node/tet:te" + 1543 "/tet:tunnel-termination-point/OTSiG-element[OTSiG- 1544 identifier=current()/../OTSiG-ref]/"+ 1545 "OTSiG-container/OTSi/OTSi-carrier-id" ; 1546 } 1547 description 1548 "Reference to the OTSi list supporting the related OTSiG" ; 1549 } 1551 } // media channels list 1552 } // media-channel-groups list 1553 } // media media-channel-groups grouping 1555 grouping oms-element { 1556 description "OMS description"; 1557 list OMS-elements { 1558 key "elt-index"; 1559 description 1560 "defines the spans and the amplifier blocks of the amplified lines"; 1561 leaf elt-index { 1562 type uint16; 1563 description 1564 "ordered list of Index of OMS element (whether it's a Fiber, an EDFA or a 1565 Concentratedloss)"; 1566 } 1567 leaf uid { 1568 type string; 1569 description 1570 "unique id of the element if it exists"; 1571 } 1572 leaf type { 1573 type identityref { 1574 base type-element; 1575 } 1576 mandatory true; 1577 description "element type"; 1578 } 1580 container element { 1581 description "element of the list of elements of the OMS"; 1582 choice element { 1583 description "OMS element type"; 1584 case amplifier { 1585 /* when "type = 'Edfa'"; */ 1586 uses amplifier-params ; 1587 } 1588 case fiber { 1589 /* when "type = 'Fiber'"; */ 1590 uses fiber-params ; 1591 } 1592 case concentratedloss { 1593 /* when "type = 'Concentratedloss'"; */ 1594 uses concentratedloss-params ; 1595 } 1597 } 1598 } 1599 } 1600 } 1602 /* Data nodes */ 1604 augment "/nw:networks/nw:network/nw:network-types" 1605 + "/tet:te-topology" { 1606 description "optical-impairment topology augmented"; 1607 container optical-impairment-topology { 1608 presence "indicates an impairment-aware topology of optical networks"; 1609 description 1610 "Container to identify impairment-aware topology type"; 1611 } 1612 } 1614 augment "/nw:networks/nw:network/nt:link/tet:te" 1615 + "/tet:te-link-attributes" { 1616 when "/nw:networks/nw:network/nw:network-types" 1617 +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { 1618 description 1619 "This augment is only valid for Optical Impairment."; 1620 } 1621 description "Optical Link augmentation for impairment data."; 1622 container OMS-attributes { 1623 config false; 1624 description "OMS attributes"; 1625 uses oms-general-optical-params; 1626 uses media-channel-groups; 1627 uses oms-element; 1628 } 1629 } 1631 augment "/nw:networks/nw:network/nw:node/tet:te" 1632 + "/tet:tunnel-termination-point" { 1633 when "/nw:networks/nw:network/nw:network-types" 1634 +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { 1635 description 1636 "This augment is only valid for Impairment with non-sliceable 1637 transponder model"; 1638 } 1639 description 1640 "Tunnel termination point augmentation for non-sliceable 1641 transponder model."; 1643 list OTSiG-element { 1644 key "OTSiG-identifier"; 1645 config false; 1646 description 1647 "the list of possible OTSiG representing client digital stream"; 1649 leaf OTSiG-identifier { 1650 type int16; 1651 description "index of OTSiG element"; 1652 } 1653 uses OTSiG; 1654 } 1656 list transponders-list { 1657 key "transponder-id"; 1658 config false; 1659 description "list of transponders"; 1660 leaf transponder-id { 1661 type uint32; 1662 description "transponder identifier"; 1663 } 1665 choice mode { 1666 description "standard mode, organizational mode or explicit mode"; 1668 case G.692.2 { 1669 uses standard_mode; 1670 } 1672 case organizational_mode { 1673 uses organizational_mode; 1674 } 1676 case explicit_mode { 1677 uses transponder-attributes; 1678 } 1679 } 1681 leaf power { 1682 type int32; 1683 units "dBm"; 1684 config false; 1685 description "per channel power"; 1686 } 1688 leaf power-min { 1689 type int32; 1690 units "dBm"; 1691 config false; 1692 description "minimum power of the transponder"; 1693 } 1694 leaf power-max { 1695 type int32; 1696 units "dBm"; 1697 config false; 1698 description "maximum power of the transponder"; 1699 } 1700 } 1701 } 1703 augment "/nw:networks/nw:network/nw:node/tet:te" 1704 + "/tet:tunnel-termination-point" { 1705 when "/nw:networks/nw:network/nw:network-types" 1706 +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { 1707 description 1708 "This augment is only valid for optical impairment with sliceable 1709 transponder model"; 1710 } 1711 description 1712 "Tunnel termination point augmentation for sliceable transponder model."; 1713 uses sliceable-transponder-attributes; 1714 } 1715 } 1716 1718 5. Security Considerations 1720 The configuration, state, and action data defined in this document 1721 are designed to be accessed via a management protocol with a secure 1722 transport layer, such as NETCONF [RFC6241]. The NETCONF access 1723 control model [RFC6536] provides the means to restrict access for 1724 particular NETCONF users to a preconfigured subset of all available 1725 NETCONF protocol operations and content. 1727 A number of configuration data nodes defined in this document are 1728 read-only; however, these data nodes may be considered sensitive or 1729 vulnerable in some network environments (TBD). 1731 6. IANA Considerations 1733 This document registers the following namespace URIs in the IETF XML 1734 registry [RFC3688]: 1736 -------------------------------------------------------------------- 1737 URI: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology 1738 Registrant Contact: The IESG. 1739 XML: N/A, the requested URI is an XML namespace. 1740 -------------------------------------------------------------------- 1742 This document registers the following YANG modules in the YANG 1743 Module Names registry [RFC7950]: 1745 -------------------------------------------------------------------- 1746 name: ietf-optical-impairment-topology 1747 namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment- 1748 topology 1749 prefix: optical-imp-topo 1750 reference: RFC XXXX (TDB) 1751 -------------------------------------------------------------------- 1753 7. Acknowledgments 1755 We thank Daniele Ceccarelli and Oscar G. De Dios for useful 1756 discussions and motivation for this work. 1758 8. References 1760 8.1. Normative References 1762 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1763 RFC 7950, August 2016. 1765 [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", 1766 RFC 8040, January 2017. 1768 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1769 Access Control Model", RFC 8341, March 2018. 1771 8.2. Informative References 1773 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1774 and A. Bierman, Ed., "Network Configuration Protocol 1775 (NETCONF)", RFC 6241, June 2011. 1777 [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework 1778 for the Control of Wavelength Switched Optical Networks 1779 (WSONs) with Impairments", RFC 6566, March 2012. 1781 [RFC7446] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 1782 Wavelength Assignment Information Model for Wavelength 1783 Switched Optical Networks", RFC 7446, Feburary 2015. 1785 [RFC7579] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General Network 1786 Element Constraint Encoding for GMPLS Controlled 1787 Networks", RFC 7579, June 2015. 1789 [RFC7581] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 1790 Wavelength Assignment Information Encoding for Wavelength 1791 Switched Optical Networks", RFC 7581, June 2015. 1793 [RFC7698] O. Gonzalez de Dios, Ed. and R. Casellas, Ed., "Framework 1794 and Requirements for GMPLS-Based Control of Flexi-Grid 1795 Dense Wavelength Division Multiplexing (DWDM) Networks", 1796 RFC 7698, November 2015. 1798 [RFC8340] M. Bjorklund, L. Berger, Ed., "YANG Tree Diagrams", RFC 1799 8340, March 2018. 1801 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1802 and R. Wilton, "Network Management Datastore Architecture 1803 (NMDA)", RFC 8342, March 2018. 1805 [RFC8345] A. Clemm, et al, "A YANG Data Model for Network 1806 Topologies", RFC 8345, March 2018. 1808 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies, work 1809 in progress: draft-ietf-teas-yang-te-topo. 1811 [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1812 Control of Traffic Engineered Networks", RFC 8453, August 1813 2018. 1815 [WSON-Topo] Y. Lee, Ed., "A Yang Data Model for WSON Optical 1816 Networks", draft-ietf-ccamp-wson-yang-13, work in 1817 progress. 1819 [L0-Types] Y. Lee, Ed., "A YANG Data Model for Layer 0 Types", 1820 draft-ietf-ccamp-layer0-types, work in progress. 1822 [G.807] "Draft new Recommendation ITU-T G.807 (ex G.media)", ITU-T 1823 Recommendation G.807, work in progress. 1825 [G.709] "Interfaces for the Optical Transport Network (OTN)", ITU-T 1826 Recommendation G.709, June 2016. 1828 [G.694.1] "Spectral grids for WDM applications: DWDM frequency 1829 grid", ITU-T Recommendation G.694.1, February 2012. 1831 [G.959.1] "Optical transport network physical layer interfaces", 1832 ITU-T Recommendation G.959.1, February 2012. 1834 [G.872] "Architecture of optical transport networks", ITU-T 1835 Recommendation G.872, January 2017. 1837 9. Contributors 1839 Jonas Martensson 1840 RISE 1842 Email: jonas.martensson@ri.se 1844 Aihua Guo 1845 Huawei Technologies 1847 Email: aguo@futurewei.com 1849 Authors' Addresses 1851 Young Lee 1852 SKKU (Sung Kyun Kwan University) 1854 Email: younglee.tx@gmail.com 1856 Haomian Zheng 1857 Huawei Technologies 1859 Email: zhenghaomian@huawei.com 1861 Italo Busi 1862 Huawei Technologies 1864 Email: Italo.Busi@huawei.com 1866 Nicola Sambo 1867 Scuola Superiore Sant'Anna 1869 Email: nicosambo@gmail.com 1871 Victor Lopez 1872 Telefonica 1874 Email: victor.lopezalvarez@telefonica.com 1875 G. Galimberti 1876 Cisco 1878 Email: ggalimbe@cisco.com 1880 Giovanni Martinelli 1881 Cisco 1882 Email: giomarti@cisco.com 1884 Jean Luc Auge 1885 Orange 1887 Email: jeanluc.auge@orange.com 1889 Esther Le Rouzic 1890 Orange 1892 Email: esther.lerouzic@orange.com 1894 Julien Meuric 1895 Orange 1897 Email: julien.meuric@orange.com 1899 Dieter Beller 1900 Nokia 1902 Email: dieter.beller@nokia.com 1904 Sergio Belotti 1905 Nokia 1907 Email: Sergio.belotti@nokia.com 1909 Griseri Enrico 1910 Nokia 1912 Email: enrico.griseri@nokia.com 1913 Gert Grammel 1914 Juniper 1916 Email: ggrammel@juniper.net