idnits 2.17.1 draft-ietf-ccamp-wson-iv-info-04.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 (March 13, 2017) is 2599 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: September 14, 2017 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 March 13, 2017 17 Information Model for Wavelength Switched Optical Networks (WSONs) with 18 Impairments Validation 19 draft-ietf-ccamp-wson-iv-info-04 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 September 14, 2017. 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 foundamental 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 definitive or exaustive. 288 In particular, [ITU.G680] contains many parameters that would be 289 required to estimate linear impairments. Some of the Computational 290 Models defined within [ITU.G680] requires parameters defined in 291 other documents like [ITU.G671]. The purpose of the list here below 292 makes this match between the two documents. 294 [ITU.G697] defines parameters can be monitored in an optical network. 295 This Information Model and associated encoding document will reuse 296 [ITU.G697] parameters identifiers and encoding for the purpose of 297 path computation. 299 The list of optical parameters starts from [ITU.G680] Section 9 which 300 provides the optical computational models for the following p: 302 G-1 OSNR. Section 9.1 304 G-2 Chromatic Dispersion (CD). Section 9.2 306 G-3 Polarization Mode Dispersion (PMD). Section 9.3 308 G-4 Polarization Dependent Loss (PDL). Section 9.3 310 In addition to the above, the following list of parameters has been 311 mentioned by [LS78]: 313 L-1 "Channel frequency range", [ITU.G671]. This parameter is part 314 of the application code and encoded through Optical Interface 315 Class as defined in [RFC7446]. 317 L-2 "Modulation format and rate". This parameter is part of the 318 application code and encoded through Optical Interface Class as 319 defined in [RFC7446]. 321 L-3 "Channel power". Required by G-1. 323 L-4 "Ripple". According to [ITU.G680], this parameter can be taken 324 into account as additional OSNR penalty. 326 L-5 "Channel signal-spontaneous noise figure", [ITU.G680]. 327 Required by OSNR calculation (see G-1) above. 329 L-6 "Channel chromatic dispersion (for fibre segment or network 330 element)". Already in G-2 above. 332 L-7 "Channel local chromatic dispersion (for a fibre segment)". 333 Already in G-2 above (since consider both local and fiber 334 dispersions). 336 L-8 "Differential group delay (for a network element)", [ITU.G671]. 337 Required by G-3. 339 L-9 "Polarisation mode dispersion (for a fibre segment)", 340 [ITU.G650.2], [ITU.G680]. Defined above as G-3. 342 L-10 "Polarization dependent loss (for a network element)", 343 [ITU.G671] and [ITU.G680]. Defined above as G-4. 345 L-11 "Reflectance". From [ITU.G671] Section 3.2.2.37 is the ratio 346 of reflected power Pr to incident power Pi at a given port of a 347 passive component, for given conditions of spectral 348 composition, polarization and geometrical distribution. 349 Generally expressed in dB. Might be monitored in some critical 350 cases. We neglect this effect as first approximation. 352 L-12 "Channel Isolation". From [ITU.G671] Section 3.2.2.2 (Adjacent 353 Channel Isolation) and Section 3.2.2.29 (Non Adjacent Channel 354 Isolation). Document [ITU.GSUP39] provide the formula for 355 calculation as channel cross-talk and measure it in dB. This 356 paramterer shall be considered for path computation. 358 L-13 "Channel extinction". From [ITU.G671] Section 3.2.2.9 needed 359 for Interferometric Crosstalk. Document [ITU.GSUP39] has the 360 formula for penalty computation. Unit of measurement is dB. 362 L-14 "Attenuation coefficient (for a fibre segment)". Document 363 [ITU.G650.1] Section 3.6.2. The unit of measure is dB. This 364 is a typical link parameter (as associated to a fiber). 366 L-15 "Non-linear coefficient (for a fibre segment)", [ITU.G650.2]. 367 Required for Non-Linear Optical Impairment Computational 368 Models. Neglected by this document. 370 The final list of parameters is G-1, G-2, G-3, G-4, L-3, L-4, L-5, 371 L-8, L-12, L-13, L-14. 373 4. Background from WSON-RWA Information Model 375 In this section we report terms already defined for the WSON-RWA 376 (impairment free) as in [RFC7446] and [RFC7579]. The purpose is to 377 provide essential information that will be reused or extended for the 378 impairment case. 380 In particular [RFC7446] Section 4.1 defines the ConnectivityMatrix 381 explaing that it does not represent any particular internal blocking 382 behavior but indicates which input ports and wavelengths could 383 possibly be connected to a particular output port. 385 ::= 387 According to [RFC7579], this definition is further detailed as: 389 ::= 390 (( ) ...) 392 This second formula highlights how the ConnectivityMatrix is built by 393 pairs of LinkSet objects identifying the internal connectivity 394 capability due to internal optical node constraint(s). It's 395 essentially binary information and tell if a wavelength or a set of 396 wavelengths can go from an input port to an output port. 398 As an additional note, ConnectivityMatrix belongs to node 399 information, is uniquely identified by adverstising node and is a 400 static information. Dynamic information related to the actual state 401 of connections is available through specific extension to link 402 information. 404 The [RFC7446] introduces the concept of ResourceBlockInfo and 405 ResourcePool for the WSON nodes. The resource block is a collection 406 of resources behaving in the same way and having similar 407 characteristics. The ResourceBlockInfo is defined as follow: 409 ::= [] 410 [] [] 412 The usage of resorurce block and resource pool is an efficient way to 413 model constrains within a WSON node. 415 5. Optical Impairment Information Model 417 The idea behind this information model is to categorize the 418 impairment parameters into three types and extend the information 419 model already defined for impairment-free WSONs. The three 420 categories are: 422 o Node Information. The concept of connectivity matrix is reused 423 and extended to introduce an impairment matrix, which represents 424 the impairments suffered on the internal path between two ports. 425 In addition, the concept of Resource Block is also reused and 426 extended to provide an efficient modelization of per-port 427 impairment. 429 o Link Information representing impairment information related to a 430 specific link or hop. 432 o Path Information representing the impairment information related 433 to the whole path. 435 All the above three categories will make use of a generic container, 436 the Impairment Vector, to transport optical impairment information. 438 This information model however will allow however to add additional 439 parameters beyond the one defined by [ITU.G680] in order to support 440 additional computational models. This mechanism could eventually 441 applicable to both linear and non-linear parameters. 443 This information model makes the assumption that the each optical 444 node in the network is able to provide the control plane protocols 445 with its own parameter values. However, no assumption is made on how 446 the optical nodes get those value information (e.g., internally 447 computed, provisioned by a network management system, etc.). To this 448 extent, the information model intentionally ignores all internal 449 detailed parameters that are used by the formulas of the Optical 450 Computational Model (i.e., "transfer function") and simply provides 451 the object containers to carry results of the formulas. 453 5.1. The Optical Impairment Vector 455 Optical Impairment Vector (OIV) is defined as a list of optical 456 parameters to be associated to a WSON node or a WSON link. It is 457 defined as: 459 ::= ([] ) ... 461 The optional LabelSet object enables wavelength dependency property 462 as per Table 1. LabelSet has its definition in [RFC7579]. 464 OPTICAL_PARAM. This object represents an optical parameter. The 465 Impairment vector can contain a set of parameters as identified by 466 [ITU.G697] since those parameters match the terms of the linear 467 impairments computational models provided by [ITU.G680]. This 468 information model does not speculate about the set of parameters 469 (since defined elsewhere, e.g. ITU-T), however it does not preclude 470 extentions by adding new parameters. 472 5.2. Node Information 474 5.2.1. Impairment Matrix 476 Impairment matrix describes a list of the optical parameters that 477 applies to a network element as a whole or ingress/egress port pairs 478 of a network element. Wavelength dependency property of optical 479 paramters is also considered. 481 ImpairmentMatrix ::= 482 (( ) ...) 484 Where: 486 MatrixID. This ID is a unique identifier for the matrix. It 487 shall be unique in scope among connectivity matrices defined in 488 [RFC7446] and impairment matrices defined here. 490 ConnType. This number identifies the type of matrix and it shall 491 be unique in scope with other values defined by impairment-free 492 WSON documents. 494 LinkSet. Same object definition and usage as [RFC7579]. The 495 pairs of LinkSet identify one or more internal node constrain. 497 OIV. The Optical Impairment Vector defined above. 499 The model can be represented as a multidimensional matrix shown in 500 the following picture 501 _________________________________________ 502 / / / / / /| 503 / / / / / / | 504 /________/_______/_______/_______/_______/ | 505 / / / / / /| /| 506 / / / / / / | | 507 /________/_______/_______/_______/_______/ | /| 508 / / / / / /| /| | 509 / / / / / / | | /| 510 /________/_______/_______/_______/_______/ | /| | 511 / / / / / /| /| | /| 512 / / / / / / | | /| | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL 514 | - | | | | | /| | /|/ 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| / 516 | | - | | | | /| | / PND 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/ 518 | | | - | | | /| / 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp. 520 | | | | - | | /|/ 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 522 | | | | | - | / OSNR 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 526 The connectivity matrix from [RFC7579] is only a two dimensional 527 matrix, containing only binary information, through the LinkSet 528 pairs. In this model, a third dimension is added by generalizing the 529 binary information through the Optical Impairment Vector associated 530 with each LinkSet pair. Optical parameters in the picture are 531 reported just as examples while details go into specific encoding 532 draft [I-D.martinelli-ccamp-wson-iv-encode]. 534 This representation shows the most general case however, the total 535 amount of information transported by control plane protocols can be 536 greatly reduced by proper encoding when the same set of values apply 537 to all LinkSet pairs. 539 5.2.2. Impairment Resource Block Information 541 This information model reuses the definition of Resource Block 542 Information adding the associated impairment vector. 544 ResourceBlockInfo ::= [] 545 [] [] [] 547 The object ResourceBlockInfo is than used as specified within 548 [RFC7446]. 550 5.3. Link Information 552 For the list of optical parameters associated to the link, the same 553 approach used for the node-specific impairment information can be 554 applied. The link-specific impairment information is extended from 555 [RFC7446] as the following: 557 ::= 558 [] [] 560 DynamicLinkInfo is already defined in [RFC7446] while OIV is the 561 Optical Impairment Vector is defined in the previous section. 563 5.4. Path Information 565 There are cases where the optical impariments can only be described 566 as a contrains on the overall end to end path. In such case, the 567 optical impariment and/or parameter, cannot be derived (using a 568 simple function) from the set of node / link contributions. 570 An equivalent case is the option reported by [RFC6566] on IV- 571 Candidate paths where, the control plane knows a list of optically 572 feasible paths so a new path setup can be selected among that list. 573 Independent from the protocols and functions combination (i.e. RWA 574 vs. Routing vs. PCE), the IV-Candidates imply a path property stating 575 that a path is optically feasible. 577 ::= 579 [EDITOR NOTE: section to be completed, especially to evaluate 580 protocol implications. Likely resemble to RSVP ADSPEC]. 582 6. Encoding Considerations 584 Details about encoding will be defined in a separate document 585 [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, 586 within [ITU.G697] Appending V, ITU already provides a guideline for 587 encoding some optical parameters. 589 In particular [ITU.G697] indicates that each parameter shall be 590 represented by a 32 bit floating point number. 592 Values for optical parameters are provided by optical node and it 593 could provide by direct measurement or from some internal computation 594 starting from indirect measurement. In such cases, it could be 595 useful to understand the variance associated with the value of the 596 optical parmater hence, the encoding shall provide the possibility to 597 include a variance as well. 599 This kind of information will enable IA-RWA process to make some 600 additional considerations on wavelength feasibility. [RFC6566] 601 Section 4.1.3 reports some considerations regarding this degree of 602 confidence during the impairment validation process. 604 7. Control Plane Architectures 606 This section briefly describes how the defintions contained in this 607 information model will match the architectural options described by 608 [RFC6566]. 610 The first assumption is that the WSON GMPLS extentions are available 611 and operational. To such extent, the WSON-RWA will provide the 612 following information through its path computation (and RWA process): 614 o The wavelengths connectivity, considering also the connectivity 615 constraints limited by reconfigurable optics, and wavelengths 616 availability. 618 o The interface compatibility at the physical level. 620 o The Optical-Elettro-Optical (OEO) availability within the network 621 (and related physical interface compatibility). As already stated 622 by the framework this information it's very important for 623 impairment validation: 625 A. If the IV functions fail (path optically infeasible), the path 626 computation function may use an available OEO point to find a 627 feasible path. In normally operated networks OEO are mainly 628 uses to support optically unfeasible path than mere wavelength 629 conversion. 631 B. The OEO points reset the optical impairment information since 632 a new light is generated. 634 7.1. IV-Centralized 636 Centralized IV process is performed by a single entity (e.g., a PCE). 637 Given sufficient impairment information, it can either be used to 638 provide a list of paths between two nodes, which are valid in terms 639 of optical impairments. Alternatively, it can help validate whether 640 a particular selected path and wavelength is feasiable or not. This 641 requires distribution of impairment information to the entity 642 performing the IV process. 644 This Informaton Model doesn't make any hypotesys on distribution 645 method for optical parameters but only defines the essential build 646 blocks. A centralized entity may get knowledge of required 647 informaton through routing protocools or other mechanism such as BGP- 648 LS. 650 7.2. IV-Distributed 652 Assuming the information model is implemented through a routing 653 protocol, every node in the WSON network shall be able to perform an 654 RWA-IV function. 656 The signalling phase may provide additional checking as others 657 traffic engineering parameters. 659 8. Acknowledgements 661 Authors would like to acknoledge Greg Bernstein and Moustafa Kattan 662 as authors of a previous similar draft whose content partially 663 converged here. 665 Authors would like to thank ITU SG15/Q6 and in particular Peter 666 Stassar and Pete Anslow for providing useful information and text to 667 CCAMP through join meetings and liaisons. 669 9. IANA Considerations 671 This document does not contain any IANA requirement. 673 10. Security Considerations 675 This document defines an information model for impairments in optical 676 networks. If such a model is put into use within a network it will 677 by its nature contain details of the physical characteristics of an 678 optical network. Such information would need to be protected from 679 intentional or unintentional disclosure. 681 11. References 683 11.1. Normative References 685 [ITU.G650.1] 686 International Telecommunications Union, "Transmission 687 media and optical systems characteristics - Optical fibre 688 cable", ITU-T Recommendation G.650.1, July 2010. 690 [ITU.G650.2] 691 International Telecommunications Union, "Definitions and 692 test methods for statistical and non-linear related 693 attributes of single-mode fibre and cable", 694 ITU-T Recommendation G.650.2, August 2015. 696 [ITU.G671] 697 International Telecommunications Union, "Transmission 698 characteristics of optical components and subsystems", 699 ITU-T Recommendation G.671, February 2012. 701 [ITU.G680] 702 International Telecommunications Union, "Physical transfer 703 functions of optical network elements", 704 ITU-T Recommendation G.680, July 2007. 706 [ITU.G697] 707 International Telecommunications Union, "Optical 708 monitoring for dense wavelength division multiplexing 709 systems", ITU-T Recommendation G.697, February 2012. 711 [ITU.GSUP39] 712 International Telecommunications Union, "Optical System 713 Design and Engineering Considerations", 714 ITU-T Recommendation G. Supplement 39, September 2012. 716 [ITU.GSUP47] 717 International Telecommunications Union, "General aspects 718 of optical fibres and cables", ITU-T Recommendation G. 719 Supplement 47, September 2012. 721 11.2. Informative References 723 [I-D.martinelli-ccamp-wson-iv-encode] 724 Martinelli, G., Zhang, X., Galimberti, G., Siracusa, D., 725 Zanardi, A., Pederzolli, F., Lee, Y., and F. Zhang, 726 "Information Encoding for WSON with Impairments 727 Validation", draft-martinelli-ccamp-wson-iv-encode-07 728 (work in progress), October 2016. 730 [LS78] International Telecommunications Union SG15/Q6, "LS/s on 731 CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON", 732 LS https://datatracker.ietf.org/liaison/1288/, October 733 2013. 735 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 736 "Framework for GMPLS and Path Computation Element (PCE) 737 Control of Wavelength Switched Optical Networks (WSONs)", 738 RFC 6163, DOI 10.17487/RFC6163, April 2011, 739 . 741 [RFC6566] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and G. 742 Martinelli, "A Framework for the Control of Wavelength 743 Switched Optical Networks (WSONs) with Impairments", 744 RFC 6566, DOI 10.17487/RFC6566, March 2012, 745 . 747 [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, 748 "Routing and Wavelength Assignment Information Model for 749 Wavelength Switched Optical Networks", RFC 7446, 750 DOI 10.17487/RFC7446, February 2015, 751 . 753 [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and 754 J. Han, "General Network Element Constraint Encoding for 755 GMPLS-Controlled Networks", RFC 7579, 756 DOI 10.17487/RFC7579, June 2015, 757 . 759 Appendix A. FAQ 761 A.1. Why the Application Code does not suffice for Optical Impairment 762 Validation? 764 Application Codes are encoded within GMPLS WSON protocol through the 765 Optical Interface Class as defined in [RFC7446]. 767 The purpose of the Application Code in RWA is simply to assess the 768 interface compatibility: same Application Code means that two 769 interfaces can have an LSP connecting the two. 771 Application Codes contain other information useful for IV process 772 (e.g., see the list of parameters) so they are required however 773 Computational Models requires more parameteres to assess the path 774 feasibility. 776 A.2. Are DWDM network multivendor? 778 According to [ITU.G680] "Situation 1" the DWDM line segments are 779 single are single vendor but an LSP can make use of different data 780 planes entities from different vendors. For example: DWDM interfaces 781 (represented in the control plane through the Optical Interface 782 Class) from a vendor and network elements described by Stutation 1 783 from another vendor. 785 Authors' Addresses 787 Giovanni Martinelli (editor) 788 Cisco 789 via Santa Maria Molgora, 48/C 790 Vimercate 20871 791 Italy 793 Phone: +39 039 2092044 794 Email: giomarti@cisco.com 796 Xian Zhang (editor) 797 Huawei Technologies 798 F3-5-B R&D Center, Huawei Base 799 Bantian, Longgang District 800 Shenzen 518129 801 P.R. China 803 Phone: +86 755 28972465 804 Email: zhang.xian@huawei.com 806 Gabriele M. Galimberti 807 Cisco 808 Via Santa Maria Molgora, 48/C 809 Vimercate 20871 810 Italy 812 Phone: +39 039 2091462 813 Email: ggalimbe@cisco.com 814 Andrea Zanardi 815 CREATE-NET 816 via alla Cascata 56/D, Povo 817 Trento 38123 818 Italy 820 Email: andrea.zanardi@create-net.org 822 Domenico Siracusa 823 CREATE-NET 824 via alla Cascata 56/D, Povo 825 Trento 38123 826 Italy 828 Email: domenico.siracusa@create-net.org 830 Federico Pederzolli 831 CREATE-NET 832 via alla Cascata 56/D, Povo 833 Trento 38123 834 Italy 836 Email: federico.perderzolli@create-net.org 838 Young Lee 839 Huawei Technologies 840 1700 Alma Drive, Suite 100 841 Plano, TX 75075 842 U.S.A 844 Email: ylee@huawei.com 846 Fatai Zhang 847 Huawei Technologies 848 F3-5-B R&D Center, Huawei Base 849 Bantian, Longgang District 850 Shenzen 518129 851 P.R. China 853 Email: zhang.fatai@huawei.com