idnits 2.17.1 draft-ietf-ccamp-wson-iv-info-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2017) is 2477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-martinelli-ccamp-wson-iv-encode-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP G. Martinelli, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational X. Zhang, Ed. 5 Expires: January 2, 2018 Huawei Technologies 6 G. Galimberti 7 Cisco 8 A. Zanardi 9 D. Siracusa 10 F. Pederzolli 11 CREATE-NET 12 Y. Lee 13 F. Zhang 14 Huawei Technologies 15 July 2017 17 Information Model for Wavelength Switched Optical Networks (WSONs) with 18 Impairments Validation 19 draft-ietf-ccamp-wson-iv-info-05 21 Abstract 23 This document defines an information model to support Impairment- 24 Aware (IA) Routing and Wavelength Assignment (RWA) functionality. 25 This information model extends the information model for impairment- 26 free RWA process in WSON to facilitate computation of paths where 27 optical impairment constraints need to considered. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 2, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions, Applicability and Properties . . . . . . . . . . 3 65 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Properties . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. ITU-T List of Optical Parameters . . . . . . . . . . . . . . 6 69 4. Background from WSON-RWA Information Model . . . . . . . . . 9 70 5. Optical Impairment Information Model . . . . . . . . . . . . 10 71 5.1. The Optical Impairment Vector . . . . . . . . . . . . . . 10 72 5.2. Node Information . . . . . . . . . . . . . . . . . . . . 11 73 5.2.1. Impairment Matrix . . . . . . . . . . . . . . . . . . 11 74 5.2.2. Impairment Resource Block Information . . . . . . . . 12 75 5.3. Link Information . . . . . . . . . . . . . . . . . . . . 13 76 5.4. Path Information . . . . . . . . . . . . . . . . . . . . 13 77 6. Encoding Considerations . . . . . . . . . . . . . . . . . . . 13 78 7. Control Plane Architectures . . . . . . . . . . . . . . . . . 14 79 7.1. IV-Centralized . . . . . . . . . . . . . . . . . . . . . 14 80 7.2. IV-Distributed . . . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 11.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 17 88 A.1. Why the Application Code does not suffice for Optical 89 Impairment Validation? . . . . . . . . . . . . . . . . . 17 90 A.2. Are DWDM network multivendor? . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 In the context of Wavelength Switched Optical Network (WSON), 96 [RFC6163] describes the basic framework for a GMPLS and PCE-based 97 Routing and Wavelength Assignment (RWA) control plane. The 98 associated information model [RFC7446] defines information/parameters 99 required by an RWA process without optical impairment considerations. 101 There are cases of WSON where optical impairments play a significant 102 role and are considered as important constraints. The framework 103 document [RFC6566] defines the problem scope and related control 104 plane architectural options for the Impairment Aware RWA (IA-RWA) 105 operation. Options include different combinations of Impairment 106 Validation (IV) and RWA functions in term of different combination of 107 control plane functions (i.e., PCE, Routing, Signaling). 109 A Control Plane with RWA-IA will not be able to solve the optical 110 impairment problem in a detailed and exhaustive way, however, it may 111 take advantage of some data plane knowledge to make better decisions 112 during its path computing phase. The final outcome will be a path, 113 instantiated through a wavelength in the data plane, that has a 114 "better chance" to work than that path were calculated without IA 115 information. "Better chance" means that path setup may still fail 116 and the GMPLS control plane will follow its usual procedures upon 117 errors and failures. A control plane will not replace a the network 118 design phase that remains a fundamental step for DWDM Optical 119 Networks. As the non-linear impairments which need to be considered 120 in the calculation of an optical path will be vendor-dependent, the 121 parameters considered in this document is not an exhaustive list. 123 This document provides an information model for the impairment aware 124 case to allow the impairment validation function implemented in the 125 control plane or enabled by control plane available information. 126 This model goes in addition to [RFC7446] and shall support any 127 control plane architectural option described by the framework 128 document (see sections 4.2 and 4.3 of [RFC6566]) where a set of 129 combinations of control plane functions vs. IV function is provided. 131 2. Definitions, Applicability and Properties 133 This section provides some concepts to help understand the model and 134 to make a clear separation from data plane definitions (ITU-T 135 recommendations). The first sub-section provides definitions while 136 the Applicability sections uses the defined definitions to scope this 137 document. 139 2.1. Definitions 141 o Computational Model / Optical Computational Model. 142 Defined by ITU standard documents. In this context we look for 143 models able to compute optical impairments for a given lightpath. 145 o Information Model. 146 Defined by IETF (this document) and provides the set of 147 information required by control plane to apply the Computational 148 Model. 150 o Level of Approximation. 151 This concept refers to the Computational Model as it may compute 152 optical impairment with a certain level of uncertainty. This 153 level is generally not measured but [RFC6566] Section 4.1.1 154 provides a rough classification about it. 156 o Feasible Path. 157 It is the output of the C-SPF with RWA-IV capability. It's an 158 optical path that satisfies optical impairment constraints. The 159 path, instantiated through wavelength(s), may actually work or not 160 work depending of the level of approximation. 162 o Existing Service Disruption. 163 An effect known to optical network designers is the cross- 164 interaction among spectrally adjacent wavelengths: an existing 165 wavelength may experience increased BER due to the setup of an 166 adjacent wavelength. Solving this problem is a typical optical 167 network design activity. Just as an example, a simple solution is 168 adding optical margins (e.g., additional OSNR), although complex 169 and detailed methods exist. 171 o DWDM Line Segments. 172 [ITU.G680] provides definition and picture for the "Situation 1" 173 DWDM Line segments: " Situation 1 - The optical path between two 174 consecutive 3R regenerators is composed of DWDM line segments from 175 a single vendor and OADMs and PXCs from another vendor". Document 176 [RFC6566] Figure 1 shows an LSP composed by two DWDM line segments 177 according to [ITU.G680] definition. 179 2.2. Applicability 181 This document targets at Scenario C defined in [RFC6566] section 182 4.1.1. as approximate impairment estimation. The Approximate 183 concept refer to the fact that this Information Model covers 184 information mainly provided by [ITU.G680] Computational Model. 186 Computational models having no or little approximation, referred as 187 IV-Detailed in the [RFC6566], currently does not exist in term of 188 ITU-T recommendation. They generally deal with non-linear optical 189 impairment and are usually vendor specific. 191 The Information Model defined in this document does not speculate 192 about the mathematical formulas used to fill up information model 193 parameters, hence it does not preclude changing the computational 194 model. At the same time, the authors do not believe this Information 195 Model is exhaustive and if necessary further documents will cover 196 additional models after they become available. 198 The result of RWA-IV process implementing this Information Model is a 199 path (and a wavelength in the data plane) that has better chance to 200 be feasible than if it was computed without any IV function. The 201 Existing Service Disruption, as per the definition above, would still 202 be a problem left to a network design phase. 204 2.3. Properties 206 An information model may have several attributes or properties that 207 need to be defined for each optical parameter made available to the 208 control plane. The properties will help to determine how the control 209 plane can deal with a specific impairment parameter, depending on 210 architectural options chosen within the overall impairment framework 211 [RFC6566]. In some case, properties value will help to identify the 212 level of approximation supported by the IV process. 214 o Time Dependency 215 This identifies how an impairment parameter may vary with time. 216 There could be cases where there is no time dependency, while in 217 other cases there may be need of re-evaluation after a certain 218 time. In this category, variations in impairments due to 219 environmental factors such as those discussed in [ITU.GSUP47] are 220 considered. In some cases, an impairment parameter that has time 221 dependency may be considered as a constant for approximation. In 222 this information model, we do neglect this property. 224 o Wavelength Dependency 225 This property identifies if an impairment parameter can be 226 considered as constant over all the wavelength spectrum of 227 interest or not. Also in this case a detailed impairment 228 evaluation might lead to consider the exact value while an 229 approximation IV might take a constant value for all wavelengths. 230 In this information model, we consider both case: dependency / no 231 dependency on a specific wavelength. This property appears 232 directly in the information model definitions and related 233 encoding. 235 o Linearity 236 As impairments are representation of physical effects, there are 237 some that have a linear behaviour while other are non-linear. 238 Linear approximation is in scope of Scenario C of [RFC6566]. 239 During the impairment validation process, this property implies 240 that the optical effect (or quantity) satisfies the superposition 241 principle, thus a final result can be calculated by the sum of 242 each component. The linearity implies the additivity of optical 243 quantities considered during an impairment validation process. 244 The non-linear effects in general do not satisfy this property. 245 The information model presented in this document however, easily 246 allow introduction of non-linear optical effects with a linear 247 approximated contribution to the linear ones. 249 o Multi-Channel 250 There are cases where a channel's impairments take different 251 values depending on the aside wavelengths already in place, this 252 is mostly due to non-linear impairments. The result would be a 253 dependency among different LSPs sharing the same path. This 254 information model do not consider this kind of property. 256 The following table summarise the above considerations where in the 257 first column reports the list of properties to be considered for each 258 optical parameter, while the second column states if this property is 259 taken into account or not by this information model. 261 +-----------------------+----------------------+ 262 | Property | Info Model Awareness | 263 +-----------------------+----------------------+ 264 | Time Dependency | no | 265 | Wavelength Dependency | yes | 266 | Linearity | yes | 267 | Multi-channel | no | 268 +-----------------------+----------------------+ 270 Table 1: Optical Impairment Properties 272 3. ITU-T List of Optical Parameters 274 As stated by Section 2.2 this Information Model does not intend to be 275 exhaustive and targets an approximate computational model although 276 not precluding future evolutions towards more detailed or different 277 impairments estimation methods. 279 On the same line, ITU SG15/Q6 provides (through [LS78]) a list of 280 optical parameters with following observations: 282 (a) the problem of calculating the non-linear impairments in a 283 multi-vendor environment is not solved. The transfer functions 284 works only for the so called [ITU.G680] "Situation 1". 286 (b) The generated list of parameters is not exhaustive however 287 provide a guideline for control plane optical impairment 288 awareness. 290 In particular, [ITU.G680] contains many parameters that would be 291 required to estimate linear impairments. Some of the Computational 292 Models defined within [ITU.G680] requires parameters defined in 293 other documents like [ITU.G671]. The purpose of the list here below 294 makes this match between the two documents. 296 [ITU.G697] defines parameters can be monitored in an optical network. 297 This Information Model and associated encoding document will reuse 298 [ITU.G697] parameters identifiers and encoding for the purpose of 299 path computation. 301 The list of optical parameters starts from [ITU.G680] Section 9 which 302 provides the optical computational models for the following p: 304 G-1 OSNR. Section 9.1 306 G-2 Chromatic Dispersion (CD). Section 9.2 308 G-3 Polarization Mode Dispersion (PMD). Section 9.3 310 G-4 Polarization Dependent Loss (PDL). Section 9.3 312 In addition to the above, the following list of parameters has been 313 mentioned by [LS78]: 315 L-1 "Channel frequency range", [ITU.G671]. This parameter is part 316 of the application code and encoded through Optical Interface 317 Class as defined in [RFC7446]. 319 L-2 "Modulation format and rate". This parameter is part of the 320 application code and encoded through Optical Interface Class as 321 defined in [RFC7446]. 323 L-3 "Channel power". Required by G-1. 325 L-4 "Ripple". According to [ITU.G680], this parameter can be taken 326 into account as additional OSNR penalty. 328 L-5 "Channel signal-spontaneous noise figure", [ITU.G680]. 329 Required by OSNR calculation (see G-1) above. 331 L-6 "Channel chromatic dispersion (for fibre segment or network 332 element)". Already in G-2 above. 334 L-7 "Channel local chromatic dispersion (for a fibre segment)". 335 Already in G-2 above (since consider both local and fiber 336 dispersions). 338 L-8 "Differential group delay (for a network element)", [ITU.G671]. 339 Required by G-3. 341 L-9 "Polarisation mode dispersion (for a fibre segment)", 342 [ITU.G650.2], [ITU.G680]. Defined above as G-3. 344 L-10 "Polarization dependent loss (for a network element)", 345 [ITU.G671] and [ITU.G680]. Defined above as G-4. 347 L-11 "Reflectance". From [ITU.G671] Section 3.2.2.37 is the ratio 348 of reflected power Pr to incident power Pi at a given port of a 349 passive component, for given conditions of spectral 350 composition, polarization and geometrical distribution. 351 Generally expressed in dB. Might be monitored in some critical 352 cases. We neglect this effect as first approximation. 354 L-12 "Channel Isolation". From [ITU.G671] Section 3.2.2.2 (Adjacent 355 Channel Isolation) and Section 3.2.2.29 (Non Adjacent Channel 356 Isolation). Document [ITU.GSUP39] provide the formula for 357 calculation as channel cross-talk and measure it in dB. This 358 parameterer shall be considered for path computation. 360 L-13 "Channel extinction". From [ITU.G671] Section 3.2.2.9 needed 361 for Interferometric Crosstalk. Document [ITU.GSUP39] has the 362 formula for penalty computation. Unit of measurement is dB. 364 L-14 "Attenuation coefficient (for a fibre segment)". Document 365 [ITU.G650.1] Section 3.6.2. The unit of measure is dB. This 366 is a typical link parameter (as associated to a fiber). 368 L-15 "Non-linear coefficient (for a fibre segment)", [ITU.G650.2]. 369 Required for Non-Linear Optical Impairment Computational 370 Models. Neglected by this document. 372 The final list of parameters is G-1, G-2, G-3, G-4, L-3, L-4, L-5, 373 L-8, L-12, L-13, L-14. 375 4. Background from WSON-RWA Information Model 377 In this section we report terms already defined for the WSON-RWA 378 (impairment free) as in [RFC7446] and [RFC7579]. The purpose is to 379 provide essential information that will be reused or extended for the 380 impairment case. 382 In particular [RFC7446] Section 4.1 defines the ConnectivityMatrix 383 and states that such matrix does not represent any particular 384 internal blocking behaviour but indicates which input ports and 385 wavelengths could possibly be connected to a particular output port. 387 ::= 389 According to [RFC7579], this definition is further detailed as: 391 ::= 392 (( ) ...) 394 This second formula highlights how the ConnectivityMatrix is built by 395 pairs of LinkSet objects identifying the internal connectivity 396 capability due to internal optical node constraint(s). It's 397 essentially binary information and tell if a wavelength or a set of 398 wavelengths can go from an input port to an output port. 400 As an additional note, ConnectivityMatrix belongs to node 401 information, is uniquely identified by advertising node and is a 402 static information. Dynamic information related to the actual state 403 of connections is available through specific extension to link 404 information. 406 The [RFC7446] introduces the concept of ResourceBlockInfo and 407 ResourcePool for the WSON nodes. The resource block is a collection 408 of resources behaving in the same way and having similar 409 characteristics. The ResourceBlockInfo is defined as follow: 411 ::= [] 412 [] [] 414 The usage of resource block and resource pool is an efficient way to 415 model constrains within a WSON node. 417 5. Optical Impairment Information Model 419 The idea behind this document is to put optical impairment parameters 420 into categories and extend the information model already defined for 421 impairment-free WSONs. The three categories are: 423 o Node Information. The concept of connectivity matrix is reused 424 and extended to introduce an impairment matrix, which represents 425 the impairments suffered on the internal path between two ports. 426 In addition, the concept of Resource Block is also reused and 427 extended to provide an efficient modelization of per-port 428 impairment. 430 o Link Information representing impairment information related to a 431 specific link or hop. 433 o Path Information representing the impairment information related 434 to the whole path. 436 All the above three categories will make use of a generic container, 437 the Impairment Vector, to transport optical impairment information. 439 This information model however will allow however to add additional 440 parameters beyond the one defined by [ITU.G680] in order to support 441 additional computational models. This mechanism could eventually 442 applicable to both linear and non-linear parameters. 444 This information model makes the assumption that the each optical 445 node in the network is able to provide the control plane protocols 446 with its own parameter values. However, no assumption is made on how 447 the optical nodes get those value information (e.g., internally 448 computed, provisioned by a network management system, etc.). To this 449 extent, the information model intentionally ignores all internal 450 detailed parameters that are used by the formulas of the Optical 451 Computational Model (i.e., "transfer function") and simply provides 452 the object containers to carry results of the formulas. 454 5.1. The Optical Impairment Vector 456 Optical Impairment Vector (OIV) is defined as a list of optical 457 parameters to be associated to a WSON node or a WSON link. It is 458 defined as: 460 ::= ([] ) ... 462 The optional LabelSet object enables wavelength dependency property 463 as per Table 1. LabelSet has its definition in [RFC7579]. 465 OPTICAL_PARAM. This object represents an optical parameter. The 466 Impairment vector can contain a set of parameters as identified by 467 [ITU.G697] since those parameters match the terms of the linear 468 impairments computational models provided by [ITU.G680]. This 469 information model does not speculate about the set of parameters 470 (since defined elsewhere, e.g. ITU-T), however it does not preclude 471 extentions by adding new parameters. 473 5.2. Node Information 475 5.2.1. Impairment Matrix 477 Impairment matrix describes a list of the optical parameters that 478 applies to a network element as a whole or ingress/egress port pairs 479 of a network element. Wavelength dependency property of optical 480 parameters is also considered. 482 ImpairmentMatrix ::= 483 (( ) ...) 485 Where: 487 MatrixID. This ID is a unique identifier for the matrix. It 488 shall be unique in scope among connectivity matrices defined in 489 [RFC7446] and impairment matrices defined here. 491 ConnType. This number identifies the type of matrix and it shall 492 be unique in scope with other values defined by impairment-free 493 WSON documents. 495 LinkSet. Same object definition and usage as [RFC7579]. The 496 pairs of LinkSet identify one or more internal node constrain. 498 OIV. The Optical Impairment Vector defined above. 500 The model can be represented as a multidimensional matrix shown in 501 the following picture 502 _________________________________________ 503 / / / / / /| 504 / / / / / / | 505 /________/_______/_______/_______/_______/ | 506 / / / / / /| /| 507 / / / / / / | | 508 /________/_______/_______/_______/_______/ | /| 509 / / / / / /| /| | 510 / / / / / / | | /| 511 /________/_______/_______/_______/_______/ | /| | 512 / / / / / /| /| | /| 513 / / / / / / | | /| | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL 515 | - | | | | | /| | /|/ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| / 517 | | - | | | | /| | / PND 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/ 519 | | | - | | | /| / 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp. 521 | | | | - | | /|/ 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 523 | | | | | - | / OSNR 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 527 The connectivity matrix from [RFC7579] is only a two dimensional 528 matrix, containing only binary information, through the LinkSet 529 pairs. In this model, a third dimension is added by generalizing the 530 binary information through the Optical Impairment Vector associated 531 with each LinkSet pair. Optical parameters in the picture are 532 reported just as an example: proper list and encoding shall be 533 defined by other documents. 535 This representation shows the most general case however, the total 536 amount of information transported by control plane protocols can be 537 greatly reduced by proper encoding when the same set of values apply 538 to all LinkSet pairs. 540 5.2.2. Impairment Resource Block Information 542 This information model reuses the definition of Resource Block 543 Information adding the associated impairment vector. 545 ResourceBlockInfo ::= [] 546 [] [] [] 548 The object ResourceBlockInfo is than used as specified within 549 [RFC7446]. 551 5.3. Link Information 553 For the list of optical parameters associated to the link, the same 554 approach used for the node-specific impairment information can be 555 applied. The link-specific impairment information is extended from 556 [RFC7446] as the following: 558 ::= 559 [] [] 561 DynamicLinkInfo is already defined in [RFC7446] while OIV is the 562 Optical Impairment Vector is defined in the previous section. 564 5.4. Path Information 566 There are cases where the optical impairments can only be described 567 as a constrains on the overall end to end path. In such case, the 568 optical impairment and/or parameter, cannot be derived (using a 569 simple function) from the set of node / link contributions. 571 An equivalent case is the option reported by [RFC6566] on IV- 572 Candidate paths where, the control plane knows a list of optically 573 feasible paths so a new path setup can be selected among that list. 574 Independent from the protocols and functions combination (i.e. RWA 575 vs. Routing vs. PCE), the IV-Candidates imply a path property stating 576 that a path is optically feasible. 578 ::= 580 [EDITOR NOTE: section to be completed, especially to evaluate 581 protocol implications. Likely resemble to RSVP ADSPEC]. 583 6. Encoding Considerations 585 Details about encoding will be defined in a separate document 586 [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, 587 within [ITU.G697] Appending V, ITU already provides a guideline for 588 encoding some optical parameters. 590 In particular [ITU.G697] indicates that each parameter shall be 591 represented by a 32 bit floating point number. 593 Values for optical parameters are provided by optical node and it 594 could provide by direct measurement or from some internal computation 595 starting from indirect measurement. In such cases, it could be 596 useful to understand the variance associated with the value of the 597 optical parameter hence, the encoding shall provide the possibility 598 to include a variance as well. 600 This kind of information will enable IA-RWA process to make some 601 additional considerations on wavelength feasibility. [RFC6566] 602 Section 4.1.3 reports some considerations regarding this degree of 603 confidence during the impairment validation process. 605 7. Control Plane Architectures 607 This section briefly describes how the definitions contained in this 608 information model will match the architectural options described by 609 [RFC6566]. 611 The first assumption is that the WSON GMPLS extensions are available 612 and operational. To such extent, the WSON-RWA will provide the 613 following information through its path computation (and RWA process): 615 o The wavelengths connectivity, considering also the connectivity 616 constraints limited by reconfigurable optics, and wavelengths 617 availability. 619 o The interface compatibility at the physical level. 621 o The Optical-Elettro-Optical (OEO) availability within the network 622 (and related physical interface compatibility). As already stated 623 by the framework this information it's very important for 624 impairment validation: 626 A. If the IV functions fail (path optically infeasible), the path 627 computation function may use an available OEO point to find a 628 feasible path. In normally operated networks OEO are mainly 629 uses to support optically unfeasible path than mere wavelength 630 conversion. 632 B. The OEO points reset the optical impairment information since 633 a new light is generated. 635 7.1. IV-Centralized 637 Centralized IV process is performed by a single entity (e.g., a PCE). 638 Given sufficient impairment information, it can either be used to 639 provide a list of paths between two nodes, which are valid in terms 640 of optical impairments. Alternatively, it can help validate whether 641 a particular selected path and wavelength is feasible or not. This 642 requires distribution of impairment information to the entity 643 performing the IV process. 645 This Information Model doesn't make any hypothesis on distribution 646 method for optical parameters but only defines the essential build 647 blocks. A centralized entity may get knowledge of required 648 information through routing protocols or other mechanism such as BGP- 649 LS. 651 7.2. IV-Distributed 653 Assuming the information model is implemented through a routing 654 protocol, every node in the WSON network shall be able to perform an 655 RWA-IV function. 657 The signalling phase may provide additional checking as others 658 traffic engineering parameters. 660 8. Acknowledgements 662 Authors would like to acknoledge Greg Bernstein and Moustafa Kattan 663 as authors of a previous similar draft whose content partially 664 converged here. 666 Authors would like to thank ITU SG15/Q6 and in particular Peter 667 Stassar and Pete Anslow for providing useful information and text to 668 CCAMP through join meetings and liaisons. 670 9. IANA Considerations 672 This document does not contain any IANA requirement. 674 10. Security Considerations 676 This document defines an information model for impairments in optical 677 networks. If such a model is put into use within a network it will 678 by its nature contain details of the physical characteristics of an 679 optical network. Such information would need to be protected from 680 intentional or unintentional disclosure. 682 11. References 684 11.1. Normative References 686 [ITU.G650.1] 687 International Telecommunications Union, "Transmission 688 media and optical systems characteristics - Optical fibre 689 cable", ITU-T Recommendation G.650.1, July 2010. 691 [ITU.G650.2] 692 International Telecommunications Union, "Definitions and 693 test methods for statistical and non-linear related 694 attributes of single-mode fibre and cable", 695 ITU-T Recommendation G.650.2, August 2015. 697 [ITU.G671] 698 International Telecommunications Union, "Transmission 699 characteristics of optical components and subsystems", 700 ITU-T Recommendation G.671, February 2012. 702 [ITU.G680] 703 International Telecommunications Union, "Physical transfer 704 functions of optical network elements", 705 ITU-T Recommendation G.680, July 2007. 707 [ITU.G697] 708 International Telecommunications Union, "Optical 709 monitoring for dense wavelength division multiplexing 710 systems", ITU-T Recommendation G.697, February 2012. 712 [ITU.GSUP39] 713 International Telecommunications Union, "Optical System 714 Design and Engineering Considerations", 715 ITU-T Recommendation G. Supplement 39, September 2012. 717 [ITU.GSUP47] 718 International Telecommunications Union, "General aspects 719 of optical fibres and cables", ITU-T Recommendation G. 720 Supplement 47, September 2012. 722 11.2. Informative References 724 [I-D.martinelli-ccamp-wson-iv-encode] 725 Martinelli, G., Zhang, X., Galimberti, G., Siracusa, D., 726 Zanardi, A., Pederzolli, F., Lee, Y., and F. Zhang, 727 "Information Encoding for WSON with Impairments 728 Validation", draft-martinelli-ccamp-wson-iv-encode-07 729 (work in progress), October 2016. 731 [LS78] International Telecommunications Union SG15/Q6, "LS/s on 732 CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON", 733 LS https://datatracker.ietf.org/liaison/1288/, October 734 2013. 736 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 737 "Framework for GMPLS and Path Computation Element (PCE) 738 Control of Wavelength Switched Optical Networks (WSONs)", 739 RFC 6163, DOI 10.17487/RFC6163, April 2011, 740 . 742 [RFC6566] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and G. 743 Martinelli, "A Framework for the Control of Wavelength 744 Switched Optical Networks (WSONs) with Impairments", 745 RFC 6566, DOI 10.17487/RFC6566, March 2012, 746 . 748 [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, 749 "Routing and Wavelength Assignment Information Model for 750 Wavelength Switched Optical Networks", RFC 7446, 751 DOI 10.17487/RFC7446, February 2015, 752 . 754 [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and 755 J. Han, "General Network Element Constraint Encoding for 756 GMPLS-Controlled Networks", RFC 7579, 757 DOI 10.17487/RFC7579, June 2015, 758 . 760 Appendix A. FAQ 762 A.1. Why the Application Code does not suffice for Optical Impairment 763 Validation? 765 Application Codes are encoded within GMPLS WSON protocol through the 766 Optical Interface Class as defined in [RFC7446]. 768 The purpose of the Application Code in RWA is simply to assess the 769 interface compatibility: same Application Code means that two 770 interfaces can have an LSP connecting the two. 772 Application Codes contain other information useful for IV process 773 (e.g., see the list of parameters) so they are required however 774 Computational Models requires more parameteres to assess the path 775 feasibility. 777 A.2. Are DWDM network multivendor? 779 According to [ITU.G680] "Situation 1" the DWDM line segments are 780 single are single vendor but an LSP can make use of different data 781 planes entities from different vendors. For example: DWDM interfaces 782 (represented in the control plane through the Optical Interface 783 Class) from a vendor and network elements described by Stutation 1 784 from another vendor. 786 Authors' Addresses 788 Giovanni Martinelli (editor) 789 Cisco 790 via Santa Maria Molgora, 48/C 791 Vimercate, MB 20871 792 Italy 794 Phone: +39 039 2092044 795 Email: giomarti@cisco.com 797 Xian Zhang (editor) 798 Huawei Technologies 799 F3-5-B R&D Center, Huawei Base 800 Bantian, Longgang District 801 Shenzen 518129 802 P.R. China 804 Phone: +86 755 28972465 805 Email: zhang.xian@huawei.com 807 Gabriele M. Galimberti 808 Cisco 809 Via Santa Maria Molgora, 48/C 810 Vimercate, MB 20871 811 Italy 813 Phone: +39 039 2091462 814 Email: ggalimbe@cisco.com 815 Andrea Zanardi 816 CREATE-NET 817 via alla Cascata 56/D, Povo 818 Trento 38123 819 Italy 821 Email: andrea.zanardi@create-net.org 823 Domenico Siracusa 824 CREATE-NET 825 via alla Cascata 56/D, Povo 826 Trento 38123 827 Italy 829 Email: domenico.siracusa@create-net.org 831 Federico Pederzolli 832 CREATE-NET 833 via alla Cascata 56/D, Povo 834 Trento 38123 835 Italy 837 Email: federico.perderzolli@create-net.org 839 Young Lee 840 Huawei Technologies 841 1700 Alma Drive, Suite 100 842 Plano, TX 75075 843 U.S.A 845 Email: ylee@huawei.com 847 Fatai Zhang 848 Huawei Technologies 849 F3-5-B R&D Center, Huawei Base 850 Bantian, Longgang District 851 Shenzen 518129 852 P.R. China 854 Email: zhang.fatai@huawei.com