idnits 2.17.1 draft-martinelli-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 (August 12, 2014) is 3544 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.sup47' is mentioned on line 221, but not defined == Missing Reference: 'ITU.G650.2' is mentioned on line 355, but not defined == Missing Reference: 'ITU.GSUP39' is mentioned on line 351, but not defined == Missing Reference: 'ITU.G650.1' is mentioned on line 353, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-general-constraint-encode-15 == Outdated reference: A later version (-24) exists of draft-ietf-ccamp-rwa-info-21 == Outdated reference: A later version (-09) exists of draft-martinelli-ccamp-wson-iv-encode-04 Summary: 0 errors (**), 0 flaws (~~), 8 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: February 13, 2015 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 August 12, 2014 17 Information Model for Wavelength Switched Optical Networks (WSONs) with 18 Impairments Validation 19 draft-martinelli-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 February 13, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . 8 70 5. Optical Impairment Information Model . . . . . . . . . . . . 9 71 5.1. The Optical Impairment Vector . . . . . . . . . . . . . . 10 72 5.2. Node Information . . . . . . . . . . . . . . . . . . . . 10 73 5.2.1. Impairment Matrix . . . . . . . . . . . . . . . . . . 10 74 5.2.2. Impairment Resource Block Information . . . . . . . . 13 75 5.3. Link Information . . . . . . . . . . . . . . . . . . . . 13 76 5.4. Path Information . . . . . . . . . . . . . . . . . . . . 13 77 6. Encoding Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. Control Plane Architectures . . . . . . . . . . . . . . . . . 14 79 7.1. IV-Centralized . . . . . . . . . . . . . . . . . . . . . 15 80 7.2. IV-Distributed . . . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 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? . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 [I-D.ietf-ccamp-rwa-info] defines 99 information/parameters required by an RWA process without optical 100 impairment considerations. 102 There are cases of WSON where optical impairments play a significant 103 role and are considered as important constraints. The framework 104 document [RFC6566] defines the problem scope and related control 105 plane architectural options for the Impairment Aware RWA (IA-RWA) 106 operation. Options include different combinations of Impairment 107 Validation (IV) and RWA functions in term of different combination of 108 control plane functions (i.e., PCE, Routing, Signaling). 110 A Control Plane with RWA-IA will not be able to solve the optical 111 impairment problem in a detailed and exhaustive way, however, it may 112 take advantage of some data plane knowledge to make better decisions 113 during its path computing phase. The final outcome will be a path, 114 instantiated through a wavelength in the data plane, that has a 115 "better chance" to work than that path were calculated without IA 116 information. "Better chance" means that path setup may still fail 117 and the GMPLS control plane will follow its usual procedures upon 118 errors and failures. A control plane will not replace a the network 119 design phase that remains a foundamental step for DWDM Optical 120 Networks. As the non-linear impairments which need to be considered 121 in the calculation of an optical path will be vendor-dependent, the 122 parameters considered in this document is not an exhaustive list. 124 This document provides an information model for the impairment aware 125 case to allow the impairment validation function implemented in the 126 control plane or enabled by control plane available information. 127 This model goes in addition to [I-D.ietf-ccamp-rwa-info] and shall 128 support any control plane architectural option described by the 129 framework document (see sections 4.2 and 4.3 of [RFC6566]) where a 130 set of combinations of control plane functions vs. IV function is 131 provided. 133 2. Definitions, Applicability and Properties 135 This section provides some concepts to help understand the model and 136 to make a clear separation from data plane definitions (ITU-T 137 recommendations). The first sub-section provides definitions while 138 the Applicability sections uses the defined definitions to scope this 139 document. 141 2.1. Definitions 143 o Computational Model / Optical Computational Model. 144 Defined by ITU standard documents. In this context we look for 145 models able to compute optical impairments for a given lightpath. 147 o Information Model. 148 Defined by IETF (this document) and provides the set of 149 information required by control plane to apply the Computational 150 Model. 152 o Level of Approximation. 153 This concept refers to the Computational Model as it may compute 154 optical impairment with a certain level of uncertainty. This 155 level is generally not measured but [RFC6566] Section 4.1.1 156 provides a rough classification about it. 158 o Feasible Path. 159 It is the output of the C-SPF with RWA-IV capability. It's an 160 optical path that satisfies optical impairment constraints. The 161 path, instantiated through wavelength(s), may actually work or not 162 work depending of the level of approximation. 164 o Existing Service Disruption. 165 An effect known to optical network designers is the cross- 166 interaction among spectrally adjacent wavelengths: an existing 167 wavelength may experience increased BER due to the setup of an 168 adjacent wavelength. Solving this problem is a typical optical 169 network design activity. Just as an example, a simple solution is 170 adding optical margins (e.g., additional OSNR), although complex 171 and detailed methods exist. 173 o DWDM Line Segments. 174 [ITU.G680] provides definition and picture for the "Situation 1" 175 DWDM Line segments: " Situation 1 - The optical path between two 176 consecutive 3R regenerators is composed of DWDM line segments from 177 a single vendor and OADMs and PXCs from another vendor". Document 178 [RFC6566] Figure 1 shows an LSP composed by two DWDM line segments 179 according to [ITU.G680] definition. 181 2.2. Applicability 183 This document targets at Scenario C defined in [RFC6566] section 184 4.1.1. as approximate impairment estimation. The Approximate 185 concept refer to the fact that this Information Model covers 186 information mainly provided by [ITU.G680] Computational Model. 188 Computational models having no or little approximation, referred as 189 IV-Detailed in the [RFC6566], currently does not exist in term of 190 ITU-T recommendation. They generally deal with non-linear optical 191 impairment and are usually vendor specific. 193 The Information Model defined in this document does not speculate 194 about the mathematical formulas used to fill up information model 195 parameters, hence it does not preclude changing the computational 196 model. At the same time, the authors do not believe this Information 197 Model is exhaustive and if necessary further documents will cover 198 additional models after they become available. 200 The result of RWA-IV process implementing this Information Model is a 201 path (and a wavelength in the data plane) that has better chance to 202 be feasible than if it was computed without any IV function. The 203 Existing Service Disruption, as per the definition above, would still 204 be a problem left to a network design phase. 206 2.3. Properties 208 An information model may have several attributes or properties that 209 need to be defined for each optical parameter made available to the 210 control plane. The properties will help to determine how the control 211 plane can deal with a specific impairment parameter, depending on 212 architectural options chosen within the overall impairment framework 213 [RFC6566]. In some case, properties value will help to identify the 214 level of approximation supported by the IV process. 216 o Time Dependency 217 This identifies how an impairment parameter may vary with time. 218 There could be cases where there is no time dependency, while in 219 other cases there may be need of re-evaluation after a certain 220 time. In this category, variations in impairments due to 221 environmental factors such as those discussed in [G.sup47] are 222 considered. In some cases, an impairment parameter that has time 223 dependency may be considered as a constant for approximation. In 224 this information model, we do neglect this property. 226 o Wavelength Dependency 227 This property identifies if an impairment parameter can be 228 considered as constant over all the wavelength spectrum of 229 interest or not. Also in this case a detailed impairment 230 evaluation might lead to consider the exact value while an 231 approximation IV might take a constant value for all wavelengths. 232 In this information model, we consider both case: dependency / no 233 dependency on a specific wavelength. This property appears 234 directly in the information model definitions and related 235 encoding. 237 o Linearity 238 As impairments are representation of physical effects, there are 239 some that have a linear behaviour while other are non-linear. 240 Linear approximation is in scope of Scenario C of [RFC6566]. 241 During the impairment validation process, this property implies 242 that the optical effect (or quantity) satisfies the superposition 243 principle, thus a final result can be calculated by the sum of 244 each component. The linearity implies the additivity of optical 245 quantities considered during an impairment validation process. 246 The non-linear effects in general do not satisfy this property. 247 The information model presented in this document however, easily 248 allow introduction of non-linear optical effects with a linear 249 approximated contribution to the linear ones. 251 o Multi-Channel 252 There are cases where a channel's impairments take different 253 values depending on the aside wavelengths already in place, this 254 is mostly due to non-linear impairments. The result would be a 255 dependency among different LSPs sharing the same path. This 256 information model do not consider this kind of property. 258 The following table summarise the above considerations where in the 259 first column reports the list of properties to be considered for each 260 optical parameter, while the second column states if this property is 261 taken into account or not by this information model. 263 +-----------------------+----------------------+ 264 | Property | Info Model Awareness | 265 +-----------------------+----------------------+ 266 | Time Dependency | no | 267 | Wavelength Dependency | yes | 268 | Linearity | yes | 269 | Multi-channel | no | 270 +-----------------------+----------------------+ 272 Table 1: Optical Impairment Properties 274 3. ITU-T List of Optical Parameters 276 As stated by Section 2.2 this Information Model does not intend to be 277 exhaustive and targets an approximate computational model although 278 not precluding future evolutions towards more detailed or different 279 impairments estimation methods. 281 On the same line, ITU SG15/Q6 provides (through [LS78]) a list of 282 optical parameters with following observations: 284 (a) the problem of calculating the non-linear impairments in a 285 multi-vendor environment is not solved. The transfer functions 286 works only for the so called [ITU.G680] "Situation 1". 288 (b) The generated list of parameters is not definitive or exaustive. 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 [I-D.ietf-ccamp-rwa-info]. 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 [I-D.ietf-ccamp-rwa-info]. 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, ITU.G680]. Defined above as G-4. 347 L-11 "Reflectance", [ITU.G671]. 349 L-12 "Isolation", [ITU.G671] and [ITU.GSUP39]. 351 L-13 "Channel extinction", [ITU.G671] and [ITU.GSUP39]. 353 L-14 "Attenuation coefficient (for a fibre segment)", [ITU.G650.1]. 355 L-15 "Non-linear coefficient (for a fibre segment)", [ITU.G650.2]. 356 Required for Non-Linear Optical Impairment Computational 357 Models. Neglected by this document. 359 The final list of parameters is G-1, G-2, G-3, G-4, L-3, L-4, L-5, 360 L-8, L-11, L-12, L-13, L-14. 362 4. Background from WSON-RWA Information Model 364 In this section we report terms already defined for the WSON-RWA 365 (impairment free) as in [I-D.ietf-ccamp-rwa-info] and 366 [I-D.ietf-ccamp-general-constraint-encode]. The purpose is to 367 provide essential information that will be reused or extended for the 368 impairment case. 370 In particular [I-D.ietf-ccamp-rwa-info] defines the connectivity 371 matrix as the following: 373 ConnectivityMatrix ::= 375 According to [I-D.ietf-ccamp-general-constraint-encode], this 376 definition is further detailed as: 378 ConnectivityMatrix ::= 379 (( ) ...) 381 This second formula highlights how the connectivity matrix is built 382 by pairs of LinkSet objects identifying the internal connectivity 383 capability due to internal optical node constraint(s). It's 384 essentially binary information and tell if a wavelength or a set of 385 wavelengths can go from an input port to an output port. 387 As an additional note, connectivity matrix belongs to node 388 information and is purely static. Dynamic information related to the 389 actual usage of the connections is available through specific 390 extension to link information. 392 Furthermore [I-D.ietf-ccamp-rwa-info] define the resource block as 393 follow: 395 ResourceBlockInfo ::= [] 396 [] [] 398 Which is an efficient way to model constrains of a WSON node. 400 5. Optical Impairment Information Model 402 The idea behind this information model is to categorize the 403 impairment parameters into three types and extend the information 404 model already defined for impairment-free WSONs. The three 405 categories are: 407 o Node Information. The concept of connectivity matrix is reused 408 and extended to introduce an impairment matrix, which represents 409 the impairments suffered on the internal path between two ports. 410 In addition, the concept of Resource Block is also reused and 411 extended to provide an efficient modelization of per-port 412 impairment. 414 o Link Information representing impairment information related to a 415 specific link or hop. 417 o Path Information representing the impairment information related 418 to the whole path. 420 All the above three categories will make use of a generic container, 421 the Impairment Vector, to transport optical impairment information. 423 This information model however will allow however to add additional 424 parameters beyond the one defined by [ITU.G680] in order to support 425 additional computational models. This mechanism could eventually 426 applicable to both linear and non-linear parameters. 428 This information model makes the assumption that the each optical 429 node in the network is able to provide the control plane protocols 430 with its own parameter values. However, no assumption is made on how 431 the optical nodes get those value information (e.g., internally 432 computed, provisioned by a network management system, etc.). To this 433 extent, the information model intentionally ignores all internal 434 detailed parameters that are used by the formulas of the Optical 435 Computational Model (i.e., "transfer function") and simply provides 436 the object containers to carry results of the formulas. 438 5.1. The Optical Impairment Vector 440 Optical Impairment Vector (OIV) is defined as a list of optical 441 parameters to be associated to a WSON node or a WSON link. It is 442 defined as: 444 ::= ([] ) ... 446 The optional LabelSet object enables wavelength dependency property 447 as per Table 1. LabelSet has its definition in 448 [I-D.ietf-ccamp-general-constraint-encode]. 450 OPTICAL_PARAM. This object represents an optical parameter. The 451 Impairment vector can contain a set of parameters as identified by 452 [ITU.G697] since those parameters match the terms of the linear 453 impairments computational models provided by [ITU.G680]. This 454 information model does not speculate about the set of parameters 455 (since defined elsewhere, e.g. ITU-T), however it does not preclude 456 extentions by adding new parameters. 458 5.2. Node Information 460 5.2.1. Impairment Matrix 462 Impairment matrix describes a list of the optical parameters that 463 applies to a network element as a whole or ingress/egress port pairs 464 of a network element. Wavelength dependency property of optical 465 paramters is also considered. 467 ImpairmentMatrix ::= 468 (( ) ...) 470 Where: 472 MatrixID. This ID is a unique identifier for the matrix. It 473 shall be unique in scope among connectivity matrices defined in 474 [I-D.ietf-ccamp-rwa-info] and impairment matrices defined here. 476 ConnType. This number identifies the type of matrix and it shall 477 be unique in scope with other values defined by impairment-free 478 WSON documents. 480 LinkSet. Same object definition and usage as 481 [I-D.ietf-ccamp-general-constraint-encode]. The pairs of LinkSet 482 identify one or more internal node constrain. 484 OIV. The Optical Impairment Vector defined above. 486 The model can be represented as a multidimensional matrix shown in 487 the following picture 488 _________________________________________ 489 / / / / / /| 490 / / / / / / | 491 /________/_______/_______/_______/_______/ | 492 / / / / / /| /| 493 / / / / / / | | 494 /________/_______/_______/_______/_______/ | /| 495 / / / / / /| /| | 496 / / / / / / | | /| 497 /________/_______/_______/_______/_______/ | /| | 498 / / / / / /| /| | /| 499 / / / / / / | | /| | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL 501 | - | | | | | /| | /|/ 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| / 503 | | - | | | | /| | / PND 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/ 505 | | | - | | | /| / 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp. 507 | | | | - | | /|/ 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 509 | | | | | - | / OSNR 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 513 The connectivity matrix from 514 [I-D.ietf-ccamp-general-constraint-encode] is only a two dimensional 515 matrix, containing only binary information, through the LinkSet 516 pairs. In this model, a third dimension is added by generalizing the 517 binary information through the Optical Impairment Vector associated 518 with each LinkSet pair. Optical parameters in the picture are 519 reported just as examples while details go into specific encoding 520 draft [I-D.martinelli-ccamp-wson-iv-encode]. 522 This representation shows the most general case however, the total 523 amount of information transported by control plane protocols can be 524 greatly reduced by proper encoding when the same set of values apply 525 to all LinkSet pairs. 527 [EDITOR NODE: first run of the information model does looks for 528 generality not for optimizing the quantity of information. We'll 529 deal with optimization in a further step.] 531 5.2.2. Impairment Resource Block Information 533 This information model reuses the definition of Resource Block 534 Information adding the associated impairment vector. 536 ResourceBlockInfo ::= [] 537 [] [] [] 539 The object ResourceBlockInfo is than used as specified within 540 [I-D.ietf-ccamp-rwa-info]. 542 5.3. Link Information 544 For the list of optical parameters associated to the link, the same 545 approach used for the node-specific impairment information can be 546 applied. The link-specific impairment information is extended from 547 [I-D.ietf-ccamp-rwa-info] as the following: 549 ::= 550 [] [] 552 DynamicLinkInfo is already defined in [I-D.ietf-ccamp-rwa-info] while 553 OIV is the Optical Impairment Vector is defined in the previous 554 section. 556 5.4. Path Information 558 There are cases where the optical impariments can only be described 559 as a contrains on the overall end to end path. In such case, the 560 optical impariment and/or parameter, cannot be derived (using a 561 simple function) from the set of node / link contributions. 563 An equivalent case is the option reported by [RFC6566] on IV- 564 Candidate paths where, the control plane knows a list of optically 565 feasible paths so a new path setup can be selected among that list. 566 Independent from the protocols and functions combination (i.e. RWA 567 vs. Routing vs. PCE), the IV-Candidates imply a path property stating 568 that a path is optically feasible. 570 ::= 572 [EDITOR NOTE: section to be completed, especially to evaluate 573 protocol implications. Likely resemble to RSVP ADSPEC]. 575 6. Encoding Considerations 577 Details about encoding will be defined in a separate document 578 [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, 579 within [ITU.G697] Appending V, ITU already provides a guideline for 580 encoding some optical parameters. 582 In particular [ITU.G697] indicates that each parameter shall be 583 represented by a 32 bit floating point number. 585 Values for optical parameters are provided by optical node and it 586 could provide by direct measurement or from some internal computation 587 starting from indirect measurement. In such cases, it could be 588 useful to understand the variance associated with the value of the 589 optical parmater hence, the encoding shall provide the possibility to 590 include a variance as well. 592 This kind of information will enable IA-RWA process to make some 593 additional considerations on wavelength feasibility. [RFC6566] 594 Section 4.1.3 reports some considerations regarding this degree of 595 confidence during the impairment validation process. 597 7. Control Plane Architectures 599 This section briefly describes how the defintions contained in this 600 information model will match the architectural options described by 601 [RFC6566]. 603 The first assumption is that the WSON GMPLS extentions are available 604 and operational. To such extent, the WSON-RWA will provide the 605 following information through its path computation (and RWA process): 607 o The wavelengths connectivity, considering also the connectivity 608 constraints limited by reconfigurable optics, and wavelengths 609 availability. 611 o The interface compatibility at the physical level. 613 o The Optical-Elettro-Optical (OEO) availability within the network 614 (and related physical interface compatibility). As already stated 615 by the framework this information it's very important for 616 impairment validation: 618 A. If the IV functions fail (path optically infeasible), the path 619 computation function may use an available OEO point to find a 620 feasible path. In normally operated networks OEO are mainly 621 uses to support optically unfeasible path than mere wavelength 622 conversion. 624 B. The OEO points reset the optical impairment information since 625 a new light is generated. 627 7.1. IV-Centralized 629 Centralized IV process is performed by a single entity (e.g., a PCE). 630 Given sufficient impairment information, it can either be used to 631 provide a list of paths between two nodes, which are valid in terms 632 of optical impairments. Alternatively, it can help validate whether 633 a particular selected path and wavelength is feasiable or not. This 634 requires distribution of impairment information to the entity 635 performing the IV process. 637 This Informaton Model doesn't make any hypotesys on distribution 638 method for optical parameters but only defines the essential build 639 blocks. A centralized entity may get knowledge of required 640 informaton through routing protocools or other mechanism such as BGP- 641 LS. 643 7.2. IV-Distributed 645 Assuming the information model is implemented through a routing 646 protocol, every node in the WSON network shall be able to perform an 647 RWA-IV function. 649 The signalling phase may provide additional checking as others 650 traffic engineering parameters. 652 8. Acknowledgements 654 Authors would like to acknoledge Greg Bernstein and Moustafa Kattan 655 as authors of a previous similar draft whose content partially 656 converged here. 658 Authors would like to thank ITU SG15/Q6 and in particular Peter 659 Stassar and Pete Anslow for providing useful information and text to 660 CCAMP through join meetings and liaisons. 662 9. IANA Considerations 664 This document does not contain any IANA requirement. 666 10. Security Considerations 668 This document defines an information model for impairments in optical 669 networks. If such a model is put into use within a network it will 670 by its nature contain details of the physical characteristics of an 671 optical network. Such information would need to be protected from 672 intentional or unintentional disclosure. 674 11. References 676 11.1. Normative References 678 [ITU.G671] 679 International Telecommunications Union, "Transmission 680 characteristics of optical components and subsystems", 681 ITU-T Recommendation G.671, February 2012. 683 [ITU.G680] 684 International Telecommunications Union, "Physical transfer 685 functions of optical network elements", ITU-T 686 Recommendation G.680, July 2007. 688 [ITU.G697] 689 International Telecommunications Union, "Optical 690 monitoring for dense wavelength division multiplexing 691 systems", ITU-T Recommendation G.697, February 2012. 693 11.2. Informative References 695 [I-D.ietf-ccamp-general-constraint-encode] 696 Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General 697 Network Element Constraint Encoding for GMPLS Controlled 698 Networks", draft-ietf-ccamp-general-constraint-encode-15 699 (work in progress), August 2014. 701 [I-D.ietf-ccamp-rwa-info] 702 Lee, Y., Bernstein, G., Li, D., and W. Imajuku, "Routing 703 and Wavelength Assignment Information Model for Wavelength 704 Switched Optical Networks", draft-ietf-ccamp-rwa-info-21 705 (work in progress), February 2014. 707 [I-D.martinelli-ccamp-wson-iv-encode] 708 Martinelli, G., Zhang, X., Galimberti, G., Siracusa, D., 709 Zanardi, A., Pederzolli, F., Lee, Y., and F. Zhang, 710 "Information Encoding for WSON with Impairments 711 Validation", draft-martinelli-ccamp-wson-iv-encode-04 712 (work in progress), July 2014. 714 [LS78] International Telecommunications Union SG15/Q6, "LS/s on 715 CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON", LS 716 https://datatracker.ietf.org/liaison/1288/, October 2013. 718 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 719 GMPLS and Path Computation Element (PCE) Control of 720 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 721 April 2011. 723 [RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A 724 Framework for the Control of Wavelength Switched Optical 725 Networks (WSONs) with Impairments", RFC 6566, March 2012. 727 Appendix A. FAQ 729 A.1. Why the Application Code does not suffice for Optical Impairment 730 Validation? 732 Application Codes are encoded within GMPLS WSON protocol through the 733 Optical Interface Class as defined in [I-D.ietf-ccamp-rwa-info]. 735 The purpose of the Application Code in RWA is simply to assess the 736 interface compatibility: same Application Code means that two 737 interfaces can have an LSP connecting the two. 739 Application Codes contain other information useful for IV process 740 (e.g., see the list of parameters) so they are required however 741 Computational Models requires more parameteres to assess the path 742 feasibility. 744 A.2. Are DWDM network multivendor? 746 According to [ITU.G680] "Situation 1" the DWDM line segments are 747 single are single vendor but an LSP can make use of different data 748 planes entities from different vendors. For example: DWDM interfaces 749 (represented in the control plane through the Optical Interface 750 Class) from a vendor and network elements described by Stutation 1 751 from another vendor. 753 Authors' Addresses 754 Giovanni Martinelli (editor) 755 Cisco 756 via Santa Maria Molgora, 48/C 757 Vimercate 20871 758 Italy 760 Phone: +39 039 2092044 761 Email: giomarti@cisco.com 763 Xian Zhang (editor) 764 Huawei Technologies 765 F3-5-B R&D Center, Huawei Base 766 Bantian, Longgang District 767 Shenzen 518129 768 P.R. China 770 Phone: +86 755 28972465 771 Email: zhang.xian@huawei.com 773 Gabriele M. Galimberti 774 Cisco 775 Via Santa Maria Molgora, 48/C 776 Vimercate 20871 777 Italy 779 Phone: +39 039 2091462 780 Email: ggalimbe@cisco.com 782 Andrea Zanardi 783 CREATE-NET 784 via alla Cascata 56/D, Povo 785 Trento 38123 786 Italy 788 Email: andrea.zanardi@create-net.org 790 Domenico Siracusa 791 CREATE-NET 792 via alla Cascata 56/D, Povo 793 Trento 38123 794 Italy 796 Email: domenico.siracusa@create-net.org 797 Federico Pederzolli 798 CREATE-NET 799 via alla Cascata 56/D, Povo 800 Trento 38123 801 Italy 803 Email: federico.perdezolli@create-net.org 805 Young Lee 806 Huawei Technologies 807 1700 Alma Drive, Suite 100 808 Plano, TX 75075 809 U.S.A 811 Email: ylee@huawei.com 813 Fatai Zhang 814 Huawei Technologies 815 F3-5-B R&D Center, Huawei Base 816 Bantian, Longgang District 817 Shenzen 518129 818 P.R. China 820 Email: zhang.fatai@huawei.com