idnits 2.17.1 draft-ietf-ccamp-wson-iv-info-01.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 9, 2015) is 3334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.sup47' is mentioned on line 219, but not defined == Missing Reference: 'ITU.G650.2' is mentioned on line 353, but not defined == Missing Reference: 'ITU.GSUP39' is mentioned on line 349, but not defined == Missing Reference: 'ITU.G650.1' is mentioned on line 351, but not defined == Outdated reference: A later version (-09) exists of draft-martinelli-ccamp-wson-iv-encode-04 Summary: 0 errors (**), 0 flaws (~~), 6 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 10, 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 March 9, 2015 17 Information Model for Wavelength Switched Optical Networks (WSONs) with 18 Impairments Validation 19 draft-ietf-ccamp-wson-iv-info-01 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 10, 2015. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 15 80 7.2. IV-Distributed . . . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 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 [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 [G.sup47] 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, ITU.G680]. Defined above as G-4. 345 L-11 "Reflectance", [ITU.G671]. 347 L-12 "Isolation", [ITU.G671] and [ITU.GSUP39]. 349 L-13 "Channel extinction", [ITU.G671] and [ITU.GSUP39]. 351 L-14 "Attenuation coefficient (for a fibre segment)", [ITU.G650.1]. 353 L-15 "Non-linear coefficient (for a fibre segment)", [ITU.G650.2]. 354 Required for Non-Linear Optical Impairment Computational 355 Models. Neglected by this document. 357 The final list of parameters is G-1, G-2, G-3, G-4, L-3, L-4, L-5, 358 L-8, L-11, L-12, L-13, L-14. 360 4. Background from WSON-RWA Information Model 362 In this section we report terms already defined for the WSON-RWA 363 (impairment free) as in [RFC7446] and 364 [I-D.ietf-ccamp-general-constraint-encode]. The purpose is to 365 provide essential information that will be reused or extended for the 366 impairment case. 368 In particular [RFC7446] Section 4.1 defines the ConnectivityMatrix 369 explaing that it does not represent any particular internal blocking 370 behavior but indicates which input ports and wavelengths could 371 possibly be connected to a particular output port. 373 ::= 374 According to [I-D.ietf-ccamp-general-constraint-encode], this 375 definition is further detailed as: 377 ::= 378 (( ) ...) 380 This second formula highlights how the ConnectivityMatrix is built by 381 pairs of LinkSet objects identifying the internal connectivity 382 capability due to internal optical node constraint(s). It's 383 essentially binary information and tell if a wavelength or a set of 384 wavelengths can go from an input port to an output port. 386 As an additional note, ConnectivityMatrix belongs to node 387 information, is uniquely identified by adverstising node and is a 388 static information. Dynamic information related to the actual state 389 of connections is available through specific extension to link 390 information. 392 The [RFC7446] introduces the concept of ResourceBlockInfo and 393 ResourcePool for the WSON nodes. The resource block is a collection 394 of resources behaving in the same way and having similar 395 characteristics. The ResourceBlockInfo is defined as follow: 397 ::= [] 398 [] [] 400 The usage of resorurce block and resource pool is an efficient way to 401 model constrains within a WSON node. 403 5. Optical Impairment Information Model 405 The idea behind this information model is to categorize the 406 impairment parameters into three types and extend the information 407 model already defined for impairment-free WSONs. The three 408 categories are: 410 o Node Information. The concept of connectivity matrix is reused 411 and extended to introduce an impairment matrix, which represents 412 the impairments suffered on the internal path between two ports. 413 In addition, the concept of Resource Block is also reused and 414 extended to provide an efficient modelization of per-port 415 impairment. 417 o Link Information representing impairment information related to a 418 specific link or hop. 420 o Path Information representing the impairment information related 421 to the whole path. 423 All the above three categories will make use of a generic container, 424 the Impairment Vector, to transport optical impairment information. 426 This information model however will allow however to add additional 427 parameters beyond the one defined by [ITU.G680] in order to support 428 additional computational models. This mechanism could eventually 429 applicable to both linear and non-linear parameters. 431 This information model makes the assumption that the each optical 432 node in the network is able to provide the control plane protocols 433 with its own parameter values. However, no assumption is made on how 434 the optical nodes get those value information (e.g., internally 435 computed, provisioned by a network management system, etc.). To this 436 extent, the information model intentionally ignores all internal 437 detailed parameters that are used by the formulas of the Optical 438 Computational Model (i.e., "transfer function") and simply provides 439 the object containers to carry results of the formulas. 441 5.1. The Optical Impairment Vector 443 Optical Impairment Vector (OIV) is defined as a list of optical 444 parameters to be associated to a WSON node or a WSON link. It is 445 defined as: 447 ::= ([] ) ... 449 The optional LabelSet object enables wavelength dependency property 450 as per Table 1. LabelSet has its definition in 451 [I-D.ietf-ccamp-general-constraint-encode]. 453 OPTICAL_PARAM. This object represents an optical parameter. The 454 Impairment vector can contain a set of parameters as identified by 455 [ITU.G697] since those parameters match the terms of the linear 456 impairments computational models provided by [ITU.G680]. This 457 information model does not speculate about the set of parameters 458 (since defined elsewhere, e.g. ITU-T), however it does not preclude 459 extentions by adding new parameters. 461 5.2. Node Information 463 5.2.1. Impairment Matrix 465 Impairment matrix describes a list of the optical parameters that 466 applies to a network element as a whole or ingress/egress port pairs 467 of a network element. Wavelength dependency property of optical 468 paramters is also considered. 470 ImpairmentMatrix ::= 471 (( ) ...) 473 Where: 475 MatrixID. This ID is a unique identifier for the matrix. It 476 shall be unique in scope among connectivity matrices defined in 477 [RFC7446] and impairment matrices defined here. 479 ConnType. This number identifies the type of matrix and it shall 480 be unique in scope with other values defined by impairment-free 481 WSON documents. 483 LinkSet. Same object definition and usage as 484 [I-D.ietf-ccamp-general-constraint-encode]. The pairs of LinkSet 485 identify one or more internal node constrain. 487 OIV. The Optical Impairment Vector defined above. 489 The model can be represented as a multidimensional matrix shown in 490 the following picture 491 _________________________________________ 492 / / / / / /| 493 / / / / / / | 494 /________/_______/_______/_______/_______/ | 495 / / / / / /| /| 496 / / / / / / | | 497 /________/_______/_______/_______/_______/ | /| 498 / / / / / /| /| | 499 / / / / / / | | /| 500 /________/_______/_______/_______/_______/ | /| | 501 / / / / / /| /| | /| 502 / / / / / / | | /| | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL 504 | - | | | | | /| | /|/ 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| / 506 | | - | | | | /| | / PND 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/ 508 | | | - | | | /| / 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp. 510 | | | | - | | /|/ 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 512 | | | | | - | / OSNR 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 516 The connectivity matrix from 517 [I-D.ietf-ccamp-general-constraint-encode] is only a two dimensional 518 matrix, containing only binary information, through the LinkSet 519 pairs. In this model, a third dimension is added by generalizing the 520 binary information through the Optical Impairment Vector associated 521 with each LinkSet pair. Optical parameters in the picture are 522 reported just as examples while details go into specific encoding 523 draft [I-D.martinelli-ccamp-wson-iv-encode]. 525 This representation shows the most general case however, the total 526 amount of information transported by control plane protocols can be 527 greatly reduced by proper encoding when the same set of values apply 528 to all LinkSet pairs. 530 5.2.2. Impairment Resource Block Information 532 This information model reuses the definition of Resource Block 533 Information adding the associated impairment vector. 535 ResourceBlockInfo ::= [] 536 [] [] [] 538 The object ResourceBlockInfo is than used as specified within 539 [RFC7446]. 541 5.3. Link Information 543 For the list of optical parameters associated to the link, the same 544 approach used for the node-specific impairment information can be 545 applied. The link-specific impairment information is extended from 546 [RFC7446] as the following: 548 ::= 549 [] [] 551 DynamicLinkInfo is already defined in [RFC7446] while OIV is the 552 Optical Impairment Vector is defined in the previous section. 554 5.4. Path Information 556 There are cases where the optical impariments can only be described 557 as a contrains on the overall end to end path. In such case, the 558 optical impariment and/or parameter, cannot be derived (using a 559 simple function) from the set of node / link contributions. 561 An equivalent case is the option reported by [RFC6566] on IV- 562 Candidate paths where, the control plane knows a list of optically 563 feasible paths so a new path setup can be selected among that list. 564 Independent from the protocols and functions combination (i.e. RWA 565 vs. Routing vs. PCE), the IV-Candidates imply a path property stating 566 that a path is optically feasible. 568 ::= 570 [EDITOR NOTE: section to be completed, especially to evaluate 571 protocol implications. Likely resemble to RSVP ADSPEC]. 573 6. Encoding Considerations 575 Details about encoding will be defined in a separate document 576 [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, 577 within [ITU.G697] Appending V, ITU already provides a guideline for 578 encoding some optical parameters. 580 In particular [ITU.G697] indicates that each parameter shall be 581 represented by a 32 bit floating point number. 583 Values for optical parameters are provided by optical node and it 584 could provide by direct measurement or from some internal computation 585 starting from indirect measurement. In such cases, it could be 586 useful to understand the variance associated with the value of the 587 optical parmater hence, the encoding shall provide the possibility to 588 include a variance as well. 590 This kind of information will enable IA-RWA process to make some 591 additional considerations on wavelength feasibility. [RFC6566] 592 Section 4.1.3 reports some considerations regarding this degree of 593 confidence during the impairment validation process. 595 7. Control Plane Architectures 597 This section briefly describes how the defintions contained in this 598 information model will match the architectural options described by 599 [RFC6566]. 601 The first assumption is that the WSON GMPLS extentions are available 602 and operational. To such extent, the WSON-RWA will provide the 603 following information through its path computation (and RWA process): 605 o The wavelengths connectivity, considering also the connectivity 606 constraints limited by reconfigurable optics, and wavelengths 607 availability. 609 o The interface compatibility at the physical level. 611 o The Optical-Elettro-Optical (OEO) availability within the network 612 (and related physical interface compatibility). As already stated 613 by the framework this information it's very important for 614 impairment validation: 616 A. If the IV functions fail (path optically infeasible), the path 617 computation function may use an available OEO point to find a 618 feasible path. In normally operated networks OEO are mainly 619 uses to support optically unfeasible path than mere wavelength 620 conversion. 622 B. The OEO points reset the optical impairment information since 623 a new light is generated. 625 7.1. IV-Centralized 627 Centralized IV process is performed by a single entity (e.g., a PCE). 628 Given sufficient impairment information, it can either be used to 629 provide a list of paths between two nodes, which are valid in terms 630 of optical impairments. Alternatively, it can help validate whether 631 a particular selected path and wavelength is feasiable or not. This 632 requires distribution of impairment information to the entity 633 performing the IV process. 635 This Informaton Model doesn't make any hypotesys on distribution 636 method for optical parameters but only defines the essential build 637 blocks. A centralized entity may get knowledge of required 638 informaton through routing protocools or other mechanism such as BGP- 639 LS. 641 7.2. IV-Distributed 643 Assuming the information model is implemented through a routing 644 protocol, every node in the WSON network shall be able to perform an 645 RWA-IV function. 647 The signalling phase may provide additional checking as others 648 traffic engineering parameters. 650 8. Acknowledgements 652 Authors would like to acknoledge Greg Bernstein and Moustafa Kattan 653 as authors of a previous similar draft whose content partially 654 converged here. 656 Authors would like to thank ITU SG15/Q6 and in particular Peter 657 Stassar and Pete Anslow for providing useful information and text to 658 CCAMP through join meetings and liaisons. 660 9. IANA Considerations 662 This document does not contain any IANA requirement. 664 10. Security Considerations 666 This document defines an information model for impairments in optical 667 networks. If such a model is put into use within a network it will 668 by its nature contain details of the physical characteristics of an 669 optical network. Such information would need to be protected from 670 intentional or unintentional disclosure. 672 11. References 674 11.1. Normative References 676 [ITU.G671] 677 International Telecommunications Union, "Transmission 678 characteristics of optical components and subsystems", 679 ITU-T Recommendation G.671, February 2012. 681 [ITU.G680] 682 International Telecommunications Union, "Physical transfer 683 functions of optical network elements", ITU-T 684 Recommendation G.680, July 2007. 686 [ITU.G697] 687 International Telecommunications Union, "Optical 688 monitoring for dense wavelength division multiplexing 689 systems", ITU-T Recommendation G.697, February 2012. 691 11.2. Informative References 693 [I-D.ietf-ccamp-general-constraint-encode] 694 Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General 695 Network Element Constraint Encoding for GMPLS Controlled 696 Networks", draft-ietf-ccamp-general-constraint-encode-20 697 (work in progress), February 2015. 699 [I-D.martinelli-ccamp-wson-iv-encode] 700 Martinelli, G., Zhang, X., Galimberti, G., Siracusa, D., 701 Zanardi, A., Pederzolli, F., Lee, Y., and F. Zhang, 702 "Information Encoding for WSON with Impairments 703 Validation", draft-martinelli-ccamp-wson-iv-encode-04 704 (work in progress), July 2014. 706 [LS78] International Telecommunications Union SG15/Q6, "LS/s on 707 CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON", LS 708 https://datatracker.ietf.org/liaison/1288/, October 2013. 710 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 711 GMPLS and Path Computation Element (PCE) Control of 712 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 713 April 2011. 715 [RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A 716 Framework for the Control of Wavelength Switched Optical 717 Networks (WSONs) with Impairments", RFC 6566, March 2012. 719 [RFC7446] Lee, Y., Bernstein, G., Li, D., and W. Imajuku, "Routing 720 and Wavelength Assignment Information Model for Wavelength 721 Switched Optical Networks", RFC 7446, February 2015. 723 Appendix A. FAQ 725 A.1. Why the Application Code does not suffice for Optical Impairment 726 Validation? 728 Application Codes are encoded within GMPLS WSON protocol through the 729 Optical Interface Class as defined in [RFC7446]. 731 The purpose of the Application Code in RWA is simply to assess the 732 interface compatibility: same Application Code means that two 733 interfaces can have an LSP connecting the two. 735 Application Codes contain other information useful for IV process 736 (e.g., see the list of parameters) so they are required however 737 Computational Models requires more parameteres to assess the path 738 feasibility. 740 A.2. Are DWDM network multivendor? 742 According to [ITU.G680] "Situation 1" the DWDM line segments are 743 single are single vendor but an LSP can make use of different data 744 planes entities from different vendors. For example: DWDM interfaces 745 (represented in the control plane through the Optical Interface 746 Class) from a vendor and network elements described by Stutation 1 747 from another vendor. 749 Authors' Addresses 751 Giovanni Martinelli (editor) 752 Cisco 753 via Santa Maria Molgora, 48/C 754 Vimercate 20871 755 Italy 757 Phone: +39 039 2092044 758 Email: giomarti@cisco.com 759 Xian Zhang (editor) 760 Huawei Technologies 761 F3-5-B R&D Center, Huawei Base 762 Bantian, Longgang District 763 Shenzen 518129 764 P.R. China 766 Phone: +86 755 28972465 767 Email: zhang.xian@huawei.com 769 Gabriele M. Galimberti 770 Cisco 771 Via Santa Maria Molgora, 48/C 772 Vimercate 20871 773 Italy 775 Phone: +39 039 2091462 776 Email: ggalimbe@cisco.com 778 Andrea Zanardi 779 CREATE-NET 780 via alla Cascata 56/D, Povo 781 Trento 38123 782 Italy 784 Email: andrea.zanardi@create-net.org 786 Domenico Siracusa 787 CREATE-NET 788 via alla Cascata 56/D, Povo 789 Trento 38123 790 Italy 792 Email: domenico.siracusa@create-net.org 794 Federico Pederzolli 795 CREATE-NET 796 via alla Cascata 56/D, Povo 797 Trento 38123 798 Italy 800 Email: federico.perdezolli@create-net.org 801 Young Lee 802 Huawei Technologies 803 1700 Alma Drive, Suite 100 804 Plano, TX 75075 805 U.S.A 807 Email: ylee@huawei.com 809 Fatai Zhang 810 Huawei Technologies 811 F3-5-B R&D Center, Huawei Base 812 Bantian, Longgang District 813 Shenzen 518129 814 P.R. China 816 Email: zhang.fatai@huawei.com