idnits 2.17.1 draft-bernstein-wson-impairment-encode-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 21, 2013) is 4075 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Otani' is mentioned on line 283, but not defined == Unused Reference: 'G.661' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'G.671' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC6566' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RWA-Info' is defined on line 597, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein (Ed.) 2 Internet Draft Grotto Networking 3 Intended status: Informational Y. Lee (Ed.) 4 Huawei 5 Xian Zhang 6 Huawei 7 February 21, 2013 8 Expires: August 2013 10 Information Encoding for Impaired Optical Path Validation 11 draft-bernstein-wson-impairment-encode-02.txt 13 Abstract 15 This document provides an information encoding for the optical 16 impairment characteristics of optical network elements for use in 17 path computation and optical path impairment validation. This 18 encoding is based on ITU-T defined optical network element 19 characteristics as given in ITU-T recommendation G.680 and related 20 specifications. This encoding is intentionally compatible with a 21 previous impairment free optical information encoding used in 22 optical path computations and wavelength assignment. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on August 21, 2013. 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 Abstract 70 This document provides an information encoding for the optical 71 impairment characteristics of optical network elements for use in 72 path computation and optical path impairment validation. This 73 encoding is based on ITU-T defined optical network element 74 characteristics as given in ITU-T recommendation G.680 and related 75 specifications. This encoding is intentionally compatible with a 76 previous impairment free optical information encoding used in 77 optical path computations and wavelength assignment. 79 Table of Contents 81 1. Introduction...................................................3 82 2. General Aspects Optical Impairment Information Encoding........4 83 2.1. Parameter Units and Grouping..............................4 84 2.2. Frequency Dependence of Parameters........................4 85 3. Network Element Wide Parameters................................7 86 3.1. Channel frequency range (GHz, Max, Min)...................7 87 3.2. Channel insertion loss deviation (dB, Max)................7 88 3.3. Ripple (dB, Max)..........................................7 89 3.4. Channel chromatic dispersion (ps/nm, Max, Min)............8 90 3.5. Differential group delay (ps, Max)........................8 91 3.6. Polarization dependent loss (dB, Max).....................8 92 3.7. Reflectance (passive component) (dB, Max).................8 93 3.8. Reconfigure time/Switching time (ms, Max, Min)............8 94 3.9. Channel uniformity (dB, Max)..............................8 95 3.10. Channel addition/removal (steady-state) gain response (dB, 96 Max, Min)......................................................9 97 3.11. Transient duration (ms, Max).............................9 98 3.12. Transient gain increase (dB, Max)........................9 99 3.13. Transient gain reduction (dB, Max).......................9 100 3.14. Multichannel gain-change difference (inter-channel gain- 101 change difference) (dB, Max)...................................9 102 3.15. Multichannel gain tilt (inter-channel gain-change 103 ratio)(dB, Max)................................................9 104 4. Per Port Parameters............................................9 105 4.1. Total input power range (dBm, Max, Min)..................10 106 4.2. Channel input power range (dBm, Max, Min)................10 107 4.3. Channel output power range (dBm, Max, Min)...............11 108 4.4. Input reflectance (dB, Max) (with amplifiers)............11 109 4.5. Output reflectance (dB, Max) (with amplifiers)...........11 110 4.6. Maximum reflectance tolerable at input (dB, Min).........11 111 4.7. Maximum reflectance tolerable at output (dB, Min)........11 112 4.8. Maximum total output power (dBm, Max)....................11 113 5. Port to Port Parameters.......................................11 114 5.1. Insertion loss (dB, Max, Min)............................12 115 5.2. Isolation, adjacent channel (dB, Min)....................12 116 5.3. Isolation, non-adjacent channel (dB, Min)................12 117 5.4. Channel extinction (dB, Min).............................12 118 5.5. Channel signal-spontaneous noise figure (dB, Max)........12 119 5.6. Channel gain (dB, Max, Min)..............................13 120 6. Security Considerations.......................................13 121 7. IANA Considerations...........................................13 122 8. Conclusions...................................................13 123 9. Acknowledgments...............................................13 124 10. References...................................................14 125 10.1. Normative References....................................14 126 10.2. Informative References..................................15 127 Author's Addresses...............................................15 128 Intellectual Property Statement........Error! Bookmark not defined. 129 Disclaimer of Validity.................Error! Bookmark not defined. 131 1. Introduction 133 This document provides an encoding of information used for path 134 validation in optical networks utilizing approximate computations 135 based on the information model in [Imp-Info]. The definitions, 136 characteristics and usage of the optical parameters that form the 137 model [Imp-Info] and this encoding are based on ITU-T recommendation 138 G.680 [G.680]. This encoding of the impairment model [Imp-Info] is 139 intentionally made compatible with the impairment free encode of 140 reference [RWA-Encode]. 142 2. General Aspects Optical Impairment Information Encoding 144 The units for the various parameters include GHz, dB, dBm, ms, ps, 145 and ps/nm. These are typically expressed as floating point numbers. 146 Due to the measurement limitations inherent in these parameters 147 single precision floating point, e.g., 32 bit IEEE floating point, 148 numbers should be sufficient, but we are in the process of 149 conferring with ITU-T SG15 Q6 on this. 151 In [Imp-Info] optical impairments were characterized into three 152 groups: (a) those that apply to the network element as a whole, (b) 153 those that can vary on a per port basis for a network element, and 154 (c) those that can vary based on ingress to egress port pairs. In 155 addition some parameters may also exhibit frequency dependence. 157 For realistic optical network elements per port and port-to-port 158 parameters typically only assume a few different values. For 159 example, the channel gain of a ROADM is usually specified in terms 160 of input to drop, add to output, and input to output. This implies 161 that many port and port-to-port parameters could be efficiently 162 specified, stored and transported by making use of the Link Set Sub- 163 TLV and Connectivity Matrix Sub-TLV of reference [RWA-Encode]. In 164 the following we indicate how these structures could be used. 165 However, whether such facilities are used is dependent upon the 166 specific protocol context, e.g., OSPF, IS-IS, etc. 168 2.1. Parameter Units and Grouping 170 The encoding discussed here is assumed to occur within a type- 171 length-value (TLV) structure. In such a structure the type and 172 length fields form a "header" of sorts. From the type field we would 173 infer the following: 175 o Units of the parameter, i.e., dB, dBm, GHz, ps, etc... 177 o The grouping of the parameters. For some parameters such as 178 chromatic dispersion, maximum and minimum values are always 179 specified. 181 o Whether the parameter may exhibit frequency dependence. Encoding 182 of frequency dependent parameters is discussed in the next 183 section. 185 2.2. Frequency Dependence of Parameters 187 Some parameters may exhibit a frequency dependence that needs to be 188 accounted for over the frequency/wavelength of the system. We 189 provide here an extensible encoding of this dependence that can take 190 into account general purpose interpolation methods such as linear 191 interpolation, cubic splines, etc... as well as application specific 192 interpolation methods such as the 3-term and 5-term Sellmeier 193 formulas of Appendix A of reference [G.650.1]. The following 194 considerations are used in the encoding of frequency dependency: 196 1. Each parameter in a group of parameters will have its own 197 interpolation data. We know from the "type" of the parameter how 198 many sub-parameters are in this group. 200 2. Interpolation data may be broken into subranges of validity for a 201 formula with particular interpolation coefficients. 203 3. The type of interpolation to be used over the sub-ranges must be 204 specified 206 4. We assume that each sub-range will make use of the same type of 207 interpolation formula (TBD if this is condition is too limiting). 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Interpolation| Num Ranges | Reserved | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Start Wavelength (first range) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 : Range 1, sub-parameter 1 : 217 + Interpolation type particular data + 218 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-: 219 : Interpolation data for : 220 + other sub-parameters + 221 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-: 222 | Start Wavelength (next range) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 : Range 2, sub-parameter 1 : 225 + Interpolation type particular data + 226 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-: 227 : More ranges if needed : 228 : : 229 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 230 | End Wavelength (for last range) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Where 234 "Interpolation" is the type of interpolation to be used across the 235 range. 236 0 Piecewise Constant. In this form of interpolation a single 237 value of the parameter is used across each sub-range. 238 1 Linear Interpolation. In this form of interpolation two values 239 of the parameter are given corresponding to the value at each 240 end of the frequency sub-range. Linear interpolation is used to 241 obtain the parameter values for frequencies between the sub- 242 range limits. 244 Others Interpolation type are FFS. 246 "Num Ranges" is an integer that gives the number of sub-ranges for 247 the interpolation. 249 Each interpolation specific parameter block is preceded by a "start 250 wavelength" which is used to indicate the beginning of that range. 251 The following ranges "start wavelength" will be used as the ending 252 wavelength for that range, except for the last range which requires 253 an explicit "end wavelength". 255 In the case of "no interpolation" the sub-parameter value is assumed 256 to be valid over the entire sub-range and no additional 257 interpolation related parameters or coefficients are needed. 259 [To be completed: examples of piecewise constant interpolation with 260 a particular frequency dependent impairment parameter.] 262 3. Network Element Wide Parameters 264 IEEE 754-2008 format 32 bit floating point numbers are used for the 265 following parameter values. Units are specified with each parameter. 267 Each of the following individual parameters would need to be 268 explicitly identified via some kind of code point mechanism. 270 3.1. Channel frequency range (GHz, Max, Min) 272 The channel frequency range is expressed in GHz. 274 0 1 2 3 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Min frequency in GHz IEEE float | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Max frequency in GHz IEEE float | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 From the perspective of a control plane making use of standard grid 283 spacing and given the encoding of lambda of [Otani] it is not clear 284 whether this parameter is needed. Use is FFS/Liaison. 286 3.2. Channel insertion loss deviation (dB, Max) 288 A 32 bit IEEE floating point number. This parameter may be frequency 289 dependent. 291 3.3. Ripple (dB, Max) 293 A 32 bit IEEE floating point number. 295 3.4. Channel chromatic dispersion (ps/nm, Max, Min) 297 0 1 2 3 298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Min dispersion in ps/nm IEEE float | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Max dispersion in ps/nm IEEE float | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 These parameters generally exhibit frequency dependence. 307 3.5. Differential group delay (ps, Max) 309 A 32 bit IEEE floating point number. 311 3.6. Polarization dependent loss (dB, Max) 313 A 32 bit IEEE floating point number. 315 3.7. Reflectance (passive component) (dB, Max) 317 A 32 bit IEEE floating point number. 319 3.8. Reconfigure time/Switching time (ms, Max, Min) 321 0 1 2 3 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Min Reconfigure time in ms IEEE float | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Max Reconfigure time in ms IEEE float | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 3.9. Channel uniformity (dB, Max) 331 A 32 bit IEEE floating point number. 333 3.10. Channel addition/removal (steady-state) gain response (dB, Max, 334 Min) 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Min gain response in dB IEEE float | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Max gain response in dB IEEE float | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 3.11. Transient duration (ms, Max) 346 A 32 bit IEEE floating point number. 348 3.12. Transient gain increase (dB, Max) 350 A 32 bit IEEE floating point number. 352 3.13. Transient gain reduction (dB, Max) 354 A 32 bit IEEE floating point number. 356 3.14. Multichannel gain-change difference (inter-channel gain-change 357 difference) (dB, Max) 359 A 32 bit IEEE floating point number. 361 3.15. Multichannel gain tilt (inter-channel gain-change ratio)(dB, Max) 363 A 32 bit IEEE floating point number. 365 4. Per Port Parameters 367 Per port parameters fit well within the category of link parameters 368 that are typically disseminated by a link state protocol. However, 369 since many optical ports on a device tend to have the same 370 parameters grouping these parameters together for conveyance makes 371 sense and can aid in interpretation. For example, in a high channel 372 count ROADM with many add and drop ports the characteristics of all 373 the add ports would tend to be similar to each other, and likewise 374 for the drop ports, but these would tend to be different from each 375 other and the trunk (or through) ports. Hence we propose an optional 376 simple grouping mechanism based on grouping common per port 377 parameters along with a Link Set sub-TLV [RWA-Encode] that specifies 378 the set of links that share the same port parameters. 380 For example: 382 0 1 2 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Link Set TLV | 386 : : : 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Port Parameter TLV #1 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Port Parameter TLV #2 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 : : 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Port Parameter TLV #N | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Each of the following individual parameters would need to be 398 explicitly identified via some kind of code point mechanism. 400 4.1. Total input power range (dBm, Max, Min) 402 0 1 2 3 403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Min power in dBm IEEE float | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Max power in dBm IEEE float | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 4.2. Channel input power range (dBm, Max, Min) 412 0 1 2 3 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Min power in dBm IEEE float | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Max power in dBm IEEE float | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 4.3. Channel output power range (dBm, Max, Min) 422 0 1 2 3 423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Min power in dBm IEEE float | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Max power in dBm IEEE float | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 4.4. Input reflectance (dB, Max) (with amplifiers) 432 A 32 bit IEEE floating point number. 434 4.5. Output reflectance (dB, Max) (with amplifiers) 436 A 32 bit IEEE floating point number. 438 4.6. Maximum reflectance tolerable at input (dB, Min) 440 A 32 bit IEEE floating point number. 442 4.7. Maximum reflectance tolerable at output (dB, Min) 444 A 32 bit IEEE floating point number. 446 4.8. Maximum total output power (dBm, Max) 448 A 32 bit IEEE floating point number. 450 5. Port to Port Parameters 452 To specify port-to-port parameters we need to indicate the port pair 453 that they apply to. Since many port pairs have the same parameter 454 values and there maybe a great number of possible port pairs, it can 455 be worth while to group port pairs with the same parameter values in 456 our encoding. In addition, this is typically how these parameters 457 are specified. For example, the specification data for a simple 458 ROADM may give the insertion loss for the "through to drop ports" as 459 a single parameter, along with a separate insertion loss parameter 460 for the "add to through ports". 462 In [RWA-Encode] the Connectivity Matrix sub-TLV is essentially a 463 compact listing of ingress-egress port pairs. Hence we can use this 464 structure to communicate common port-to-port parameters for a set of 465 ingress-egress pairs. 467 For example: 469 0 1 2 3 470 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Connectivity Matrix Sub-TLV | 473 | (list of ingress-egress port pairs with common parameters) | 474 : : : 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Port-Port Parameter TLV #1 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Port-Port Parameter TLV #2 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 : : 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Port-Port Parameter TLV #N | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Each of the following individual parameters would need to be 486 explicitly identified via some kind of code point mechanism. 488 5.1. Insertion loss (dB, Max, Min) 490 TBD if this parameter changes with frequency. 492 0 1 2 3 493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Min Insertion loss in dB IEEE float | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Max Insertion loss in dB IEEE float | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 5.2. Isolation, adjacent channel (dB, Min) 502 A 32 bit IEEE floating point number. 504 5.3. Isolation, non-adjacent channel (dB, Min) 506 A 32 bit IEEE floating point number. 508 5.4. Channel extinction (dB, Min) 510 A 32 bit IEEE floating point number. This parameter may change with 511 frequency. 513 5.5. Channel signal-spontaneous noise figure (dB, Max) 515 A 32 bit IEEE floating point number. This parameter may change with 516 frequency. 518 5.6. Channel gain (dB, Max, Min) 520 This parameter may exhibit frequency dependence. 522 0 1 2 3 523 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Min Channel gain in dB IEEE float | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Max Channel gain in dB IEEE float | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 6. Security Considerations 532 This document defines an encoding for an information model 533 describing impairments in optical networks. If such a encoding is 534 put into use within a network it will by its nature contain details 535 of the physical characteristics of an optical network. Such 536 information would need to be protected from intentional or 537 unintentional disclosure. 539 7. IANA Considerations 541 This draft does not currently require any consideration from IANA. 543 8. Conclusions 545 The state of standardization of optical device characteristics has 546 matured from when initial IETF work concerning optical impairments 547 was investigated in [RFC4054]. Relatively recent ITU-T 548 recommendations provide a standardized based of optical 549 characteristic definitions and parameters that control plane 550 technologies such as GMPLS and PCE can make use of in performing 551 optical path validation. The enclosed information model shows how 552 readily such ITU-T optical work can be utilized within the control 553 plane. 555 9. Acknowledgments 557 This document was prepared using 2-Word-v2.0.template.dot. 559 10. References 561 10.1. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [G.650.1] ITU-T Recommendation G.650.1, Definitions and test methods 567 for linear, deterministic attributes of single-mode fibre 568 and cable, June 2004. 570 [G.661] ITU-T Recommendation G.661, Definition and test methods 571 for the relevant generic parameters of optical amplifier 572 devices and subsystems, March 2006. 574 [G.671] ITU-T Recommendation G.671, Transmission characteristics 575 of optical components and subsystems, January 2005. 577 [G.680] ITU-T Recommendation G.680, Physical transfer functions of 578 optical network elements, July 2007. 580 [RFC6566] G. Bernstein, Y. Lee, D. Li, G. Martinelli, "A Framework 581 for the Control and Measurement of Wavelength Switched 582 Optical Networks (WSON) with Impairments", RFC 6566, March 583 2012. 585 [Imp-Info] Y. Lee, G. Bernstein, M. Kattan, "Information Model for 586 Impaired Optical Path Validation", Work in Progress, 587 draft-bernstein-wson-impairment-info 589 [RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 590 "GeneralizedLabels for G.694 Lambda-Switching Capable 591 Label Switching 592 Routers", RFC 6205, March 2011. 594 [RFC4054] Strand, J., Ed., and A. Chiu, Ed., "Impairments and Other 595 Constraints on Optical Layer Routing", RFC 4054, May 2005. 597 [RWA-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 598 Wavelength Assignment Information Model for Wavelength 599 Switched Optical Networks", Work in Progress, draft-ietf- 600 ccamp-rwa-info 602 [RWA-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 603 Wavelength Assignment Information Encoding for Wavelength 604 Switched Optical Networks" Work in progress, draft-ietf- 605 ccamp-rwa-wson-encode 607 10.2. Informative References 609 Author's Addresses 611 Greg Bernstein 612 Grotto Networking 613 Fremont CA, USA 615 Phone: (510) 573-2237 616 Email: gregb@grotto-networking.com 618 Young Lee (ed.) 619 Huawei Technologies 620 1700 Alma Drive, Suite 100 621 Plano, TX 75075, USA 623 Phone: (972) 509-5599 (x2240) 624 Email: ylee@huawei.com 626 Xian Zhang 627 Huawei Technologies 628 F3-5-B R&D Center, Huawei Base 629 Bantian, Longgang District 630 Shenzhen 518129 P.R.China 632 Phone: +86-755-28972913 633 Email: zhang.xian@huawei.com 635 Intellectual Property Statement 637 The IETF Trust takes no position regarding the validity or scope of 638 any Intellectual Property Rights or other rights that might be 639 claimed to pertain to the implementation or use of the technology 640 described in any IETF Document or the extent to which any license 641 under such rights might or might not be available; nor does it 642 represent that it has made any independent effort to identify any 643 such rights. 645 Copies of Intellectual Property disclosures made to the IETF 646 Secretariat and any assurances of licenses to be made available, or 647 the result of an attempt made to obtain a general license or 648 permission for the use of such proprietary rights by implementers or 649 users of this specification can be obtained from the IETF on-line 650 IPR repository at http://www.ietf.org/ipr 651 The IETF invites any interested party to bring to its attention any 652 copyrights, patents or patent applications, or other proprietary 653 rights that may cover technology that may be required to implement 654 any standard or specification contained in an IETF Document. Please 655 address the information to the IETF at ietf-ipr@ietf.org. 657 Disclaimer of Validity 659 All IETF Documents and the information contained therein are 660 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 661 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 662 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 663 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 664 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 665 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 666 FOR A PARTICULAR PURPOSE. 668 Acknowledgment 670 Funding for the RFC Editor function is currently provided by the 671 Internet Society.