idnits 2.17.1 draft-martinelli-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 (July 3, 2014) is 3575 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.sup47' is mentioned on line 214, but not defined == Missing Reference: 'ITU.GSUP39' is mentioned on line 352, but not defined == Missing Reference: 'ITU.G650.1' is mentioned on line 354, but not defined == Missing Reference: 'ITU.G650.2' is mentioned on line 356, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-general-constraint-encode-14 == 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-03 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: January 4, 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 July 3, 2014 17 Information Model for Wavelength Switched Optical Networks (WSONs) with 18 Impairments Validation 19 draft-martinelli-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) function. This 25 operation might be required in Wavelength Switched Optical Networks 26 (WSON) that already support RWA and the information model defined 27 here goes in addition and it is fully compatible with the already 28 defined information model for impairment-free RWA process in WSON. 30 This information model shall support all control plane architectural 31 options defined for WSON with impairment validation. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 4, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definitions, Applicability and Properties . . . . . . . . . . 3 69 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 71 2.3. Properties . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. ITU-T List of Optical Parameters . . . . . . . . . . . . . . 6 73 4. Background from WSON-RWA Information Model . . . . . . . . . 8 74 5. Optical Impairment Information Model . . . . . . . . . . . . 9 75 5.1. The Optical Impairment Vector . . . . . . . . . . . . . . 10 76 5.2. Node Information . . . . . . . . . . . . . . . . . . . . 10 77 5.2.1. Impairment Matrix . . . . . . . . . . . . . . . . . . 10 78 5.2.2. Impairment Resource Block Information . . . . . . . . 12 79 5.3. Link Information . . . . . . . . . . . . . . . . . . . . 12 80 5.4. Path Information . . . . . . . . . . . . . . . . . . . . 13 81 6. Encoding Considerations . . . . . . . . . . . . . . . . . . . 13 82 7. Control Plane Architectures . . . . . . . . . . . . . . . . . 13 83 7.1. IV-Centralized . . . . . . . . . . . . . . . . . . . . . 14 84 7.2. IV-Distributed . . . . . . . . . . . . . . . . . . . . . 14 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 11.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Appendix A. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 16 92 A.1. Why the Application Code does not suffice for Optical 93 Impairment Validation? . . . . . . . . . . . . . . . . . 16 94 A.2. Are DWDM network multivendor? . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 In the context of Wavelength Switched Optical Network (WSON), 100 [RFC6163] describes the basic framework for a GMPLS and PCE-based 101 Routing and Wavelength Assignment (RWA) control plane. The 102 associated information model [I-D.ietf-ccamp-rwa-info] defines all 103 information/parameters required by an RWA process. 105 There are cases of WSON where optical impairments plays a significant 106 role and are considered as important constraints. The framework 107 document [RFC6566] defines the problem scope and related control 108 plane architectural options for the Impairment Aware RWA (IA-RWA) 109 operation. Options include different combinations of Impairment 110 Validation (IV) and RWA functions in term of different combination of 111 control plane functions (i.e., PCE, Routing, Signaling). 113 This document provides an information model for the impairment aware 114 case to allow the impairment validation function implemented in the 115 control plane or enabled by control plane available information. 116 This model goes in addition to [I-D.ietf-ccamp-rwa-info] and shall 117 support any control plane architectural option described by the 118 framework document (see sections 4.2 and 4.3 of [RFC6566]) where a 119 set of combinations of control plane functions vs. IV function is 120 provided. 122 2. Definitions, Applicability and Properties 124 This section provides some concepts to help understand concepts used 125 along the document and to make a clear separation about what coming 126 from data plane definitions (ITU-T G recommendations) and are taken 127 as input for this Information Model. The first sub-section provides 128 raw definitions while the Applicability sections reuses the defined 129 concepts to scope this document. 131 2.1. Definitions 133 o Computational Model / Optical Computational Model. 134 Defined by ITU standard documents. In this context we look for 135 models able to compute optical impairments for a given lightpath. 137 o Information Model. 138 Defined by IETF (this document) and provides the set of 139 information required by control plane to apply the Computational 140 Model. 142 o Level of Approximation. 143 This concept refers to the Computational Model as it may compute 144 optical impairment with a certain level of uncertainty. This 145 level is generally not measured but [RFC6566] Section 4.1.1 146 provides a rough classification about it. 148 o Feasible Path. 149 It is the output of the C-SPF with RWA-IV capability. It's an 150 optical path that satisfies optical impairment constraints. The 151 path, instantiated through wavelength(s), may actually work or not 152 work depending of the level of approximation. 154 o Existing Service Disruption. 155 An effect known to optical network designers is the cross- 156 interaction among spectrally adjacent wavelengths: an existing 157 wavelength may experience increased BER due to the setup of an 158 adjacent wavelength. Solving this problem is a typical optical 159 network design activity. Just as an example, a simple solution is 160 adding optical margins (e.g., additional OSNR), although complex 161 and detailed methods exist. 163 o DWDM Line Segments. 164 [ITU.G680] provides definition and picture for the "Situation 1" 165 DWDM Line segments: " Situation 1 - The optical path between two 166 consecutive 3R regenerators is composed of DWDM line segments from 167 a single vendor and OADMs and PXCs from another vendor". Document 168 [RFC6566] Figure 1 shows an LSP composed by two DWDM line segments 169 according to [ITU.G680] definition. 171 2.2. Applicability 173 This document targets at Scenario C defined in [RFC6566] section 174 4.1.1. as approximate impairment estimation. The Approximate 175 concept refer to the fact that this Information Model covers 176 information mainly provided by [ITU.G680] Computational Model. 178 Computational models having no or little approximation, referred as 179 IV-Detailed in the [RFC6566], currently does not exist in term of 180 ITU-T recommendation. They generally deal with non-linear optical 181 impairment and are usually vendor specific. 183 The Information Model defined in this document does not speculate 184 about the mathematical formulas used to fill up information model 185 parameters, hence it does not preclude changing the computational 186 model. At the same time, the authors do not believe this Information 187 Model is exhaustive and if necessary further documents will cover 188 additional models after they become available. 190 The result of RWA-IV process implementing this Information Model is a 191 path (and a wavelength in the data plane) that has better chance to 192 be feasible than if it was computed without any IV function. The 193 Existing Service Disruption, as per the definition above, would still 194 be a problem left to network designers: this model does not replace 195 by any means the optical network design phase. The Information Model 196 applies to GMPLS context with the associated relationship between 197 data plane(s) and control plane. 199 2.3. Properties 201 An information model may have several attributes or properties that 202 need to be defined for each optical parameter made available to the 203 control plane. The properties will help to determine how the control 204 plane can deal with a specific impairment parameter, depending on 205 architectural options chosen within the overall impairment framework 206 [RFC6566]. In some case, properties value will help to identify the 207 level of approximation supported by the IV process. 209 o Time Dependency 210 This identifies how an impairment parameter may vary with time. 211 There could be cases where there is no time dependency, while in 212 other cases there may be need of re-evaluation after a certain 213 time. In this category, variations in impairments due to 214 environmental factors such as those discussed in [G.sup47] are 215 considered. In some cases, an impairment parameter that has time 216 dependency may be considered as a constant for approximation. In 217 this information model, we do neglect this property. 219 o Wavelength Dependency 220 This property identifies if an impairment parameter can be 221 considered as constant over all the wavelength spectrum of 222 interest or not. Also in this case a detailed impairment 223 evaluation might lead to consider the exact value while an 224 approximation IV might take a constant value for all wavelengths. 225 In this information model, we consider both case: dependency / no 226 dependency on a specific wavelength. This property appears 227 directly in the information model definitions and related 228 encoding. 230 o Linearity 231 As impairments are representation of physical effects, there are 232 some that have a linear behaviour while other are non-linear. 233 Linear approximation is in scope of Scenario C of [RFC6566]. 234 During the impairment validation process, this property implies 235 that the optical effect (or quantity) satisfies the superposition 236 principle, thus a final result can be calculated by the sum of 237 each component. The linearity implies the additivity of optical 238 quantities considered during an impairment validation process. 239 The non-linear effects in general do not satisfy this property. 240 The information model presented in this document however, easily 241 allow introduction of non-linear optical effects with a linear 242 approximated contribution to the linear ones. 244 o Multi-Channel 245 There are cases where a channel's impairments take different 246 values depending on the aside wavelengths already in place, this 247 is mostly due to non-linear impairments. The result would be a 248 dependency among different LSPs sharing the same path. This 249 information model do not consider this kind of property. 251 The following table summarise the above considerations where in the 252 first column reports the list of properties to be considered for each 253 optical parameter, while the second column states if this property is 254 taken into account or not by this information model. 256 +-----------------------+----------------------+ 257 | Property | Info Model Awareness | 258 +-----------------------+----------------------+ 259 | Time Dependency | no | 260 | Wavelength Dependency | yes | 261 | Linearity | yes | 262 | Multi-channel | no | 263 +-----------------------+----------------------+ 265 Table 1: Optical Impairment Properties 267 3. ITU-T List of Optical Parameters 269 As stated by Section 2.2 this Information Model does not intend to be 270 exhaustive and targets an approximate computational model although 271 not precluding future evolutions towards more detailed or different 272 impairments estimation methods. 274 On the same line, ITU SG15/Q6 provides (through [LS78]) a list of 275 optical parameters with following observations: 277 (a) the problem of calculating the non-linear impairments in a 278 multi-vendor environment is not solved. The transfer functions 279 works only for the so called [ITU.G680] "Situation 1". 281 (b) The generated list of parameters is not definitive or exaustive. 283 In particular, [ITU.G680] contains many parameters that would be 284 required to estimate linear impairments. Some of the Computational 285 Models defined within [ITU.G680] requires parameters defined in 286 other documents like [ITU.G671]. The purpose of the list here below 287 makes this match between the two documents. 289 [ITU.G697] defines parameters can be monitored in an optical network. 290 This Information Model and associated encoding document will reuse 291 [ITU.G697] parameters identifiers and encoding for the purpose of 292 path computation. 294 The list of optical parameters starts from [ITU.G680] Section 9 which 295 provides the optical computational models for the following p: 297 G-1 OSNR. Section 9.1 299 G-2 Chromatic Dispersion (CD). Section 9.2 301 G-3 Polarization Mode Dispersion (PMD). Section 9.3 303 G-4 Polarization Dependent Loss (PDL). Section 9.3 305 In addition to the above, the following list of parameters has been 306 mentioned by [LS78]: 308 L-1 Channel frequency range [ITU.G671]. 309 This parameter is part of the application code and encoded 310 through Optical Interface Class as defined in 311 [I-D.ietf-ccamp-rwa-info]. 313 L-2 Modulation format and rate. 314 This parameter is part of the application code and encoded 315 through Optical Interface Class as defined in 316 [I-D.ietf-ccamp-rwa-info]. 318 L-3 Channel power. 319 Required by G-1. 321 L-4 Ripple. 322 According to [ITU.G680], this parameter can be taken into 323 account as additional OSNR penalty. 325 L-5 Channel signal-spontaneous noise figure [ITU.G680] 326 Required by OSNR calculation (see G-1) above. 328 L-6 Channel chromatic dispersion (for fibre segment or network 329 element). 330 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]. 338 Required by G-3. 340 L-9 Polarisation mode dispersion (for a fibre segment) [ITU.G650.2, 341 ITU.G680]. 342 Defined above as G-3. 344 L-10 Polarization dependent loss (for a network element) [ITU.G671, 345 ITU.G680] 346 Defined above as G-4. 348 L-11 Reflectance [ITU.G671]. 350 L-12 Isolation [ITU.G671] and [ITU.GSUP39] 352 L-13 Channel extinction [ITU.G671] and [ITU.GSUP39]. 354 L-14 Attenuation coefficient (for a fibre segment) [ITU.G650.1]. 356 L-15 Non-linear coefficient (for a fibre segment) [ITU.G650.2]. 357 Required for Non-Linear Optical Impairment Computational 358 Models. Neglected by this document. 360 The final list of parameters is G-1, G-2, G-3, G-4, L-3, L-4, L-5, 361 L-8, L-11, L-12, L-13, L-14. 363 4. Background from WSON-RWA Information Model 365 In this section we report terms already defined for the WSON-RWA 366 (impairment free) as in [I-D.ietf-ccamp-rwa-info] and 367 [I-D.ietf-ccamp-general-constraint-encode]. The purpose is to 368 provide essential information that will be reused or extended for the 369 impairment case. 371 In particular [I-D.ietf-ccamp-rwa-info] defines the connectivity 372 matrix as the following: 374 ConnectivityMatrix ::= 376 According to [I-D.ietf-ccamp-general-constraint-encode], this 377 definition is further detailed as: 379 ConnectivityMatrix ::= 380 (( ) ...) 382 This second formula highlights how the connectivity matrix is built 383 by pairs of LinkSet objects identifying the internal connectivity 384 capability due to internal optical node constraint(s). It's 385 essentially binary information and tell if a wavelength or a set of 386 wavelengths can go from an input port to an output port. 388 As an additional note, connectivity matrix belongs to node 389 information and is purely static. Dynamic information related to the 390 actual usage of the connections is available through specific 391 extension to link information. 393 Furthermore [I-D.ietf-ccamp-rwa-info] define the resource block as 394 follow: 396 ResourceBlockInfo ::= [] 397 [] [] 399 Which is an efficient way to model constrains of a WSON node. 401 5. Optical Impairment Information Model 403 The idea behind this information model is to categorize the 404 impairment parameters into three types and extend the information 405 model already defined for impairment-free WSONs. The three 406 categories are: 408 o Node Information. The concept of connectivity matrix is reused 409 and extended to introduce an impairment matrix, which represents 410 the impairments suffered on the internal path between two ports. 411 In addition, the concept of Resource Block is also reused and 412 extended to provide an efficient modelization of per-port 413 impairment. 415 o Link Information representing impairment information related to a 416 specific link or hop. 418 o Path Information representing the impairment information related 419 to the whole path. 421 All the above three categories will make use of a generic container, 422 the Impairment Vector, to transport optical impairment information. 424 This information model however will allow however to add additional 425 parameters beyond the one defined by [ITU.G680] in order to support 426 additional computational models. This mechanism could eventually 427 applicable to both linear and non-linear parameters. 429 This information model makes the assumption that the each optical 430 node in the network is able to provide the control plane protocols 431 with its own parameter values. However, no assumption is made on how 432 the optical nodes get those value information (e.g., internally 433 computed, provisioned by a network management system, etc.). To this 434 extent, the information model intentionally ignores all internal 435 detailed parameters that are used by the formulas of the Optical 436 Computational Model (i.e., "transfer function") and simply provides 437 the object containers to carry results of the formulas. 439 5.1. The Optical Impairment Vector 441 Optical Impairment Vector (OIV) is defined as a list of optical 442 parameters to be associated to a WSON node or a WSON link. It is 443 defined as: 445 ::= ([] ) ... 447 The optional LabelSet object enables wavelength dependency property 448 as per Table 1. LabelSet has its definition in 449 [I-D.ietf-ccamp-general-constraint-encode]. 451 OPTICAL_PARAM. This object represents an optical parameter. The 452 Impairment vector can contain a set of parameters as identified by 453 [ITU.G697] since those parameters match the terms of the linear 454 impairments computational models provided by [ITU.G680]. This 455 information model does not speculate about the set of parameters 456 (since defined elsewhere, e.g. ITU-T), however it does not preclude 457 extentions by adding new parameters. 459 5.2. Node Information 461 5.2.1. Impairment Matrix 463 Impairment matrix describes a list of the optical parameters that 464 applies to a network element as a whole or ingress/egress port pairs 465 of a network element. Wavelength dependency property of optical 466 paramters is also considered. 468 ImpairmentMatrix ::= 469 (( ) ...) 471 Where: 473 MatrixID. This ID is a unique identifier for the matrix. It 474 shall be unique in scope among connectivity matrices defined in 475 [I-D.ietf-ccamp-rwa-info] and impairment matrices defined here. 477 ConnType. This number identifies the type of matrix and it shall 478 be unique in scope with other values defined by impairment-free 479 WSON documents. 481 LinkSet. Same object definition and usage as 482 [I-D.ietf-ccamp-general-constraint-encode]. The pairs of LinkSet 483 identify one or more internal node constrain. 485 OIV. The Optical Impairment Vector defined above. 487 The model can be represented as a multidimensional matrix shown in 488 the following picture 490 _________________________________________ 491 / / / / / /| 492 / / / / / / | 493 /________/_______/_______/_______/_______/ | 494 / / / / / /| /| 495 / / / / / / | | 496 /________/_______/_______/_______/_______/ | /| 497 / / / / / /| /| | 498 / / / / / / | | /| 499 /________/_______/_______/_______/_______/ | /| | 500 / / / / / /| /| | /| 501 / / / / / / | | /| | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| | / PDL 503 | - | | | | | /| | /|/ 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| / 505 | | - | | | | /| | / PND 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /|/ 507 | | | - | | | /| / 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Chr.Disp. 509 | | | | - | | /|/ 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 511 | | | | | - | / OSNR 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 515 The connectivity matrix from 516 [I-D.ietf-ccamp-general-constraint-encode] is only a two dimensional 517 matrix, containing only binary information, through the LinkSet 518 pairs. In this model, a third dimension is added by generalizing the 519 binary information through the Optical Impairment Vector associated 520 with each LinkSet pair. Optical parameters in the picture are 521 reported just as examples while details go into specific encoding 522 draft [I-D.martinelli-ccamp-wson-iv-encode]. 524 This representation shows the most general case however, the total 525 amount of information transported by control plane protocols can be 526 greatly reduced by proper encoding when the same set of values apply 527 to all LinkSet pairs. 529 [EDITOR NODE: first run of the information model does looks for 530 generality not for optimizing the quantity of information. We'll 531 deal with optimization in a further step.] 533 5.2.2. Impairment Resource Block Information 535 This information model reuses the definition of Resource Block 536 Information adding the associated impairment vector. 538 ResourceBlockInfo ::= [] 539 [] [] [] 541 The object ResourceBlockInfo is than used as specified within 542 [I-D.ietf-ccamp-rwa-info]. 544 5.3. Link Information 546 For the list of optical parameters associated to the link, the same 547 approach used for the node-specific impairment information can be 548 applied. The link-specific impairment information is extended from 549 [I-D.ietf-ccamp-rwa-info] as the following: 551 ::= 552 [] [] 554 DynamicLinkInfo is already defined in [I-D.ietf-ccamp-rwa-info] while 555 OIV is the Optical Impairment Vector is defined in the previous 556 section. 558 5.4. Path Information 560 There are cases where the optical impariments can only be described 561 as a contrains on the overall end to end path. In such case, the 562 optical impariment and/or parameter, cannot be derived (using a 563 simple function) from the set of node / link contributions. 565 An equivalent case is the option reported by [RFC6566] on IV- 566 Candidate paths where, the control plane knows a list of optically 567 feasible paths so a new path setup can be selected among that list. 568 Independent from the protocols and functions combination (i.e. RWA 569 vs. Routing vs. PCE), the IV-Candidates imply a path property stating 570 that a path is optically feasible. 572 ::= 574 [EDITOR NOTE: section to be completed, especially to evaluate 575 protocol implications. Likely resemble to RSVP ADSPEC]. 577 6. Encoding Considerations 579 Details about encoding will be defined in a separate document 580 [I-D.martinelli-ccamp-wson-iv-encode] however worth remembering that, 581 within [ITU.G697] Appending V, ITU already provides a guideline for 582 encoding some optical parameters. 584 In particular [ITU.G697] indicates that each parameter shall be 585 represented by a 32 bit floating point number. 587 Values for optical parameters are provided by optical node and it 588 could provide by direct measurement or from some internal computation 589 starting from indirect measurement. In such cases, it could be 590 useful to understand the variance associated with the value of the 591 optical parmater hence, the encoding shall provide the possibility to 592 include a variance as well. 594 This kind of information will enable IA-RWA process to make some 595 additional considerations on wavelength feasibility. [RFC6566] 596 Section 4.1.3 reports some considerations regarding this degree of 597 confidence during the impairment validation process. 599 7. Control Plane Architectures 601 This section briefly describes how the defintions contained in this 602 information model will match the architectural options described by 603 [RFC6566]. 605 The first assumption is that the WSON GMPLS extentions are available 606 and operational. To such extent, the WSON-RWA will provide the 607 following information through its path computation (and RWA process): 609 o The wavelengths connectivity, considering also the connectivity 610 constraints limited by reconfigurable optics, and wavelengths 611 availability. 613 o The interface compatibility at the physical level. 615 o The Optical-Elettro-Optical (OEO) availability within the network 616 (and related physical interface compatibility). As already stated 617 by the framework this information it's very important for 618 impairment validation: 620 A. If the IV functions fail (path optically infeasible), the path 621 computation function may use an available OEO point to find a 622 feasible path. In normally operated networks OEO are mainly 623 uses to support optically unfeasible path than mere wavelength 624 conversion. 626 B. The OEO points reset the optical impairment information since 627 a new light is generated. 629 7.1. IV-Centralized 631 Centralized IV process is performed by a single entity (e.g., a PCE). 632 Given sufficient impairment information, it can either be used to 633 provide a list of paths between two nodes, which are valid in terms 634 of optical impairments. Alternatively, it can help validate whether 635 a particular selected path and wavelength is feasiable or not. This 636 requires distribution of impairment information to the entity 637 performing the IV process. 639 This Informaton Model doesn't make any hypotesys on distribution 640 method for optical parameters but only defines the essential build 641 blocks. A centralized entity may get knowledge of required 642 informaton through routing protocools or other mechanism such as BGP- 643 LS. 645 7.2. IV-Distributed 647 Assuming the information model is implemented through a routing 648 protocol, every node in the WSON network shall be able to perform an 649 RWA-IV function. 651 The signalling phase may provide additional checking as others 652 traffic engineering parameters. 654 8. Acknowledgements 656 Authors would like to acknoledge Greg Bernstein and Moustafa Kattan 657 as authors of a previous similar draft whose content partially 658 converged here. 660 Authors would like to thank ITU SG15/Q6 and in particular Peter 661 Stassar and Pete Anslow for providing useful information and text to 662 CCAMP through join meetings and liaisons. 664 9. IANA Considerations 666 This document does not contain any IANA requirement. 668 10. Security Considerations 670 This document defines an information model for impairments in optical 671 networks. If such a model is put into use within a network it will 672 by its nature contain details of the physical characteristics of an 673 optical network. Such information would need to be protected from 674 intentional or unintentional disclosure. 676 11. References 678 11.1. Normative References 680 [ITU.G671] 681 International Telecommunications Union, "Transmission 682 characteristics of optical components and subsystems", 683 ITU-T Recommendation G.671, February 2012. 685 [ITU.G680] 686 International Telecommunications Union, "Physical transfer 687 functions of optical network elements", ITU-T 688 Recommendation G.680, July 2007. 690 [ITU.G697] 691 International Telecommunications Union, "Optical 692 monitoring for dense wavelength division multiplexing 693 systems", ITU-T Recommendation G.697, February 2012. 695 11.2. Informative References 697 [I-D.ietf-ccamp-general-constraint-encode] 698 Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General 699 Network Element Constraint Encoding for GMPLS Controlled 700 Networks", draft-ietf-ccamp-general-constraint-encode-14 701 (work in progress), February 2014. 703 [I-D.ietf-ccamp-rwa-info] 704 Lee, Y., Bernstein, G., Li, D., and W. Imajuku, "Routing 705 and Wavelength Assignment Information Model for Wavelength 706 Switched Optical Networks", draft-ietf-ccamp-rwa-info-21 707 (work in progress), February 2014. 709 [I-D.martinelli-ccamp-wson-iv-encode] 710 Martinelli, G., Siracusa, D., Zhang, X., Galimberti, G., 711 and A. Zanardi, "Information Encoding for WSON with 712 Impairments Validation", draft-martinelli-ccamp-wson-iv- 713 encode-03 (work in progress), February 2014. 715 [LS78] International Telecommunications Union SG15/Q6, "LS/s on 716 CCAMP Liaison to ITU-T SG15 Q6 and Q12 on WSON", LS 717 https://datatracker.ietf.org/liaison/1288/, October 2013. 719 [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for 720 GMPLS and Path Computation Element (PCE) Control of 721 Wavelength Switched Optical Networks (WSONs)", RFC 6163, 722 April 2011. 724 [RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A 725 Framework for the Control of Wavelength Switched Optical 726 Networks (WSONs) with Impairments", RFC 6566, March 2012. 728 Appendix A. FAQ 730 A.1. Why the Application Code does not suffice for Optical Impairment 731 Validation? 733 Application Codes are encoded within GMPLS WSON protocol through the 734 Optical Interface Class as defined in [I-D.ietf-ccamp-rwa-info]. 736 The purpose of the Application Code in RWA is simply to assess the 737 interface compatibility: same Application Code means that two 738 interfaces can have an LSP connecting the two. 740 Application Codes contain other information useful for IV process 741 (e.g., see the list of parameters) so they are required however 742 Computational Models requires more parameteres to assess the path 743 feasibility. 745 A.2. Are DWDM network multivendor? 747 According to [ITU.G680] "Situation 1" the DWDM line segments are 748 single are single vendor but an LSP can make use of different data 749 planes entities from different vendors. For example: DWDM interfaces 750 (represented in the control plane through the Optical Interface 751 Class) from a vendor and network elements described by Stutation 1 752 from another vendor. 754 Authors' Addresses 756 Giovanni Martinelli (editor) 757 Cisco 758 via Philips 12 759 Monza 20900 760 Italy 762 Phone: +39 039 2092044 763 Email: giomarti@cisco.com 765 Xian Zhang (editor) 766 Huawei Technologies 767 F3-5-B R&D Center, Huawei Base 768 Bantian, Longgang District 769 Shenzen 518129 770 P.R. China 772 Phone: +86 755 28972465 773 Email: zhang.xian@huawei.com 775 Gabriele M. Galimberti 776 Cisco 777 Via Philips,12 778 Monza 20900 779 Italy 781 Phone: +39 039 2091462 782 Email: ggalimbe@cisco.com 784 Andrea Zanardi 785 CREATE-NET 786 via alla Cascata 56/D, Povo 787 Trento 38123 788 Italy 790 Email: andrea.zanardi@create-net.org 791 Domenico Siracusa 792 CREATE-NET 793 via alla Cascata 56/D, Povo 794 Trento 38123 795 Italy 797 Email: domenico.siracusa@create-net.org 799 Federico Pederzolli 800 CREATE-NET 801 via alla Cascata 56/D, Povo 802 Trento 38123 803 Italy 805 Email: federico.perdezolli@create-net.org 807 Young Lee 808 Huawei Technologies 809 1700 Alma Drive, Suite 100 810 Plano, TX 75075 811 U.S.A 813 Email: ylee@huawei.com 815 Fatai Zhang 816 Huawei Technologies 817 F3-5-B R&D Center, Huawei Base 818 Bantian, Longgang District 819 Shenzen 518129 820 P.R. China 822 Email: zhang.fatai@huawei.com