idnits 2.17.1 draft-ietf-ccamp-rwa-wson-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2010) is 5197 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.698.1' is mentioned on line 485, but not defined == Missing Reference: 'G.698.2' is mentioned on line 514, but not defined == Missing Reference: 'G.707' is mentioned on line 557, but not defined == Missing Reference: 'G.709' is mentioned on line 559, but not defined == Missing Reference: 'RFC5212' is mentioned on line 874, but not defined == Missing Reference: 'Trans07' is mentioned on line 1785, but not defined == Missing Reference: 'Yang05' is mentioned on line 1786, but not defined == Missing Reference: 'Sambo09' is mentioned on line 1788, but not defined == Missing Reference: 'Sen08' is mentioned on line 1800, but not defined == Missing Reference: 'RFC3473' is mentioned on line 1844, but not defined == Missing Reference: 'RFC5420' is mentioned on line 1863, but not defined == Unused Reference: 'RFC3630' is defined on line 2280, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 2284, but no explicit reference was found in the text == Unused Reference: 'RFC4201' is defined on line 2287, but no explicit reference was found in the text == Unused Reference: 'G.Sup43' is defined on line 2415, but no explicit reference was found in the text == Unused Reference: 'RFC4054' is defined on line 2427, but no explicit reference was found in the text == Unused Reference: 'RFC4606' is defined on line 2430, but no explicit reference was found in the text -- No information found for draft-otani-ccamp-gmpls-g-694-lambda-labels - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Lee (ed.) 2 Internet Draft Huawei 3 Intended status: Informational G. Bernstein (ed.) 4 Expires: August 2010 Grotto Networking 5 Wataru Imajuku 6 NTT 8 February 1, 2010 10 Framework for GMPLS and PCE Control of Wavelength Switched Optical 11 Networks (WSON) 12 draft-ietf-ccamp-rwa-wson-framework-05.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 1, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 This memo provides a framework for applying Generalized Multi- 55 Protocol Label Switching (GMPLS) and the Path Computation Element 56 (PCE) architecture to the control of wavelength switched optical 57 networks (WSON). In particular we provide control plane models for 58 key wavelength switched optical network subsystems and processes. The 59 subsystems include wavelength division multiplexed links, tunable 60 laser transmitters, reconfigurable optical add/drop multiplexers 61 (ROADM) and wavelength converters. In addition, electro-optical 62 network elements and their compatibility constraints relative to 63 optical signal parameters are characterized. 65 Lightpath provisioning, in general, requires the routing and 66 wavelength assignment (RWA) process. This process is reviewed and the 67 information requirements, both static and dynamic for this process 68 are presented, along with alternative implementation architectures 69 that could be realized via various combinations of extended GMPLS and 70 PCE protocols. 72 This memo focuses on topological elements and path selection 73 constraints that are common across different WSON environments as 74 such it does not address optical impairments in any depth. 76 Table of Contents 78 1. Introduction..................................................4 79 1.1. Revision History..........................................5 80 1.1.1. Changes from 00......................................5 81 1.1.2. Changes from 01......................................5 82 1.1.3. Changes from 02......................................5 83 1.1.4. Changes from 03......................................6 84 1.1.5. Changes from 04......................................6 85 1.2. Related Documents.........................................6 86 2. Terminology....................................................7 87 3. Wavelength Switched Optical Networks...........................7 88 3.1. WDM and CWDM Links........................................8 89 3.2. Optical Transmitters......................................9 90 3.3. Optical Signals in WSONs.................................10 91 3.3.1. Optical Tributary Signals...........................11 92 3.3.2. WSON Signal Characteristics.........................12 93 3.4. ROADMs, OXCs, Splitters, Combiners and FOADMs............13 94 3.4.1. Reconfigurable Add/Drop Multiplexers and OXCs.......13 95 3.4.2. Splitters...........................................16 96 3.4.3. Combiners...........................................16 97 3.4.4. Fixed Optical Add/Drop Multiplexers.................17 98 3.5. Electro-Optical Systems..................................17 99 3.5.1. Regenerators........................................17 100 3.5.2. OEO Switches........................................20 101 3.6. Wavelength Converters....................................20 102 3.6.1. Wavelength Converter Pool Modeling..................22 103 3.7. Characterizing Electro-Optical Network Elements..........26 104 3.7.1. Input Constraints...................................27 105 3.7.2. Output Constraints..................................27 106 3.7.3. Processing Capabilities.............................28 107 4. Routing and Wavelength Assignment and the Control Plane.......29 108 4.1. Architectural Approaches to RWA..........................30 109 4.1.1. Combined RWA (R&WA).................................30 110 4.1.2. Separated R and WA (R+WA)...........................30 111 4.1.3. Routing and Distributed WA (R+DWA)..................31 112 4.2. Conveying information needed by RWA......................32 113 4.3. Lightpath Temporal Characteristics.......................33 114 5. Modeling Examples and Control Plane Use Cases.................34 115 5.1. Network Modeling for GMPLS/PCE Control...................34 116 5.1.1. Describing the WSON nodes...........................34 117 5.1.2. Describing the links................................36 118 5.2. RWA Path Computation and Establishment...................37 119 5.3. Resource Optimization....................................38 120 5.4. Support for Rerouting....................................39 121 5.5. Electro-Optical Networking Scenarios.....................39 122 5.5.1. Fixed Regeneration Points...........................39 123 5.5.2. Shared Regeneration Pools...........................40 124 5.5.3. Reconfigurable Regenerators.........................40 125 5.5.4. Relation to Translucent Networks....................40 126 6. GMPLS & PCE Implications......................................41 127 6.1. Implications for GMPLS signaling.........................41 128 6.1.1. Identifying Wavelengths and Signals.................42 129 6.1.2. WSON Signals and Network Element Processing.........42 130 6.1.3. Combined RWA/Separate Routing WA support............42 131 6.1.4. Distributed Wavelength Assignment: Unidirectional, No 132 Converters.................................................43 133 6.1.5. Distributed Wavelength Assignment: Unidirectional, 134 Limited Converters.........................................44 135 6.1.6. Distributed Wavelength Assignment: Bidirectional, No 136 Converters.................................................44 137 6.2. Implications for GMPLS Routing...........................44 138 6.2.1. Electro-Optical Element Signal Compatibility........45 139 6.2.2. Wavelength-Specific Availability Information........46 140 6.2.3. WSON Routing Information Summary....................46 141 6.3. Optical Path Computation and Implications for PCE........48 142 6.3.1. Lightpath Constraints and Characteristics...........48 143 6.3.2. Electro-Optical Element Signal Compatibility........49 144 6.3.3. Discovery of RWA Capable PCEs.......................49 145 6.4. Summary of Impacts by RWA Architecture...................50 146 7. Security Considerations.......................................51 147 8. IANA Considerations...........................................51 148 9. Acknowledgments...............................................51 149 10. References...................................................52 150 10.1. Normative References....................................52 151 10.2. Informative References..................................53 152 11. Contributors.................................................56 153 Author's Addresses...............................................57 154 Intellectual Property Statement..................................57 155 Disclaimer of Validity...........................................58 157 1. Introduction 159 This memo provides a framework for applying GMPLS and the Path 160 Computation Element (PCE) architecture to the control of WSONs. In 161 particular we provide control plane models for key wavelength 162 switched optical network subsystems and processes. The subsystems 163 include wavelength division multiplexed links, tunable laser 164 transmitters, reconfigurable optical add/drop multiplexers (ROADM) 165 and wavelength converters. In addition, electro-optical network 166 elements and their compatibility constraints relative to optical 167 signal parameters are characterized. 169 Lightpath provisioning, in general, requires the routing and 170 wavelength assignment (RWA) process. This process is reviewed and the 171 information requirements, both static and dynamic for this process 172 are presented, along with alternative implementation architectures 173 that could be realized via various combinations of extended GMPLS and 174 PCE protocols. 176 This document will focus on the unique properties of links, switches 177 and path selection constraints that occur in WSONs. Different WSONs 178 such as access, metro and long haul may apply different techniques 179 for dealing with optical impairments hence this document will not 180 address optical impairments in any depth, but instead focus on 181 properties that are common across a variety of WSONs. For more on how 182 the GMPLS control plane can aid in dealing with optical impairments 183 see [WSON-Imp]. 185 1.1. Revision History 187 1.1.1. Changes from 00 189 o Added new first level section on modeling examples and control 190 plane use cases. 192 o Added new third level section on wavelength converter pool 193 modeling 195 o Editorial clean up of English and updated references. 197 1.1.2. Changes from 01 199 Fixed error in wavelength converter pool example. 201 1.1.3. Changes from 02 203 Updated the abstract to emphasize the focus of this draft and 204 differentiate it from WSON impairment [WSON-Imp] and WSON 205 compatibility [WSON-Compat] drafts. 207 Added references to [WSON-Imp] and [WSON-Compat]. 209 Updated the introduction to explain the relationship between this 210 document and the [WSON-Imp] and [WSON-Compat] documents. 212 In section 3.1 removed discussion of optical impairments in fibers. 214 Merged section 3.2.2 and section 3.2.3. Deferred much of the 215 discussion of signal types and standards to [WSON-Compat]. 217 In section 3.4 on Wavelength converters removed paragraphs dealing 218 with signal compatibility discussion as this is addressed in [WSON- 219 Compat]. 221 In section 6.1 removed discussion of signaling extensions to deal 222 with different WSON signal types. This is deferred to [WSON-Compat]. 224 In section 6 removed discussion of "Need for Wavelength Specific 225 Maximum Bandwidth Information". 227 In section 6 removed discussion of "Relationship to link bundling and 228 layering". 230 In section 6 removed discussion of "Computation Architecture 231 Implications" as this material was redundant with text that occurs 232 earlier in the document. 234 In section 6 removed discussion of "Scaling Implications" as this 235 material was redundant with text that occurs earlier in the document. 237 1.1.4. Changes from 03 239 In Section 3.3.1 added 4-degree ROADM example and its connectivity 240 matrix. 242 1.1.5. Changes from 04 244 Added and enhanced sections on signal type and network element 245 compatibility. 247 Merged section 3.2.1 into section 3.2. 249 Created new section 3.3 on Optical signals with material from [WSON- 250 Compat]. 252 Created new section 3.5 on Electro-Optical systems with material from 253 [WSON-Compat]. 255 Created new section 3.7 on Characterizing Electro-Optical Network 256 Elements with material from [WSON-Compat]. 258 Created new section 5.5 on Electro-Optical Networking Scenarios with 259 material from [WSON-Compat]. 261 Created new section 6.1.2 on WSON Signals and Network Element 262 Processing with material from [WSON-Compat]. 264 Created new section 6.3.2. Electro-Optical Related PCEP Extensions 265 with material from [WSON-Compat]. 267 1.2. Related Documents 269 This framework document covers essential concepts and models for the 270 application and extension of the control plane to WSONs. The 271 following documents address specific aspects of WSONs and complement 272 this draft. 274 o [WSON-Info] This document provides an information model needed by 275 the routing and wavelength assignment (RWA) process in WSON. 277 o [WSON-Encode] This document provides efficient, protocol-agnostic 278 encodings for the information elements necessary to support the 279 routing and wavelength assignment (RWA) process in WSONs. 281 o [WSON-Imp] This document provides a framework for the support of 282 impairment aware Routing and Wavelength Assignment (RWA) in WSON. 284 o [PCEP-RWA] This document provides application-specific 285 requirements for the Path Computation Element communication 286 Protocol (PCEP) for the support of RWA in WSON. 288 2. Terminology 290 CWDM: Coarse Wavelength Division Multiplexing. 292 DWDM: Dense Wavelength Division Multiplexing. 294 FOADM: Fixed Optical Add/Drop Multiplexer. 296 OXC: Optical cross connect. A symmetric optical switching element in 297 which a signal on any ingress port can reach any egress port. 299 ROADM: Reconfigurable Optical Add/Drop Multiplexer. An asymmetric 300 wavelength selective switching element featuring ingress and egress 301 line side ports as well as add/drop side ports. 303 RWA: Routing and Wavelength Assignment. 305 Wavelength Conversion/Converters: The process of converting an 306 information bearing optical signal centered at a given wavelength to 307 one with "equivalent" content centered at a different wavelength. 308 Wavelength conversion can be implemented via an optical-electronic- 309 optical (OEO) process or via a strictly optical process. 311 WDM: Wavelength Division Multiplexing. 313 Wavelength Switched Optical Networks (WSON): WDM based optical 314 networks in which switching is performed selectively based on the 315 center wavelength of an optical signal. 317 3. Wavelength Switched Optical Networks 319 WSONs come in a variety of shapes and sizes from continent spanning 320 long haul networks, to metropolitan networks, to residential access 321 networks. In all these cases we are concerned with those properties 322 that constrain the choice of wavelengths that can be used, i.e., 323 restrict the wavelength label set, impact the path selection process, 324 and limit the topological connectivity. In addition, if electro- 325 optical network elements are used in the WSON, additional 326 compatibility constraints may be imposed by the network elements on 327 various optical signal parameters. In the following we examine and 328 model some major subsystems of a WSON with an emphasis on those 329 aspects that are of relevance to the control plane. In particular we 330 look at WDM links, Optical Transmitters, ROADMs, and Wavelength 331 Converters. 333 3.1. WDM and CWDM Links 335 WDM and CWDM links run over optical fibers, and optical fibers come 336 in a wide range of types that tend to be optimized for various 337 applications from access networks, metro, long haul, and submarine 338 links to name a few. ITU-T standards exist for various types of 339 fibers. For the purposes here we are concerned only with single mode 340 fibers (SMF). The following SMF fiber types are typically encountered 341 in optical networks: 343 ITU-T Standard | Common Name 344 ------------------------------------------------------------ 345 G.652 [G.652] | Standard SMF | 346 G.653 [G.653] | Dispersion shifted SMF | 347 G.654 [G.654] | Cut-off shifted SMF | 348 G.655 [G.655] | Non-zero dispersion shifted SMF | 349 G.656 [G.656] | Wideband non-zero dispersion shifted SMF | 350 ------------------------------------------------------------ 351 Typically WDM links operate in one or more of the approximately 352 defined optical bands [G.Sup39]: 354 Band Range (nm) Common Name Raw Bandwidth (THz) 355 O-band 1260-1360 Original 17.5 356 E-band 1360-1460 Extended 15.1 357 S-band 1460-1530 Short 9.4 358 C-band 1530-1565 Conventional 4.4 359 L-band 1565-1625 Long 7.1 360 U-band 1625-1675 Ultra-long 5.5 362 Not all of a band may be usable, for example in many fibers that 363 support E-band there is significant attenuation due to a water 364 absorption peak at 1383nm. Hence we can have a discontinuous 365 acceptable wavelength range for a particular link. Also some systems 366 will utilize more than one band. This is particularly true for coarse 367 WDM (CWDM) systems. 369 Current technology breaks up the bandwidth capacity of fibers into 370 distinct channels based on either wavelength or frequency. There are 371 two standards covering wavelengths and channel spacing. ITU-T 372 recommendation [G.694.1] describes a DWDM grid defined in terms of 373 frequency grids of 12.5GHz, 25GHz, 50GHz, 100GHz, and other multiples 374 of 100GHz around a 193.1THz center frequency. At the narrowest 375 channel spacing this provides less than 4800 channels across the O 376 through U bands. ITU-T recommendation [G.694.2] describes a CWDM grid 377 defined in terms of wavelength increments of 20nm running from 1271nm 378 to 1611nm for 18 or so channels. The number of channels is 379 significantly smaller than the 32 bit GMPLS label space allocated to 380 lambda switching. A label representation for these ITU-T grids is 381 given in [Otani] and allows a common vocabulary to be used in 382 signaling lightpaths. Further, these ITU-T grid based labels can also 383 be used to describe WDM links, ROADM ports, and wavelength converters 384 for the purposes of path selection. 386 With a tremendous existing base of fiber many WDM links are designed 387 to take advantage of particular fiber characteristics or to try to 388 avoid undesirable properties. For example dispersion shifted SMF 389 [G.653] was originally designed for good long distance performance in 390 single channel systems, however putting WDM over this type of fiber 391 requires much system engineering and a fairly limited range of 392 wavelengths. Hence for our basic, impairment unaware, modeling of a 393 WDM link we will need the following information: 395 o Wavelength range(s): Given a mapping between labels and the ITU-T 396 grids each range could be expressed in terms of a doublet 397 (lambda1, lambda2) or (freq1, freq1) where the lambdas or 398 frequencies can be represented by 32 bit integers. 400 o Channel spacing: currently there are about five channel spacings 401 used in DWDM systems 12.5GHz to 200GHz and one defined CWDM 402 spacing. 404 For a particular link this information is relatively static, i.e., 405 changes to these properties generally require hardware upgrades. Such 406 information could be used locally during wavelength assignment via 407 signaling, similar to label restrictions in MPLS or used by a PCE in 408 solving the combined routing and wavelength assignment problem. 410 3.2. Optical Transmitters 412 WDM optical systems make use of laser transmitters utilizing 413 different wavelengths (frequencies). Some laser transmitters were and 414 are manufactured for a specific wavelength of operation, that is, the 415 manufactured frequency cannot be changed. First introduced to reduce 416 inventory costs, tunable optical laser transmitters are becoming 417 widely deployed in some systems [Coldren04], [Buus06]. This allows 418 flexibility in the wavelength used for optical transmission and aids 419 in path selection. 421 Fundamental modeling parameters from the control plane perspective 422 optical transmitters are: 424 o Tunable: Is this transmitter tunable or fixed. 426 o Tuning range: This is the frequency or wavelength range over which 427 the laser can be tuned. With the fixed mapping of labels to 428 lambdas of [Otani] this can be expressed as a doublet (lambda1, 429 lambda2) or (freq1, freq2) where lambda1 and lambda2 or freq1 and 430 freq2 are the labels representing the lower and upper bounds in 431 wavelength or frequency. 433 o Tuning time: Tuning times highly depend on the technology used. 434 Thermal drift based tuning may take seconds to stabilize, whilst 435 electronic tuning might provide sub-ms tuning times. Depending on 436 the application this might be critical. For example, thermal drift 437 might not be applicable for fast protection applications. 439 o Spectral Characteristics and stability: The spectral shape of the 440 laser's emissions and its frequency stability put limits on 441 various properties of the overall WDM system. One relatively easy 442 to characterize constraint is the finest channel spacing on which 443 the transmitter can be used. 445 Note that ITU-T recommendations specify many aspects of a laser 446 transmitter. Many of these parameters, such as spectral 447 characteristics and stability, are used in the design of WDM 448 subsystems consisting of transmitters, WDM links and receivers 449 however they do not furnish additional information that will 450 influence label switched path (LSP) provisioning in a properly 451 designed system. 453 Also note that lasers transmitters as a component can degrade and 454 fail over time. This presents the possibility of the failure of a LSP 455 (lightpath) without either a node or link failure. Hence, additional 456 mechanisms may be necessary to detect and differentiate this failure 457 from the others, e.g., one doesn't not want to initiate mesh 458 restoration if the source transmitter has failed, since the laser 459 transmitter will still be failed on the alternate optical path. 461 3.3. Optical Signals in WSONs 463 In wavelength switched optical networks (WSONs) our fundamental unit 464 of switching is intuitively that of a "wavelength". The transmitters 465 and receivers in these networks will deal with one wavelength at a 466 time, while the switching systems themselves can deal with multiple 467 wavelengths at a time. Hence we are generally concerned with 468 multichannel dense wavelength division multiplexing (DWDM) networks 469 with single channel interfaces. Interfaces of this type are defined 470 in ITU-T recommendations [G.698.1] and [G.698.1]. Key non-impairment 471 related parameters defined in [G.698.1] and [G.698.2] are: 473 (a) Minimum Channel Spacing (GHz) 475 (b) Minimum and Maximum central frequency 477 (c) Bit-rate/Line coding (modulation) of optical tributary signals 479 In for the purposes of modeling the WSON in the control plane we can 480 consider (a) and (b) as properties of the link and restrictions on 481 the GMPLS labels while (c) is a property of the "signal". 483 3.3.1. Optical Tributary Signals 485 The optical interface specifications [G.698.1], [G.698.2], and 486 [G.959.1] all use the concept of an Optical Tributary Signal which is 487 defined as "a single channel signal that is placed within an optical 488 channel for transport across the optical network". Note the use of 489 the qualifier "tributary" to indicate that this is a single channel 490 entity and not a multichannel optical signal. 492 There are a currently a number of different "flavors" of optical 493 tributary signals, known as "optical tributary signal classes". These 494 are currently characterized by a modulation format and bit rate range 495 [G.959.1]: 497 (a) optical tributary signal class NRZ 1.25G 499 (b) optical tributary signal class NRZ 2.5G 501 (c) optical tributary signal class NRZ 10G 503 (d) optical tributary signal class NRZ 40G 505 (e) optical tributary signal class RZ 40G 507 Note that with advances in technology more optical tributary signal 508 classes may be added and that this is currently an active area for 509 deployment and standardization. In particular at the 40G rate there 510 are a number of non-standardized advanced modulation formats that 511 have seen significant deployment including Differential Phase Shift 512 Keying (DPSK) and Phase Shaped Binary Transmission (PSBT)[Winzer06]. 514 Note that according to [G.698.2] it is important to fully specify the 515 bit rate of the optical tributary signal: 517 "When an optical system uses one of these codes, therefore, it is 518 necessary to specify both the application code and also the exact bit 519 rate of the system. In other words, there is no requirement for 520 equipment compliant with one of these codes to operate over the 521 complete range of bit rates specified for its optical tributary 522 signal class." 524 Hence we see that modulation format (optical tributary signal class) 525 and bit rate are key parameters in characterizing the optical 526 tributary signal. 528 3.3.2. WSON Signal Characteristics 530 We refer an optical tributary signal defined in ITU-T G.698.1 and .2 531 to as the signal in this document. This is an "entity" that can be 532 put on an optical communications channel formed from links and 533 network elements in a WSON. This corresponds to the "lambda" LSP in 534 GMPLS. For signal compatibility purposes with electro-optical network 535 elements we will be interested in the following signal 536 characteristics: 538 List 1. WSON Signal Characteristics 540 1. Optical tributary signal class (modulation format). 541 2. FEC: whether forward error correction is used in the digital stream 542 and what type of error correcting code is used 543 3. Center frequency (wavelength) 544 4. Bit rate 545 5. G-PID: General Protocol Identifier for the information format 547 The first three items on this list can change as a WSON signal 548 traverses a network with regenerators, OEO switches, or wavelength 549 converters. 551 Bit rate and GPID would not change since they describe the encoded 552 bit stream. A set of G-PID values is already defined for lambda 553 switching in [RFC3471] and [RFC4328]. 555 Note that a number of "pre-standard" or proprietary modulation 556 formats and FEC codes are commonly used in WSONs. For some digital 557 bit streams the presence of FEC can be detected, e.g., in [G.707] 558 this is indicated in the signal itself via the FEC status indication 559 (FSI) byte, while in [G.709] this can be inferred from whether the 560 FEC field of the OTUk is all zeros or not. 562 3.4. ROADMs, OXCs, Splitters, Combiners and FOADMs 564 Definitions of various optical devices and their parameters can be 565 found in [G.671], we only look at a subset of these and their non- 566 impairment related properties. 568 3.4.1. Reconfigurable Add/Drop Multiplexers and OXCs 570 Reconfigurable add/drop optical multiplexers (ROADM) have matured and 571 are available in different forms and technologies [Basch06]. This is 572 a key technology that allows wavelength based optical switching. A 573 classic degree-2 ROADM is shown in Figure 1. 575 Line side ingress +---------------------+ Line side egress 576 --->| |---> 577 | | 578 | ROADM | 579 | | 580 | | 581 +---------------------+ 582 | | | | o o o o 583 | | | | | | | | 584 O O O O | | | | 585 Tributary Side: Drop (egress) Add (ingress) 587 Figure 1 Degree-2 ROADM 589 The key feature across all ROADM types is their highly asymmetric 590 switching capability. In the ROADM of Figure 1, the "add" ingress 591 ports can only egress on the line side egress port and not on any of 592 the "drop" egress ports. The degree of a ROADM or switch is given by 593 the number of line side ports (ingress and egress) and does not 594 include the number of "add" or "drop" ports. Sometimes the "add" 595 "drop" ports are also called tributary ports. As the degree of the 596 ROADM increases beyond two it can have properties of both a switch 597 (OXC) and a multiplexer and hence we must know the switched 598 connectivity offered by such a network element to effectively utilize 599 it. A straight forward way to do this is via a "switched 600 connectivity" matrix A where Amn = 0 or 1, depending upon whether a 601 wavelength on ingress port m can be connected to egress port n 602 [Imajuku]. For the ROADM of Figure 1 the switched connectivity matrix 603 can be expressed as 604 Ingress Egress Port 605 Port #1 #2 #3 #4 #5 606 -------------- 607 #1: 1 1 1 1 1 608 #2 1 0 0 0 0 609 A = #3 1 0 0 0 0 610 #4 1 0 0 0 0 611 #5 1 0 0 0 0 613 Where ingress ports 2-5 are add ports, egress ports 2-5 are drop 614 ports and ingress port #1 and egress port #1 are the line side (WDM) 615 ports. 617 For ROADMs this matrix will be very sparse, and for OXCs the 618 complement of the matrix will be very sparse, compact encodings and 619 examples, including high degree ROADMs/OXCs, are given in [WSON- 620 Encode]. A classic degree-4 ROADM is shown in Figure 2. 622 +-----------------------+ 623 Line side-1 --->| |---> Line side-2 624 ingress (I1) | | egress (E2) 625 Line side-1 <---| |<--- Line side-2 626 Egress (E1) | | Ingress (I2) 627 | ROADM | 628 Line side-3 --->| |---> Line side-4 629 ingress (I3) | | egress (E4) 630 Line side-3 <---| |<--- Line side-4 631 Egress (E3) | | Ingress (I4) 632 | | 633 +-----------------------+ 634 | O | O | O | O 635 | | | | | | | | 636 O | O | O | O | 637 Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 639 Figure 2 Degree-4 ROADM 641 Note that this example is 4-degree example with one (potentially 642 multi-channel) add/drop per line side port. 644 Note also that the connectivity constraints for typical ROADM designs 645 are "bi-directional", i.e. if ingress port X can be connected to 646 egress port Y, typically ingress port Y can be connected to egress 647 port X, assuming the numbering is done in such a way that ingress X 648 and egress X correspond to the same line side direction or the same 649 add/drop port. This makes the connectivity matrix symmetrical as 650 shown below. 652 Ingress Egress Port 653 Port E1 E2 E3 E4 E5 E6 E7 E8 654 ----------------------- 655 I1 0 1 1 1 0 1 0 0 656 I2 1 0 1 1 0 0 1 0 657 A = I3 1 1 0 1 1 0 0 0 658 I4 1 1 1 0 0 0 0 1 659 I5 0 0 1 0 0 0 0 0 660 I6 1 0 0 0 0 0 0 0 661 I7 0 1 0 0 0 0 0 0 662 I8 0 0 0 1 0 0 0 0 664 where I5/E5 are add/drop ports to/from line side-3, I6/E6 are 665 add/drop ports to/from line side-1, I7/E7 are add/drop ports to/from 666 line side-2 and I8/E8 are add/drop ports to/from line side-4. Note 667 that diagonal elements are zero since it is assumed that loopback is 668 not supported. If ports support loopback, diagonal elements would be 669 one. 671 Additional constraints may also apply to the various ports in a 672 ROADM/OXC. In the literature of optical switches and ROADMs the 673 following restrictions/terms are used: 675 Colored port: An ingress or more typically an egress (drop) port 676 restricted to a single channel of fixed wavelength. 678 Colorless port: An ingress or more typically an egress (drop) port 679 restricted to a single channel of arbitrary wavelength. 681 In general a port on a ROADM could have any of the following 682 wavelength restrictions: 684 o Multiple wavelengths, full range port 686 o Single wavelength, full range port 688 o Single wavelength, fixed lambda port 690 o Multiple wavelengths, reduced range port (for example wave band 691 switching) 693 To model these restrictions we need two pieces of information for 694 each port: (a) number of wavelengths, (b) wavelength range and 695 spacing. Note that this information is relatively static. More 696 complicated wavelength constraints are modeled in [WSON-Info]. 698 3.4.2. Splitters 700 An optical splitter consists of a single ingress port and two or more 701 egress ports. The ingress optical signaled is essentially copied 702 (with power loss) to all egress ports. 704 Using the modeling notions of section 3.4.1. the ingress and egress 705 ports of a splitter would have the same wavelength restrictions. In 706 addition we can describe a splitter by a connectivity matrix Amn as 707 follows: 709 Ingress Egress Port 710 Port #1 #2 #3 ... #N 711 ----------------- 712 A = #1 1 1 1 ... 1 714 The difference from a simple ROADM is that this is not a switched 715 (potential) connectivity matrix but the fixed connectivity matrix of 716 the device. 718 3.4.3. Combiners 720 A optical combiner is somewhat the dual of a splitter in that it has 721 a single multi-wavelength egress port and multiple ingress ports. 722 The contents of all the ingress ports are copied and combined to the 723 single egress port. The various ports may have different wavelength 724 restrictions. It is generally the responsibility of those using the 725 combiner to assure that wavelength collision does not occur on the 726 egress port. The fixed connectivity matrix Amn for a combiner would 727 look like: 729 Ingress Egress Port 730 Port #1 731 --- 732 #1: 1 733 #2 1 734 A = #3 1 735 ... 1 736 #N 1 738 3.4.4. Fixed Optical Add/Drop Multiplexers 740 A fixed optical add/drop multiplexer can alter the course of an 741 ingress wavelength in a preset way. In particular a given wavelength 742 (or waveband) from a line side ingress port would be dropped to a 743 fixed "tributary" egress port. Depending on the device's construction 744 that same wavelength may or may not be "continued" to the line side 745 egress port ("drop and continue" operation). Further there may exist 746 tributary ingress ports ("add" ports) whose signals are combined with 747 each other and "continued" line side signals. 749 In general to represent the routing properties of an FOADM we need a 750 fixed connectivity matrix Amn as previously discussed and we need the 751 precise wavelength restrictions for all ingress and egress ports. 752 From the wavelength restrictions on the tributary egress ports (drop 753 ports) we can see what wavelengths have been dropped. From the 754 wavelength restrictions on the tributary ingress (add) ports we can 755 see which wavelengths have been added to the line side egress port. 756 Finally from the added wavelength information and the line side 757 egress wavelength restrictions we can infer which wavelengths have 758 been continued. 760 To summarize, the modeling methodology introduced in section 3.4.1. 761 consisting of a connectivity matrix and port wavelength restrictions 762 can be used to describe a large set of fixed optical devices such as 763 combiners, splitters and FOADMs. Hybrid devices consisting of both 764 switched and fixed parts are modeled in [WSON-Info]. 766 3.5. Electro-Optical Systems 768 This section describes how Electro-Optical Systems (e.g., OEO 769 switches, wavelength converters, and regenerators) interact with the 770 WSON signal characteristics defined in List 1 in Section 2.3. OEO 771 switches, wavelength converters and regenerators all share a similar 772 property: they can be more or less "transparent" to an "optical 773 signal" depending on their functionality and/or implementation. 774 Regenerators have been fairly well characterized in this regard so we 775 start by describing their properties. 777 3.5.1. Regenerators 779 The various approaches to regeneration are discussed in ITU-T G.872 780 Annex A [G.872]. They map a number of functions into the so-called 781 1R, 2R and 3R categories of regenerators as summarized in Table 1 782 below: 784 Table 1 Regenerator functionality mapped to general regenerator 785 classes from [G.872]. 787 --------------------------------------------------------------------- 788 1R | Equal amplification of all frequencies within the amplification 789 | bandwidth. There is no restriction upon information formats. 790 +----------------------------------------------------------------- 791 | Amplification with different gain for frequencies within the 792 | amplification bandwidth. This could be applied to both single- 793 | channel and multi-channel systems. 794 +----------------------------------------------------------------- 795 | Dispersion compensation (phase distortion). This analogue 796 | process can be applied in either single-channel or multi- 797 | channel systems. 798 --------------------------------------------------------------------- 799 2R | Any or all 1R functions. Noise suppression. 800 +----------------------------------------------------------------- 801 | Digital reshaping (Schmitt Trigger function) with no clock 802 | recovery. This is applicable to individual channels and can be 803 | used for different bit rates but is not transparent to line 804 | coding (modulation). 805 -------------------------------------------------------------------- 806 3R | Any or all 1R and 2R functions. Complete regeneration of the 807 | pulse shape including clock recovery and retiming within 808 | required jitter limits. 809 -------------------------------------------------------------------- 811 From the previous table we can see that 1R regenerators are generally 812 independent of signal modulation format (also known as line coding), 813 but may work over a limited range of wavelength/frequencies. We see 814 that 2R regenerators are generally applicable to a single digital 815 stream and are dependent upon modulation format (line coding) and to 816 a lesser extent are limited to a range of bit rates (but not a 817 specific bit rate). Finally, 3R regenerators apply to a single 818 channel, are dependent upon the modulation format and generally 819 sensitive to the bit rate of digital signal, i.e., either are 820 designed to only handle a specific bit rate or need to be programmed 821 to accept and regenerate a specific bit rate. In all these types of 822 regenerators the digital bit stream contained within the optical or 823 electrical signal is not modified. 825 However, in the most common usage of regenerators the digital bit 826 stream may be slightly modified for performance monitoring and fault 827 management purposes. SONET, SDH and G.709 all have digital signal 828 "envelopes" designed to be used between "regenerators" (in this case 829 3R regenerators). In SONET this is known as the "section" signal, in 830 SDH this is known as the "regenerator section" signal, in G.709 this 831 is known as an OTUk (Optical Channel Transport Unit-k). These 832 signals reserve a portion of their frame structure (known as 833 overhead) for use by regenerators. The nature of this overhead is 834 summarized in Table 2. 836 Table 2. SONET, SDH, and G.709 regenerator related overhead. 838 +-----------------------------------------------------------------+ 839 |Function | SONET/SDH | G.709 OTUk | 840 | | Regenerator | | 841 | | Section | | 842 |------------------+----------------------+-----------------------| 843 |Signal | J0 (section | Trail Trace | 844 |Identifier | trace) | Identifier (TTI) | 845 |------------------+----------------------+-----------------------| 846 |Performance | BIP-8 (B1) | BIP-8 (within SM) | 847 |Monitoring | | | 848 |------------------+----------------------+-----------------------| 849 |Management | D1-D3 bytes | GCC0 (general | 850 |Communications | | communications | 851 | | | channel) | 852 |------------------+----------------------+-----------------------| 853 |Fault Management | A1, A2 framing | FAS (frame alignment | 854 | | bytes | signal), BDI(backward| 855 | | | defect indication)BEI| 856 | | | (backward error | 857 | | | indication) | 858 +------------------+----------------------+-----------------------| 859 |Forward Error | P1,Q1 bytes | OTUk FEC | 860 |Correction (FEC) | | | 861 +-----------------------------------------------------------------+ 863 In the previous table we see support for frame alignment, signal 864 identification, and FEC. What this table also shows by its omission 865 is that no switching or multiplexing occurs at this layer. This is a 866 significant simplification for the control plane since control plane 867 standards require a multi-layer approach when there are multiple 868 switching layers, but not for "layering" to provide the management 869 functions of Table 2. That is, many existing technologies covered by 870 GMPLS contain extra management related layers that are essentially 871 ignored by the control plane (though not by the management plane!). 872 Hence, the approach here is to include regenerators and other devices 873 at the WSON layer unless they provide higher layer switching and then 874 a multi-layer or multi-region approach [RFC5212] is called for. 875 However, this can result in regenerators having a dependence on the 876 client signal type. 878 Hence we see that depending upon the regenerator technology we may 879 have the following constraints imposed by a regenerator device: 881 Table 3. Regenerator Compatibility Constraints 883 +--------------------------------------------------------+ 884 | Constraints | 1R | 2R | 3R | 885 +--------------------------------------------------------+ 886 | Limited Wavelength Range | x | x | x | 887 +--------------------------------------------------------+ 888 | Modulation Type Restriction | | x | x | 889 +--------------------------------------------------------+ 890 | Bit Rate Range Restriction | | x | x | 891 +--------------------------------------------------------+ 892 | Exact Bit Rate Restriction | | | x | 893 +--------------------------------------------------------+ 894 | Client Signal Dependence | | | x | 895 +--------------------------------------------------------+ 897 Note that Limited Wavelength Range constraint is already modeled in 898 GMPLS for WSON and that Modulation Type Restriction constraint 899 includes FEC. 901 3.5.2. OEO Switches 903 A common place where optical-to-electrical-to-optical (OEO) 904 processing may take place is in WSON switches that utilize (or 905 contain) regenerators. A vendor may add regenerators to a switching 906 system for a number of reasons. One obvious reason is to restore 907 signal quality either before or after optical processing (switching). 908 Another reason may be to convert the signal to an electronic form for 909 switching then reconverting to an optical signal prior to egress from 910 the switch. In this later case the regeneration is applied to adapt 911 the signal to the switch fabric regardless of whether or not it is 912 needed from a signal quality perspective. 914 In either case these optical switches have essentially the same 915 compatibility constraints as those we described for regenerators in 916 Table 3. 918 3.6. Wavelength Converters 920 Wavelength converters take an ingress optical signal at one 921 wavelength and emit an equivalent content optical signal at another 922 wavelength on egress. There are currently two approaches to building 923 wavelength converters. One approach is based on optical to electrical 924 to optical (OEO) conversion with tunable lasers on egress. This 925 approach can be dependent upon the signal rate and format, i.e., this 926 is basically an electrical regenerator combined with a tunable laser. 927 Hence, this type wavelength converter has signal processing 928 restrictions that are essentially the same as those we described for 929 regenerators in Table 3 of section 3.5.1. 931 The other approach performs the wavelength conversion, optically via 932 non-linear optical effects, similar in spirit to the familiar 933 frequency mixing used in radio frequency systems, but significantly 934 harder to implement. Such processes/effects may place limits on the 935 range of achievable conversion. These may depend on the wavelength of 936 the input signal and the properties of the converter as opposed to 937 only the properties of the converter in the OEO case. Different WSON 938 system designs may choose to utilize this component to varying 939 degrees or not at all. 941 Current or envisioned contexts for wavelength converters are: 943 1. Wavelength conversion associated with OEO switches and tunable 944 laser transmitters. In this case there are plenty of converters to 945 go around since we can think of each tunable output laser 946 transmitter on an OEO switch as a potential wavelength converter. 948 2. Wavelength conversion associated with ROADMs/OXCs. In this case we 949 may have a limited pool of wavelength converters available. 950 Conversion could be either all optical or via an OEO method. 952 3. Wavelength conversion associated with fixed devices such as FOADMs. 953 In this case we may have a limited amount of conversion. Also in 954 this case the conversion may be used as part of light path routing. 956 Based on the above considerations we model wavelength converters as 957 follows: 959 1. Wavelength converters can always be modeled as associated with 960 network elements. This includes fixed wavelength routing elements. 962 2. A network element may have full wavelength conversion capability, 963 i.e., any ingress port and wavelength, or a limited number of 964 wavelengths and ports. On a box with a limited number of 965 converters there also may exist restrictions on which ports can 966 reach the converters. Hence regardless of where the converters 967 actually are we can associate them with ingress ports. 969 3. Wavelength converters have range restrictions that are either 970 independent or dependent upon the ingress wavelength. 972 In WSONs where wavelength converters are sparse we may actually see a 973 light path appear to loop or "backtrack" upon itself in order to 974 reach a wavelength converter prior to continuing on to its 975 destination. The lambda used on the "detour" out to the wavelength 976 converter would be different from that coming back from the "detour" 977 to the wavelength converter. 979 A model for an individual O-E-O wavelength converter would consist 980 of: 982 o Input lambda or frequency range 984 o Output lambda or frequency range 986 3.6.1. Wavelength Converter Pool Modeling 988 A WSON node may include multiple wavelength converters. These are 989 usually arranged into some type of pool to promote resource sharing. 990 There are a number of different approaches used in the design of 991 switches with converter pools. However, from the point of view of 992 path computation we need to know the following: 994 1. The nodes that support wavelength conversion. 996 2. The accessibility and availability of a wavelength converter to 997 convert from a given ingress wavelength on a particular ingress 998 port to a desired egress wavelength on a particular egress port. 1000 3. Limitations on the types of signals that can be converted and the 1001 conversions that can be performed. 1003 To model point 2 above we can use a similar technique as used to 1004 model ROADMs and optical switches, i.e., matrices to indicate 1005 possible connectivity along with wavelength constraints for 1006 links/ports. Since wavelength converters are considered a scarce 1007 resource we will also want our model to include as a minimum the 1008 usage state of individual wavelength converters in the pool. 1010 We utilize a three stage model as shown schematically in Figure 3. In 1011 this model we assume N ingress ports (fibers), P wavelength 1012 converters, and M egress ports (fibers). Since not all ingress ports 1013 can necessarily reach the converter pool, the model starts with a 1014 wavelength pool ingress matrix WI(i,p) = {0,1} whether ingress port i 1015 can reach potentially reach wavelength converter p. 1017 Since not all wavelength can necessarily reach all the converters or 1018 the converters may have limited input wavelength range we have a set 1019 of ingress port constraints for each wavelength converter. Currently 1020 we assume that a wavelength converter can only take a single 1021 wavelength on input. We can model each wavelength converter ingress 1022 port constraint via a wavelength set mechanism. 1024 Next we have a state vector WC(j) = {0,1} dependent upon whether 1025 wavelength converter j in the pool is in use. This is the only state 1026 kept in the converter pool model. This state is not necessary for 1027 modeling "fixed" transponder system, i.e., systems where there is no 1028 sharing. In addition, this state information may be encoded in a 1029 much more compact form depending on the overall connectivity 1030 structure [WSON-Encode]. 1032 After that, we have a set of wavelength converter egress wavelength 1033 constraints. These constraints indicate what wavelengths a particular 1034 wavelength converter can generate or are restricted to generating due 1035 to internal switch structure. 1037 Finally, we have a wavelength pool egress matrix WE(p,k) = {0,1} 1038 depending on whether the output from wavelength converter p can reach 1039 egress port k. Examples of this method being used to model wavelength 1040 converter pools for several switch architectures from the literature 1041 are given in reference [WSON-Encode]. 1043 I1 +-------------+ +-------------+ E1 1044 ----->| | +--------+ | |-----> 1045 I2 | +------+ WC #1 +-------+ | E2 1046 ----->| | +--------+ | |-----> 1047 | Wavelength | | Wavelength | 1048 | Converter | +--------+ | Converter | 1049 | Pool +------+ WC #2 +-------+ Pool | 1050 | | +--------+ | | 1051 | Ingress | | Egress | 1052 | Connection | . | Connection | 1053 | Matrix | . | Matrix | 1054 | | . | | 1055 | | | | 1056 IN | | +--------+ | | EM 1057 ----->| +------+ WC #P +-------+ |-----> 1058 | | +--------+ | | 1059 +-------------+ ^ ^ +-------------+ 1060 | | 1061 | | 1062 | | 1063 | | 1065 Ingress wavelength Egress wavelength 1066 constraints for constraints for 1067 each converter each converter 1069 Figure 3 Schematic diagram of wavelength converter pool model. 1071 Example: Shared Per Node 1073 In Figure 4 below we show a simple optical switch in a four 1074 wavelength DWDM system sharing wavelength converters in a general 1075 "per node" fashion. 1077 +-----------+ ___________ +------+ 1078 | |--------------------------->| | 1079 | |--------------------------->| C | 1080 /| | |--------------------------->| o | E1 1081 I1 /D+--->| |--------------------------->| m | 1082 + e+--->| | | b |====> 1083 ====>| M| | Optical | +-----------+ +----+ | i | 1084 + u+--->| Switch | | WC Pool | |O S|-->| n | 1085 \x+--->| | | +-----+ | |p w|-->| e | 1086 \| | +----+->|WC #1|--+->|t i| | r | 1087 | | | +-----+ | |i t| +------+ 1088 | | | | |c c| +------+ 1089 /| | | | +-----+ | |a h|-->| | 1090 I2 /D+--->| +----+->|WC #2|--+->|l |-->| C | E2 1091 + e+--->| | | +-----+ | | | | o | 1092 ====>| M| | | +-----------+ +----+ | m |====> 1093 + u+--->| | | b | 1094 \x+--->| |--------------------------->| i | 1095 \| | |--------------------------->| n | 1096 | |--------------------------->| e | 1097 |___________|--------------------------->| r | 1098 +-----------+ +------+ 1100 Figure 4 An optical switch featuring a shared per node wavelength 1101 converter pool architecture. 1103 In this case the ingress and egress pool matrices are simply: 1105 +-----+ +-----+ 1106 | 1 1 | | 1 1 | 1107 WI =| |, WE =| | 1108 | 1 1 | | 1 1 | 1109 +-----+ +-----+ 1111 Example: Shared Per Link 1113 In Figure 5 we show a different wavelength pool architecture know as 1114 "shared per fiber". In this case the ingress and egress pool matrices 1115 are simply: 1117 +-----+ +-----+ 1118 | 1 1 | | 1 0 | 1119 WI =| |, WE =| | 1120 | 1 1 | | 0 1 | 1121 +-----+ +-----+ 1123 +-----------+ +------+ 1124 | |--------------------------->| | 1125 | |--------------------------->| C | 1126 /| | |--------------------------->| o | E1 1127 I1 /D+--->| |--------------------------->| m | 1128 + e+--->| | | b |====> 1129 ====>| M| | Optical | +-----------+ | i | 1130 + u+--->| Switch | | WC Pool | | n | 1131 \x+--->| | | +-----+ | | e | 1132 \| | +----+->|WC #1|--+---------->| r | 1133 | | | +-----+ | +------+ 1134 | | | | +------+ 1135 /| | | | +-----+ | | | 1136 I2 /D+--->| +----+->|WC #2|--+---------->| C | E2 1137 + e+--->| | | +-----+ | | o | 1138 ====>| M| | | +-----------+ | m |====> 1139 + u+--->| | | b | 1140 \x+--->| |--------------------------->| i | 1141 \| | |--------------------------->| n | 1142 | |--------------------------->| e | 1143 |___________|--------------------------->| r | 1144 +-----------+ +------+ 1145 Figure 5 An optical switch featuring a shared per fiber wavelength 1146 converter pool architecture. 1148 3.7. Characterizing Electro-Optical Network Elements 1150 In this section we characterize Electro-Optical WSON network elements 1151 by the three key functional components: Input constraints, Output 1152 constraints and Processing Capabilities. 1154 WSON Network Element 1155 +-----------------------+ 1156 WSON Signal | | | | WSON Signal 1157 | | | | 1158 ---------------> | | | | -----------------> 1159 | | | | 1160 +-----------------------+ 1161 <-----> <-------> <-----> 1163 Input Processing Output 1165 Figure 6 WSON Network Element 1167 3.7.1. Input Constraints 1169 Section 3 discussed the basic properties regenerators, OEO switches 1170 and wavelength converters from these we have the following possible 1171 types of input constraints and properties: 1173 1. Acceptable Modulation formats 1175 2. Client Signal (GPID) restrictions 1177 3. Bit Rate restrictions 1179 4. FEC coding restrictions 1181 5. Configurability: (a) none, (b) self-configuring, (c) required 1183 We can represent these constraints via simple lists. Note that the 1184 device may need to be "provisioned" via signaling or some other means 1185 to accept signals with some attributes versus others. In other cases 1186 the devices maybe relatively transparent to some attributes, e.g., 1187 such as a 2R regenerator to bit rate. Finally, some devices maybe 1188 able to auto-detect some attributes and configure themselves, e.g., a 1189 3R regenerator with bit rate detection mechanisms and flexible phase 1190 locking circuitry. To account for these different cases we've added 1191 item 5, which describes the devices configurability. 1193 Note that such input constraints also apply to the final destination, 1194 sink or termination, of the WSON signal. 1196 3.7.2. Output Constraints 1198 None of the network elements considered here modifies either the bit 1199 rate or the basic type of the client signal. However, they may modify 1200 the modulation format or the FEC code. Typically we'd see the 1201 following types of output constraints: 1203 1. Output modulation is the same as input modulation (default) 1205 2. A limited set of output modulations is available 1207 3. Output FEC is the same as input FEC code (default) 1209 4. A limited set of output FEC codes is available 1211 Note that in cases (2) and (4) above, where there is more than one 1212 choice in the output modulation or FEC code then the network element 1213 will need to be configured on a per LSP basis as to which choice to 1214 use. 1216 3.7.3. Processing Capabilities 1218 A general WSON network element (NE) can perform a number of signal 1219 processing functions including: 1221 (A) Regeneration (possibly different types) 1223 (B) Fault and Performance Monitoring 1225 (C) Wavelength Conversion 1227 (D) Switching 1229 Item(D) can be modeled with existing GMPLS mechanisms. 1231 An NE may or may not have the ability to perform regeneration (of the 1232 one of the types previously discussed). In addition some nodes may 1233 have limited regeneration capability, i.e., a shared pool, which may 1234 be applied to selected signals traversing the NE. Hence to describe 1235 the regeneration capability of a link or node we have at a minimum: 1237 1. Regeneration capability: (a)fixed, (b) selective, (c) none 1239 2. Regeneration type: 1R, 2R, 3R 1241 3. Regeneration pool properties for the case of selective 1242 regeneration (ingress & egress restrictions, availability) 1244 Note that the properties of shared regenerator pools would be 1245 essentially the same at that of wavelength converter pools modeled in 1246 section 3.6.1. 1248 Item (B), fault and performance monitoring, is typically outside the 1249 scope of the control plane. However, when the operations are to be 1250 performed on an LSP basis or as part of an LSP then the control plane 1251 can be of assistance in their configuration. Per LSP, per node, fault 1252 and performance monitoring examples include setting up a "section 1253 trace" (a regenerator overhead identifier) between two nodes, or 1254 intermediate optical performance monitoring at selected nodes along a 1255 path. 1257 4. Routing and Wavelength Assignment and the Control Plane 1259 In wavelength switched optical networks consisting of tunable lasers 1260 and wavelength selective switches with wavelength converters on every 1261 interface, path selection is similar to the MPLS and TDM circuit 1262 switched cases in that the labels, in this case wavelengths 1263 (lambdas), have only local significance. That is, a wavelength- 1264 convertible network with full wavelength-conversion capability at 1265 each node is equivalent to a circuit-switched TDM network with full 1266 time slot interchange capability; thus, the routing problem needs to 1267 be addressed only at the level of the traffic engineered (TE) link 1268 choice, and wavelength assignment can be resolved locally by the 1269 switches on a hop-by-hop basis. 1271 However, in the limiting case of an optical network with no 1272 wavelength converters, a light path (optical signal) needs a route 1273 from source to destination and must pick a single wavelength that can 1274 be used along that path without "colliding" with the wavelength used 1275 by any other light path that may share an optical fiber. This is 1276 sometimes referred to as a "wavelength continuity constraint". To 1277 ease up on this constraint while keeping network costs in check a 1278 limited number of wavelength converters may be introduced at key 1279 points in the network [Chu03]. 1281 In the general case of limited or no wavelength converters this 1282 computation is known as the Routing and Wavelength Assignment (RWA) 1283 problem [HZang00]. The "hardness" of this problem is well documented. 1284 There, however, exist a number of reasonable approximate methods for 1285 its solution [HZang00]. 1287 The inputs to the basic RWA problem are the requested light paths 1288 source and destination, the network's topology, the locations and 1289 capabilities of any wavelength converters, and the wavelengths 1290 available on each optical link. The output from an algorithm solving 1291 the RWA problem is an explicit route through ROADMs, a wavelength for 1292 the optical transmitter, and a set of locations (generally associated 1293 with ROADMs or switches) where wavelength conversion is to occur and 1294 the new wavelength to be used on each component link after that point 1295 in the route. 1297 It is to be noted that choice of specific RWA algorithm is out of the 1298 scope for this document. However there are a number of different 1299 approaches to dealing with the RWA algorithm that can affect the 1300 division of effort between signaling, routing and PCE. 1302 4.1. Architectural Approaches to RWA 1304 Two general computational approaches are taken to solving the RWA 1305 problem. Some algorithms utilize a two step procedure of path 1306 selection followed by wavelength assignment, and others solve the 1307 problem in a combined fashion. 1309 In the following, three different ways of performing RWA in 1310 conjunction with the control plane are considered. The choice of one 1311 of these architectural approaches over another generally impacts the 1312 demands placed on the various control plane protocols. 1314 4.1.1. Combined RWA (R&WA) 1316 In this case, a unique entity is in charge of performing routing and 1317 wavelength assignment. This approach relies on a sufficient knowledge 1318 of network topology, of available network resources and of network 1319 nodes capabilities. This solution is compatible with most known RWA 1320 algorithms, and in particular those concerned with network 1321 optimization. On the other hand, this solution requires up-to-date 1322 and detailed network information. 1324 Such a computational entity could reside in two different logical 1325 places: 1327 o In a separate Path Computation Element (PCE) which owns the 1328 complete and updated knowledge of network state and provides path 1329 computation services to nodes. 1331 o In the Ingress node, in that case all nodes have the R&WA 1332 functionality; the knowledge of the network state is obtained by a 1333 periodic flooding of information provided by the other nodes. 1335 4.1.2. Separated R and WA (R+WA) 1337 In this case a first entity performs routing, while a second performs 1338 wavelength assignment. The first entity furnishes one or more paths 1339 to the second entity that will perform wavelength assignment and 1340 possibly final path selection. 1342 As the entities computing the path and the wavelength assignment are 1343 separated, this constrains the class of RWA algorithms that may be 1344 implemented. Although it may seem that algorithms optimizing a joint 1345 usage of the physical and spectral paths are excluded from this 1346 solution, many practical optimization algorithms only consider a 1347 limited set of possible paths, e.g., as computed via a k-shortest 1348 path algorithm [Ozdaglar03]. Hence although there is no guarantee 1349 that the selected final route and wavelength offers the optimal 1350 solution, by allowing multiple routes to pass to the wavelength 1351 selection process reasonable optimization can be performed. 1353 The entity performing the routing assignment needs the topology 1354 information of the network, whereas the entity performing the 1355 wavelength assignment needs information on the network's available 1356 resources and on network node capabilities. 1358 4.1.3. Routing and Distributed WA (R+DWA) 1360 In this case a first entity performs routing, while wavelength 1361 assignment is performed on a hop-by-hop manner along the previously 1362 computed route. This mechanism relies on updating of a list of 1363 potential wavelengths used to ensure conformance with the wavelength 1364 continuity constraint. 1366 As currently specified, the GMPLS protocol suite signaling protocol 1367 can accommodate such an approach. Per [RFC3471], the Label Set 1368 selection works according to an AND scheme. Each hop restricts the 1369 Label Set sent to the next hop from the one received from the 1370 previous hop by performing an AND operation between the wavelength 1371 referred by the labels the message includes with the one available on 1372 the ongoing interface. The constraint to perform this AND operation 1373 is up to the node local policy (even if one expects a consistent 1374 policy configuration throughout a given transparency domain). When 1375 wavelength conversion is performed at an intermediate node, a new 1376 Label Set is generated. The egress nodes selects one label in the 1377 Label Set received at the node, which is also up to the node local 1378 policy. 1380 Depending on these policies a spectral assignment may not be found or 1381 one consuming too many conversion resources relative to what a 1382 dedicated wavelength assignment policy would have achieved. Hence, 1383 this approach may generate higher blocking probabilities in a heavily 1384 loaded network. 1386 On the one hand, this solution may be empowered with some signaling 1387 extensions to ease its functioning and possibly enhance its 1388 performances relatively to blocking. Note that this approach requires 1389 less information dissemination than the others. 1391 The first entity may be a PCE or the ingress node of the LSP. This 1392 solution is applicable inside networks where resource optimization is 1393 not as critical. 1395 4.2. Conveying information needed by RWA 1397 The previous sections have characterized WSONs and lightpath 1398 requests. In particular, high level models of the information used by 1399 the RWA process were presented. We can view this information as 1400 either static, changing with hardware changes (including possibly 1401 failures), or dynamic, those that can change with subsequent 1402 lightpath provisioning. The timeliness in which an entity involved in 1403 the RWA process is notified of such changes is fairly situational. 1404 For example, for network restoration purposes, learning of a hardware 1405 failure or of new hardware coming online to provide restoration 1406 capability can be critical. 1407 Currently there are various methods for communicating RWA relevant 1408 information, these include, but are not limited to: 1410 o Existing control plane protocols such as GMPLS routing and 1411 signaling. Note that routing protocols can be used to convey both 1412 static and dynamic information. Static information currently 1413 conveyed includes items like router options and such. 1415 o Management protocols such as NetConf, SNMPv3, CLI, CORBA, or 1416 others. 1418 o Directory services and accompanying protocols. These are good for 1419 the dissemination of relatively static information. Not intended 1420 for dynamic information. 1422 o Other techniques for dynamic information: messaging straight from 1423 NEs to PCE to avoid flooding. This would be useful if the number 1424 of PCEs is significantly less than number of WSON NEs. Or other 1425 ways to limit flooding to "interested" NEs. 1427 Mechanisms to improve scaling of dynamic information: 1429 o Tailor message content to WSON. For example the use of wavelength 1430 ranges, or wavelength occupation bit maps. 1432 Utilize incremental updates if feasible. 1434 4.3. Lightpath Temporal Characteristics 1436 The temporal characteristics of a light path connection can affect 1437 the choice of solution to the RWA process. For our purposes here we 1438 look at the timeliness of connection establishment/teardown, and the 1439 duration of the connection. 1441 Connection Establishment/Teardown Timeliness can be thought of in 1442 approximately three time frames: 1444 1. Time Critical: For example those lightpath establishments used for 1445 restoration of service or other high priority real time service 1446 requests. 1448 2. Soft time bounds: This is a more typical new connection request. 1449 While expected to be responsive, there should be more time to take 1450 into account network optimization. 1452 3. Scheduled or Advanced reservations. Here lightpath connections are 1453 requested significantly ahead of their intended "in service" time. 1454 There is the potential for significant network optimization if 1455 multiple lightpaths can be computed concurrently to achieve network 1456 optimization objectives. 1458 Lightpath connection duration has typically been thought of as 1459 approximately three time frames: 1461 1. Dynamic: those lightpaths with relatively short duration (holding 1462 times). 1464 2. Pseudo-static: lightpaths with moderately long durations. 1466 3. Static: lightpaths with long durations. 1468 Different types of RWA algorithms have been developed for dealing 1469 with dynamic versus pseudo-static conditions. These can address 1470 service provider's needs for: (a) network optimization, (b) 1471 restoration, and (c) highly dynamic lightpath provisioning. 1473 Hence we can model timescale related lightpath requirements via the 1474 following notions: 1476 o Batch or Sequential light path connection requests 1478 o Timeliness of Connection establishment 1480 o Duration of lightpath connection 1482 5. Modeling Examples and Control Plane Use Cases 1484 This section provides examples of the fixed and switch optical node 1485 and wavelength constraint models of section 3. and WSON control plane 1486 use cases related to path computation, establishment, rerouting, and 1487 optimization. 1489 5.1. Network Modeling for GMPLS/PCE Control 1491 Consider a network containing three routers (R1 through R3), eight 1492 WSON nodes (N1 through N8) and 18 links (L1 through L18) and one OEO 1493 converter (O1) in a topology shown below. 1495 +--+ +--+ +--+ +--------+ 1496 +-L3-+N2+-L5-+ +--------L12--+N6+--L15--+ N8 +-- 1497 | +--+ |N4+-L8---+ +--+ ++--+---++ 1498 | | +-L9--+| | | | 1499 +--+ +-+-+ ++-+ || | L17 L18 1500 | ++-L1--+ | | ++++ +----L16---+ | | 1501 |R1| | N1| L7 |R2| | | | 1502 | ++-L2--+ | | ++-+ | ++---++ 1503 +--+ +-+-+ | | | + R3 | 1504 | +--+ ++-+ | | +-----+ 1505 +-L4-+N3+-L6-+N5+-L10-+ ++----+ 1506 +--+ | +--------L11--+ N7 +---- 1507 +--+ ++---++ 1508 | | 1509 L13 L14 1510 | | 1511 ++-+ | 1512 |O1+-+ 1513 +--+ 1514 5.1.1. Describing the WSON nodes 1516 The eight WSON nodes in this example have the following properties: 1518 o Nodes N1, N2, N3 have fixed OADMs (FOADMs) installed and can 1519 therefore only access a static and pre-defined set of wavelengths 1521 o All other nodes contain ROADMs and can therefore access all 1522 wavelengths. 1524 o Nodes N4, N5, N7 and N8 are multi-degree nodes, allowing any 1525 wavelength to be optically switched between any of the links. Note 1526 however, that this does not automatically apply to wavelengths 1527 that are being added or dropped at the particular node. 1529 o Node N4 is an exception to that: This node can switch any 1530 wavelength from its add/drop ports to any of its outgoing links 1531 (L5, L7 and L12 in this case) 1533 o The links from the routers are always only able to carry one 1534 wavelength with the exception of links L8 and L9 which are capable 1535 to add/drop any wavelength. 1537 o Node N7 contains an OEO transponder (O1) connected to the node via 1538 links L13 and L14. That transponder operates in 3R mode and does 1539 not change the wavelength of the signal. Assume that it can 1540 regenerate any of the client signals, however only for a specific 1541 wavelength. 1543 Given the above restrictions, the node information for the eight 1544 nodes can be expressed as follows: (where ID == identifier, SCM == 1545 switched connectivity matrix, and FCM == fixed connectivity matrix). 1547 +ID+SCM +FCM + 1548 | | |L1 |L2 |L3 |L4 | | |L1 |L2 |L3 |L4 | | 1549 | |L1 |0 |0 |0 |0 | |L1 |0 |0 |1 |0 | | 1550 |N1|L2 |0 |0 |0 |0 | |L2 |0 |0 |0 |1 | | 1551 | |L3 |0 |0 |0 |0 | |L3 |1 |0 |0 |1 | | 1552 | |L4 |0 |0 |0 |0 | |L4 |0 |1 |1 |0 | | 1553 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1554 | | |L3 |L5 | | | | |L3 |L5 | | | | 1555 |N2|L3 |0 |0 | | | |L3 |0 |1 | | | | 1556 | |L5 |0 |0 | | | |L5 |1 |0 | | | | 1557 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1558 | | |L4 |L6 | | | | |L4 |L6 | | | | 1559 |N3|L4 |0 |0 | | | |L4 |0 |1 | | | | 1560 | |L6 |0 |0 | | | |L6 |1 |0 | | | | 1561 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1562 | | |L5 |L7 |L8 |L9 |L12| |L5 |L7 |L8 |L9 |L12| 1563 | |L5 |0 |1 |1 |1 |1 |L5 |0 |0 |0 |0 |0 | 1564 |N4|L7 |1 |0 |1 |1 |1 |L7 |0 |0 |0 |0 |0 | 1565 | |L8 |1 |1 |0 |1 |1 |L8 |0 |0 |0 |0 |0 | 1566 | |L9 |1 |1 |1 |0 |1 |L9 |0 |0 |0 |0 |0 | 1567 | |L12|1 |1 |1 |1 |0 |L12|0 |0 |0 |0 |0 | 1568 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1569 | | |L6 |L7 |L10|L11| | |L6 |L7 |L10|L11| | 1570 | |L6 |0 |1 |0 |1 | |L6 |0 |0 |1 |0 | | 1571 |N5|L7 |1 |0 |0 |1 | |L7 |0 |0 |0 |0 | | 1572 | |L10|0 |0 |0 |0 | |L10|1 |0 |0 |0 | | 1573 | |L11|1 |1 |0 |0 | |L11|0 |0 |0 |0 | | 1574 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1575 | | |L12|L15| | | | |L12|L15| | | | 1576 |N6|L12|0 |1 | | | |L12|0 |0 | | | | 1577 | |L15|1 |0 | | | |L15|0 |0 | | | | 1578 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1579 | | |L11|L13|L14|L16| | |L11|L13|L14|L16| | 1580 | |L11|0 |1 |0 |1 | |L11|0 |0 |0 |0 | | 1581 |N7|L13|1 |0 |0 |0 | |L13|0 |0 |1 |0 | | 1582 | |L14|0 |0 |0 |1 | |L14|0 |1 |0 |0 | | 1583 | |L16|1 |0 |1 |0 | |L16|0 |0 |1 |0 | | 1584 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1585 | | |L15|L16|L17|L18| | |L15|L16|L17|L18| | 1586 | |L15|0 |1 |0 |0 | |L15|0 |0 |0 |1 | | 1587 |N8|L16|1 |0 |0 |0 | |L16|0 |0 |1 |0 | | 1588 | |L17|0 |0 |0 |0 | |L17|0 |1 |0 |0 | | 1589 | |L18|0 |0 |0 |0 | |L18|1 |0 |1 |0 | | 1590 +--+---+---+---+---+---+---+---+---+---+---+---+---+ 1592 5.1.2. Describing the links 1594 For the following discussion some simplifying assumptions are made: 1596 o It is assumed that the WSON node support a total of four 1597 wavelengths designated WL1 through WL4. 1599 o It is assumed that the impairment feasibility of a path or path 1600 segment is independent from the wavelength chosen. 1602 For the discussion of the RWA operation to build LSPs between two 1603 routers, the wavelength constraints on the links between the routers 1604 and the WSON nodes as well as the connectivity matrix of these links 1605 needs to be specified: 1607 +Link+WLs supported +Possible egress links+ 1608 | L1 | WL1 | L3 | 1609 +----+-----------------+---------------------+ 1610 | L2 | WL2 | L4 | 1611 +----+-----------------+---------------------+ 1612 | L8 | WL1 WL2 WL3 WL4 | L5 L7 L12 | 1613 +----+-----------------+---------------------+ 1614 | L9 | WL1 WL2 WL3 WL4 | L5 L7 L12 | 1615 +----+-----------------+---------------------+ 1616 | L10| WL2 | L6 | 1617 +----+-----------------+---------------------+ 1618 | L13| WL1 WL2 WL3 WL4 | L11 L14 | 1619 +----+-----------------+---------------------+ 1620 | L14| WL1 WL2 WL3 WL4 | L13 L16 | 1621 +----+-----------------+---------------------+ 1622 | L17| WL2 | L16 | 1623 +----+-----------------+---------------------+ 1624 | L18| WL1 | L15 | 1625 +----+-----------------+---------------------+ 1627 Note that the possible egress links for the links connecting to the 1628 routers is inferred from the Switched Connectivity Matrix and the 1629 Fixed Connectivity Matrix of the Nodes N1 through N8 and is show here 1630 for convenience, i.e., this information does not need to be repeated. 1632 5.2. RWA Path Computation and Establishment 1634 The calculation of optical impairment feasible routes is outside the 1635 scope of this framework document. In general impairment feasible 1636 routes serve as an input to the RWA algorithm. 1638 For the example use case shown here, assume the following feasible 1639 routes: 1641 +Endpoint 1+Endpoint 2+Feasible Route + 1642 | R1 | R2 | L1 L3 L5 L8 | 1643 | R1 | R2 | L1 L3 L5 L9 | 1644 | R1 | R2 | L2 L4 L6 L7 L8 | 1645 | R1 | R2 | L2 L4 L6 L7 L9 | 1646 | R1 | R2 | L2 L4 L6 L10 | 1647 | R1 | R3 | L1 L3 L5 L12 L15 L18 | 1648 | R1 | N7 | L2 L4 L6 L11 | 1649 | N7 | R3 | L16 L17 | 1650 | N7 | R2 | L16 L15 L12 L9 | 1651 | R2 | R3 | L8 L12 L15 L18 | 1652 | R2 | R3 | L8 L7 L11 L16 L17 | 1653 | R2 | R3 | L9 L12 L15 L18 | 1654 | R2 | R3 | L9 L7 L11 L16 L17 | 1656 Given a request to establish a LSP between R1 and R2 the RWA 1657 algorithm finds the following possible solutions: 1659 +WL + Path + 1660 | WL1| L1 L3 L5 L8 | 1661 | WL1| L1 L3 L5 L9 | 1662 | WL2| L2 L4 L6 L7 L8| 1663 | WL2| L2 L4 L6 L7 L9| 1664 | WL2| L2 L4 L6 L10 | 1666 Assume now that the RWA chooses WL1 and the Path L1 L3 L5 L8 for the 1667 requested LSP. 1669 Next, another LSP is signaled from R1 to R2. Given the established 1670 LSP using WL1, the following table shows the available paths: 1672 +WL + Path + 1673 | WL2| L2 L4 L6 L7 L9| 1674 | WL2| L2 L4 L6 L10 | 1676 Assume now that the RWA chooses WL2 and the path L2 L4 L6 L7 L9 for 1677 the establishment of the new LSP. 1679 Faced with another LSP request -this time from R2 to R3 - can not be 1680 fulfilled since the only four possible paths (starting at L8 and L9) 1681 are already in use. 1683 5.3. Resource Optimization 1685 The preceding example gives rise to another use case: The 1686 optimization of network resources. Optimization can be achieved on a 1687 number of layers (e.g. through electrical or optical multiplexing of 1688 client signals) or by re-optimizing the solutions found by the RWA 1689 algorithm. 1691 Given the above example again, assume that the RWA algorithm should 1692 find a path between R2 and R3. The only possible path to reach R3 1693 from R2 needs to use L9. L9 however is blocked by one of the LSPs 1694 from R1. 1696 5.4. Support for Rerouting 1698 It is also envisioned that the extensions to GMPLS and PCE support 1699 rerouting of wavelengths in case of failures. 1701 Assume for this discussion that the only two LSPs in use in the 1702 system are: 1704 LSP1: WL1 L1 L3 L5 L8 1706 LSP2: WL2 L2 L4 L6 L7 L9 1708 Assume furthermore that the link L5 fails. The RWA can now find the 1709 following alternate path and and establish that path: 1711 R1 -> N7 -> R2 1713 Level 3 regeneration will take place at N7, so that the complete path 1714 looks like this: 1716 R1 -> L2 L4 L6 L11 L13 -> O1 -> L14 L16 L15 L12 L9 -> R2 1718 5.5. Electro-Optical Networking Scenarios 1720 In the following we look at various networking scenarios involving 1721 regenerators, OEO switches and wavelength converters. We group these 1722 scenarios roughly by type and number of extensions to the GMPLS 1723 control plane that would be required. 1725 5.5.1. Fixed Regeneration Points 1727 In the simplest networking scenario involving regenerators, the 1728 regeneration is associated with a WDM link or entire node and is not 1729 optional, i.e., all signals traversing the link or node will be 1730 regenerated. This includes OEO switches since they provide 1731 regeneration on every port. 1733 There maybe input constraints and output constraints on the 1734 regenerators. Hence the path selection process will need to know from 1735 an IGP or other means the regenerator constraints so that it can 1736 choose a compatible path. For impairment aware routing and wavelength 1737 assignment (IA-RWA) the path selection process will also need to know 1738 which links/nodes provide regeneration. Even for "regular" RWA, this 1739 regeneration information is useful since wavelength converters 1740 typically perform regeneration and the wavelength continuity 1741 constraint can be relaxed at such a point. 1743 Signaling does not need to be enhanced to include this scenario since 1744 there are no reconfigurable regenerator options on input, output or 1745 with respect to processing. 1747 5.5.2. Shared Regeneration Pools 1749 In this scenario there are nodes with shared regenerator pools within 1750 the network in addition to fixed regenerators of the previous 1751 scenario. These regenerators are shared within a node and their 1752 application to a signal is optional. There are no reconfigurable 1753 options on either input or output. The only processing option is to 1754 "regenerate" a particular signal or not. 1756 Regenerator information in this case is used in path computation to 1757 select a path that ensures signal compatibility and IA-RWA criteria. 1759 To setup an LSP that utilizes a regenerator from a node with a shared 1760 regenerator pool we need to be able to indicate that regeneration is 1761 to take place at that particular node along the signal path. Such a 1762 capability currently does not exist in GMPLS signaling. 1764 5.5.3. Reconfigurable Regenerators 1766 In this scenario we have regenerators that require configuration 1767 prior to use on an optical signal. We discussed previously that this 1768 could be due to a regenerator that must be configured to accept 1769 signals with different characteristics, for regenerators with a 1770 selection of output attributes, or for regenerators with additional 1771 optional processing capabilities. 1773 As in the previous scenarios we will need information concerning 1774 regenerator properties for selection of compatible paths and for IA- 1775 RWA computations. In addition during LSP setup we need to be able 1776 configure regenerator options at a particular node along the path. 1777 Such a capability currently does not exist in GMPLS signaling. 1779 5.5.4. Relation to Translucent Networks 1781 In the literature, networks that contain both transparent network 1782 elements such as reconfigurable optical add drop multiplexers 1783 (ROADMs) and electro-optical network elements such regenerators or 1784 OEO switches are frequently referred to as Translucent optical 1785 networks [Trans07]. Earlier work suggesting GMPLS extensions for 1786 translucent optical networks can be found in [Yang05] while a more 1787 comprehensive evaluation of differing GMPLS control plane approaches 1788 to translucent networks can be found in [Sambo09]. 1790 Three main types of translucent optical networks have been discussed: 1792 4. Transparent "islands" surrounded by regenerators. This is 1793 frequently seen when transitioning from a metro optical sub- 1794 network to a long haul optical sub-network. 1796 5. Mostly transparent networks with a limited number of OEO 1797 ("opaque") nodes strategically placed. This takes advantage of the 1798 inherent regeneration capabilities of OEO switches. In the 1799 planning of such networks one has to determine the optimal 1800 placement of the OEO switches [Sen08]. 1802 6. Mostly transparent networks with a limited number of optical 1803 switching nodes with "shared regenerator pools" that can be 1804 optionally applied to signals passing through these switches. 1805 These switches are sometimes called translucent nodes. 1807 All three of these types of translucent networks fit within either 1808 the networking scenarios of sections 5.5.1. and 5.5.2. above. And 1809 hence, can be accommodated by the GMPLS extensions suggested in this 1810 document. 1812 6. GMPLS & PCE Implications 1814 The presence and amount of wavelength conversion available at a 1815 wavelength switching interface has an impact on the information that 1816 needs to be transferred by the control plane (GMPLS) and the PCE 1817 architecture. Current GMPLS and PCE standards can address the full 1818 wavelength conversion case so the following will only address the 1819 limited and no wavelength conversion cases. 1821 6.1. Implications for GMPLS signaling 1823 Basic support for WSON signaling already exists in GMPLS with the 1824 lambda (value 9) LSP encoding type [RFC3471], or for G.709 compatible 1825 optical channels, the LSP encoding type (value = 13) "G.709 Optical 1826 Channel" from [RFC4328]. However a number of practical issues arise 1827 in the identification of wavelengths and signals, and distributed 1828 wavelength assignment processes which are discussed below. 1830 6.1.1. Identifying Wavelengths and Signals 1832 As previously stated a global fixed mapping between wavelengths and 1833 labels simplifies the characterization of WDM links and WSON devices. 1834 Furthermore such a mapping as described in [Otani] eases 1835 communication between PCE and WSON PCCs. 1837 6.1.2. WSON Signals and Network Element Processing 1839 We saw in section 3.3.2. 3.3.2. that a WSON signal at any point along 1840 its path can be characterized by the (a) modulation format, (b) FEC, 1841 (c) wavelength, (d)bit rate, and (d)G-PID. 1843 Currently G-PID, wavelength (via labels), and bit rate (via bandwidth 1844 encoding) are supported in [RFC3471] and [RFC3473]. These RFCs can 1845 accommodate the wavelength changing at any node along the LSP and can 1846 thus provide explicit control of wavelength converters. 1848 In the fixed regeneration point scenario (section 5.5.1. ) no 1849 enhancements are required to signaling since there are no additional 1850 configuration options for the LSP at a node. 1852 In the case of shared regeneration pools (section 5.5.2. ) we need to 1853 be able to indicate to a node that it should perform regeneration on 1854 a particular signal. Viewed another way, for an LSP we want to 1855 specify that certain nodes along the path perform regeneration. Such 1856 a capability currently does not exist in GMPLS signaling. 1858 The case of configurable regenerators (section 5.5.3. ) is very 1859 similar to the previous except that now there are potentially many 1860 more items that we may want to configure on a per node basis for an 1861 LSP. 1863 Note that the techniques of [RFC5420] which allow for additional LSP 1864 attributes and their recording in an RRO object could be extended to 1865 allow for additional LSP attributes in an ERO. This could allow one 1866 to indicate where optional 3R regeneration should take place along a 1867 path, any modification of LSP attributes such as modulation format, 1868 or any enhance processing such as performance monitoring. 1870 6.1.3. Combined RWA/Separate Routing WA support 1872 In either the combined RWA or separate routing WA cases, the node 1873 initiating the signaling will have a route from the source to 1874 destination along with the wavelengths (generalized labels) to be 1875 used along portions of the path. Current GMPLS signaling supports an 1876 explicit route object (ERO) and within an ERO an ERO Label subobject 1877 can be use to indicate the wavelength to be used at a particular 1878 node. In case the local label map approach is used the label sub- 1879 object entry in the ERO has to be translated appropriately. 1881 6.1.4. Distributed Wavelength Assignment: Unidirectional, No 1882 Converters 1884 GMPLS signaling for a uni-directional lightpath LSP allows for the 1885 use of a label set object in the RSVP-TE path message. The processing 1886 of the label set object to take the intersection of available lambdas 1887 along a path can be performed resulting in the set of available 1888 lambda being known to the destination that can then use a wavelength 1889 selection algorithm to choose a lambda. For example, the following is 1890 a non-exhaustive subset of wavelength assignment (WA) approaches 1891 discussed in [HZang00]: 1893 1. Random: Looks at all available wavelengths for the light path then 1894 chooses from those available at random. 1896 2. First Fit: Wavelengths are ordered, first available (on all links) 1897 is chosen. 1899 3. Most Used: Out of the wavelengths available on the path attempts 1900 to select most use wavelength in network. 1902 4. Least Loaded: For multi-fiber networks. Chooses the wavelength j 1903 that maximizes minimum of the difference between the number of 1904 fibers on link l and the number of fibers on link l with 1905 wavelength j occupied. 1907 As can be seen from the above short list, wavelength assignment 1908 methods have differing information or processing requirements. The 1909 information requirements of these methods are as follows: 1911 1. Random: nothing more than the available wavelength set. 1913 2. First Fit: nothing more than the available wavelength set. 1915 3. Most Used: the available wavelength set and information on global 1916 wavelength use in the network. 1918 4. Least Loaded: the available wavelength set and information 1919 concerning the wavelength dependent loading for each link (this 1920 applies to multi-fiber links). This could be obtained via global 1921 information or via supplemental information passed via the 1922 signaling protocol. 1924 In case (3) above the global information needed by the wavelength 1925 assignment could be derived from suitably enhanced GMPLS routing. 1927 Note however this information need not be accurate enough for 1928 combined RWA computation. GMPLS signaling does not provide a way to 1929 indicate that a particular wavelength assignment algorithm should be 1930 used. 1932 6.1.5. Distributed Wavelength Assignment: Unidirectional, Limited 1933 Converters 1935 The previous outlined the case with no wavelength converters. In the 1936 case of wavelength converters, nodes with wavelength converters would 1937 need to make the decision as to whether to perform conversion. One 1938 indicator for this would be that the set of available wavelengths 1939 which is obtained via the intersection of the incoming label set and 1940 the egress links available wavelengths is either null or deemed too 1941 small to permit successful completion. 1943 At this point the node would need to remember that it will apply 1944 wavelength conversion and will be responsible for assigning the 1945 wavelength on the previous lambda-contiguous segment when the RSVP-TE 1946 RESV message passes by. The node will pass on an enlarged label set 1947 reflecting only the limitations of the wavelength converter and the 1948 egress link. The record route option in RVSP-TE signaling can be used 1949 to show where wavelength conversion has taken place. 1951 6.1.6. Distributed Wavelength Assignment: Bidirectional, No 1952 Converters 1954 There are potential issues in the case of a bi-directional lightpath 1955 which requires the use of the same lambda in both directions. We can 1956 try to use the above procedure to determine the available 1957 bidirectional lambda set if we use the interpretation that the 1958 available label set is available in both directions. However, a 1959 problem, arises in that bidirectional LSPs setup, according to 1960 [RFC3471] section 4.1, is indicated by the presence of an upstream 1961 label in the path message. 1963 However, until the intersection of the available label sets is 1964 obtained, e.g., at the destination node and the wavelength assignment 1965 algorithm has been run the upstream label information will not be 1966 available. Hence currently distributed wavelength assignment with 1967 bidirectional lightpaths is not supported. 1969 6.2. Implications for GMPLS Routing 1971 GMPLS routing [RFC4202] currently defines an interface capability 1972 descriptor for "lambda switch capable" (LSC) which we can use to 1973 describe the interfaces on a ROADM or other type of wavelength 1974 selective switch. In addition to the topology information typically 1975 conveyed via an IGP, we would need to convey the following subsystem 1976 properties to minimally characterize a WSON: 1978 1. WDM Link properties (allowed wavelengths). 1980 2. Laser Transmitters (wavelength range). 1982 3. ROADM/FOADM properties (connectivity matrix, port wavelength 1983 restrictions). 1985 4. Wavelength Converter properties (per network element, may change if 1986 a common limited shared pool is used). 1988 This information is modeled in detail in [WSON-Info] and a compact 1989 encoding is given in [WSON-Encode]. 1991 6.2.1. Electro-Optical Element Signal Compatibility 1993 In network scenarios where signal compatibility is a concern we need 1994 to add parameters to our existing node and link models to take into 1995 account electro-optical input constraints, output constraints, and 1996 the signal processing capabilities of a NE in path computations. 1998 Input Constraints: 2000 1. Permitted optical tributary signal classes: A list of optical 2001 tributary signal classes that can be processed by this network 2002 element or carried over this link. [configuration type] 2003 2. Acceptable FEC codes [configuration type] 2004 3. Acceptable Bit Rate Set: A list of specific bit rates or bit rate 2005 ranges that the device can accommodate. Coarse bit rate info is 2006 included with the optical tributary signal class restrictions. 2007 4. Acceptable G-PID list: A list of G-PIDs corresponding to the 2008 "client" digital streams that is compatible with this device. 2010 Note that since the bit rate of the signal does not change over the 2011 LSP. We can make this an LSP parameter and hence this information 2012 would be available for any NE that needs to use it for configuration. 2013 Hence we do not need "configuration type" for the NE with respect to 2014 bit rate. 2016 Output Constraints: 2018 1. Output modulation: (a)same as input, (b) list of available types 2019 2. FEC options: (a) same as input, (b) list of available codes 2021 Processing Capabilities: 2023 1. Regeneration: (a) 1R, (b) 2R, (c) 3R, (d)list of selectable 2024 regeneration types 2026 2. Fault and Performance Monitoring (a)GPID particular capabilities 2027 TBD, (b) optical performance monitoring capabilities TBD. 2029 Note that such parameters could be specified on an (a) Network 2030 element wide basis, (b) a per port basis, (c) on a per regenerator 2031 basis. Typically such information has been on a per port basis, 2032 e.g., the GMPLS interface switching capability descriptor [RFC4202]. 2034 6.2.2. Wavelength-Specific Availability Information 2036 For wavelength assignment we need to know which specific wavelengths 2037 are available and which are occupied if we are going to run a 2038 combined RWA process or separate WA process as discussed in sections 2039 4.1.1. 4.1.2. This is currently not possible with GMPLS routing 2040 extensions. 2042 In the routing extensions for GMPLS [RFC4202], requirements for 2043 layer-specific TE attributes are discussed. The RWA problem for 2044 optical networks without wavelength converters imposes an additional 2045 requirement for the lambda (or optical channel) layer: that of 2046 knowing which specific wavelengths are in use. Note that current 2047 dense WDM (DWDM) systems range from 16 channels to 128 channels with 2048 advanced laboratory systems with as many as 300 channels. Given these 2049 channel limitations and if we take the approach of a global 2050 wavelength to label mapping or furnishing the local mappings to the 2051 PCEs then representing the use of wavelengths via a simple bit-map is 2052 feasible [WSON-Encode]. 2054 6.2.3. WSON Routing Information Summary 2056 The following table summarizes the WSON information that could be 2057 conveyed via GMPLS routing and attempts to classify that information 2058 as to its static or dynamic nature and whether that information would 2059 tend to be associated with either a link or a node. 2061 Information Static/Dynamic Node/Link 2062 ------------------------------------------------------------------ 2063 Connectivity matrix Static Node 2064 Per port wavelength restrictions Static Node(1) 2065 WDM link (fiber) lambda ranges Static Link 2066 WDM link channel spacing Static Link 2067 Laser Transmitter range Static Link(2) 2068 Wavelength conversion capabilities Static(3) Node 2069 Maximum bandwidth per Wavelength Static Link 2070 Wavelength Availability Dynamic(4) Link 2071 Signal Compatibility & Processing Static/Dynamic Node 2073 Notes: 2075 1. These are the per port wavelength restrictions of an optical 2076 device such as a ROADM and are independent of any optical 2077 constraints imposed by a fiber link. 2079 2. This could also be viewed as a node capability. 2081 3. This could be dynamic in the case of a limited pool of converters 2082 where the number available can change with connection 2083 establishment. Note we may want to include regeneration 2084 capabilities here since OEO converters are also regenerators. 2086 4. Not necessarily needed in the case of distributed wavelength 2087 assignment via signaling. 2089 While the full complement of the information from the previous table 2090 is needed in the Combined RWA and the separate Routing and WA 2091 architectures, in the case of Routing + distribute WA via signaling 2092 we only need the following information: 2094 Information Static/Dynamic Node/Link 2095 ------------------------------------------------------------------ 2096 Connectivity matrix Static Node 2097 Wavelength conversion capabilities Static(3) Node 2099 Information models and compact encodings for this information is 2100 provided in [WSON-Info] and [WSON-Encode]. 2102 6.3. Optical Path Computation and Implications for PCE 2104 As previously noted the RWA problem can be computationally intensive 2105 [HZang00]. Such computationally intensive path computations and 2106 optimizations were part of the impetus for the PCE (path computation 2107 element) architecture. 2109 As the PCEP defines the procedures necessary to support both 2110 sequential [RFC5440] and global concurrent path computations 2111 [RFC5557], PCE is well positioned to support WSON-enabled RWA 2112 computation with some protocol enhancement. 2114 Implications for PCE generally fall into two main categories: (a) 2115 lightpath constraints and characteristics, (b) computation 2116 architectures. 2118 6.3.1. Lightpath Constraints and Characteristics 2120 For the varying degrees of optimization that may be encountered in a 2121 network the following models of bulk and sequential lightpath 2122 requests are encountered: 2124 o Batch optimization, multiple lightpaths requested at one time. 2126 o Lightpath(s) and backup lightpath(s) requested at one time. 2128 o Single lightpath requested at a time. 2130 PCEP and PCE-GCO can be readily enhanced to support all of the 2131 potential models of RWA computation. 2133 Lightpath constraints include: 2135 o Bidirectional Assignment of wavelengths 2137 o Possible simultaneous assignment of wavelength to primary and 2138 backup paths. 2140 o Tuning range constraint on optical transmitter. 2142 Lightpath characteristics can include: 2144 o Duration information (how long this connection may last) 2146 o Timeliness/Urgency information (how quickly is this connection 2147 needed) 2148 6.3.2. Electro-Optical Element Signal Compatibility 2150 When requesting a path computation to PCE, the PCC should be able to 2151 indicate the following: 2153 o The GPID type of an LSP 2155 o The signal attributes at the transmitter (at the source): (i) 2156 modulation type; (ii) FEC type 2158 o The signal attributes at the receiver (at the sink): (i) 2159 modulation type; (ii) FEC type 2161 The PCE should be able to respond to the PCC with the following: 2163 o The conformity of the requested optical characteristics associated 2164 with the resulting LSP with the source, sink and NE along the LSP. 2166 o Additional LSP attributes modified along the path (e.g., 2167 modulation format change, etc.) 2169 6.3.3. Discovery of RWA Capable PCEs 2171 The algorithms and network information needed for solving the RWA are 2172 somewhat specialized and computationally intensive hence not all PCEs 2173 within a domain would necessarily need or want this capability. 2174 Hence, it would be useful via the mechanisms being established for 2175 PCE discovery [RFC5088] to indicate that a PCE has the ability to 2176 deal with the RWA problem. Reference [RFC5088] indicates that a sub- 2177 TLV could be allocated for this purpose. 2179 Recent progress on objective functions in PCE [RFC5541] would allow 2180 the operators to flexibly request differing objective functions per 2181 their need and applications. For instance, this would allow the 2182 operator to choose an objective function that minimizes the total 2183 network cost associated with setting up a set of paths concurrently. 2184 This would also allow operators to choose an objective function that 2185 results in a most evenly distributed link utilization. 2187 This implies that PCEP would easily accommodate wavelength selection 2188 algorithm in its objective function to be able to optimize the path 2189 computation from the perspective of wavelength assignment if chosen 2190 by the operators. 2192 6.4. Summary of Impacts by RWA Architecture 2194 The following table summarizes for each RWA strategy the list of 2195 mandatory ("M") and optional ("O") control plane features according 2196 to GMPLS architectural blocks: 2198 o Information required by the path computation entity, 2200 o LSP request parameters used in either PCC to PCE situations or in 2201 signaling, 2203 o RSVP-TE LSP signaling parameters used in LSP establishment. 2205 The table shows which enhancements are common to all architectures 2206 (R&WA, R+WA, R+DWA), which apply only to R&WA and R+WA (R+&WA), and 2207 which apply only to R+DWA. Note that this summary serves for the 2208 purpose of a generic reference. 2210 +-------------------------------------+-----+-------+-------+-------+ 2211 | | |Common | R+&WA | R+DWA | 2212 | Feature | ref +---+---+---+---+---+---+ 2213 | | | M | O | M | O | M | O | 2214 +-------------------------------------+-----+---+---+---+---+---+---+ 2215 | Generalized Label for Wavelength |5.1.1| x | | | | | | 2216 +-------------------------------------+-----+---+---+---+---+---+---+ 2217 | Flooding of information for the | | | | | | | | 2218 | routing phase | | | | | | | | 2219 | Node features | 3.3 | | | | | | | 2220 | Node type | | | x | | | | | 2221 | spectral X-connect constraint | | | | x | | | | 2222 | port X-connect constraint | | | | x | | | | 2223 | Transponders availability | | | x | | | | | 2224 | Transponders features | 3.2 | | x | | | | | 2225 | Converter availability | | | | x | | | | 2226 | Converter features | 3.4 | | | x | | | x | 2227 | TE-parameters of WDM links | 3.1 | x | | | | | | 2228 | Total Number of wavelength | | x | | | | | | 2229 | Number of wavelengths available | | x | | | | | | 2230 | Grid spacing | | x | | | | | | 2231 | Wavelength availability on links | 5.2 | | | x | | | | 2232 +-------------------------------------+-----+---+---+---+---+---+---+ 2233 | LSP request parameters | | | | | | | | 2234 | Signal features | 5.1 | | x | | | x | | 2235 | Modulation format | | | x | | | x | | 2236 | Modulation parameters | | | x | | | x | | 2237 | Specification of RWA method | 5.1 | | x | | | x | | 2238 | LSP time features | 4.3 | | x | | | | | 2239 +-------------------------------------+-----+---+---+---+---+---+---+ 2240 | Enriching signaling messages | | | | | | | | 2241 | Signal features | 5.1 | | | | | x | | 2242 +-------------------------------------+-----+---+---+---+---+---+---+ 2244 7. Security Considerations 2246 This document has no requirement for a change to the security models 2247 within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, 2248 and PCEP security models could be operated unchanged. 2250 However satisfying the requirements for RWA using the existing 2251 protocols may significantly affect the loading of those protocols. 2252 This makes the operation of the network more vulnerable to denial of 2253 service attacks. Therefore additional care maybe required to ensure 2254 that the protocols are secure in the WSON environment. 2256 Furthermore the additional information distributed in order to 2257 address the RWA problem represents a disclosure of network 2258 capabilities that an operator may wish to keep private. Consideration 2259 should be given to securing this information. 2261 8. IANA Considerations 2263 This document makes no request for IANA actions. 2265 9. Acknowledgments 2267 The authors would like to thank Adrian Farrel for many helpful 2268 comments that greatly improved the contents of this draft. 2270 This document was prepared using 2-Word-v2.0.template.dot. 2272 10. References 2274 10.1. Normative References 2276 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 2277 (GMPLS) Signaling Functional Description", RFC 3471, 2278 January 2003. 2280 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2281 (TE) Extensions to OSPF Version 2", RFC 3630, September 2282 2003. 2284 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 2285 (GMPLS) Architecture", RFC 3945, October 2004. 2287 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 2288 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 2290 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support 2291 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 2292 4202, October 2005. 2294 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 2295 Switching (GMPLS) Signaling Extensions for G.709 Optical 2296 Transport Networks Control", RFC 4328, January 2006. 2298 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 2299 applications: DWDM frequency grid", June, 2002. 2301 [RFC5088] J.L. Le Roux, J.P. Vasseur, Yuichi Ikejiri, and Raymond 2302 Zhang, "OSPF protocol extensions for Path Computation 2303 Element (PCE) Discovery", January 2008. 2305 [RFC5557] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path 2306 Computation Element Communication Protocol (PCECP) 2307 Requirements and Protocol Extensions In Support of Global 2308 Concurrent Optimization", RFC 5557, July 2009. 2310 [RFC5440] J.P. Vasseur and J.L. Le Roux (Editors), "Path Computation 2311 Element (PCE) Communication Protocol (PCEP)", RFC 5440, May 2312 2009. 2314 [RFC5541] J.L. Le Roux, J.P. Vasseur, and Y. Lee, "Encoding of 2315 Objective Functions in Path Computation Element (PCE) 2316 communication and discovery protocols", RFC 5541, July 2317 2009. 2319 [WSON-Compat] G. Bernstein, Y. Lee, B. Mack-Crane, "WSON Signal 2320 Characteristics and Network Element Compatibility 2321 Constraints for GMPLS", draft-bernstein-ccamp-wson- 2322 compatibility, work in progress. 2324 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, and W. Imajuku, "Routing 2325 and Wavelength Assignment Information Encoding for 2326 Wavelength Switched Optical Networks", draft-bernstein- 2327 ccamp-wson-encode, work in progress. 2329 [WSON-Imp] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework 2330 for the Control of Wavelength Switched Optical Networks 2331 (WSON) with Impairments", draft-ietf-ccamp-wson- 2332 impairments, work in progress. 2334 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 2335 Wavelength Assignment Information for Wavelength Switched 2336 Optical Networks", draft-bernstein-ccamp-wson-info, work in 2337 progress 2339 [PCEP-RWA] Y. Lee, G. Bernstein, J. Martensson, T. Takeda, T. Otani, 2340 "PCEP Requirements for WSON Routing and Wavelength 2341 Assignment", draft-lee-pce-wson-routing-wavelength, work in 2342 progress. 2344 10.2. Informative References 2346 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and 2347 wavelength assignment approaches for wavelength-routed 2348 optical WDM networks", Optical Networks Magazine, January 2349 2000. 2351 [Coldren04] Larry A. Coldren, G. A. Fish, Y. Akulova, J. S. 2352 Barton, L. Johansson and C. W. Coldren, "Tunable 2353 Seiconductor Lasers: A Tutorial", Journal of Lightwave 2354 Technology, vol. 22, no. 1, pp. 193-202, January 2004. 2356 [Chu03] Xiaowen Chu, Bo Li and Chlamtac I, "Wavelength converter 2357 placement under different RWA algorithms in wavelength- 2358 routed all-optical networks", IEEE Transactions on 2359 Communications, vol. 51, no. 4, pp. 607-617, April 2003. 2361 [Buus06] Jens Buus EJM, "Tunable Lasers in Optical Networks", 2362 Journal of Lightware Technology, vol. 24, no. 1, pp. 5-11, 2363 January 2006. 2365 [Basch06] E. Bert Bash, Roman Egorov, Steven Gringeri and Stuart 2366 Elby, "Architectural Tradeoffs for Reconfigurable Dense 2367 Wavelength-Division Multiplexing Systems", IEEE Journal of 2368 Selected Topics in Quantum Electronics, vol. 12, no. 4, pp. 2369 615-626, July/August 2006. 2371 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 2372 Labels of Lambda-Switching Capable Label Switching Routers 2373 (LSR)", work in progress: draft-otani-ccamp-gmpls-g-694- 2374 lambda-labels, work in progress. 2376 [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced 2377 Optical Modulation Formats", Proceedings of the IEEE, vol. 2378 94, no. 5, pp. 952-985, May 2006. 2380 [G.652] ITU-T Recommendation G.652, Characteristics of a single-mode 2381 optical fibre and cable, June 2005. 2383 [G.653] ITU-T Recommendation G.653, Characteristics of a dispersion- 2384 shifted single-mode optical fibre and cable, December 2006. 2386 [G.654] ITU-T Recommendation G.654, Characteristics of a cut-off 2387 shifted single-mode optical fibre and cable, December 2006. 2389 [G.655] ITU-T Recommendation G.655, Characteristics of a non-zero 2390 dispersion-shifted single-mode optical fibre and cable, 2391 March 2006. 2393 [G.656] ITU-T Recommendation G.656, Characteristics of a fibre and 2394 cable with non-zero dispersion for wideband optical 2395 transport, December 2006. 2397 [G.671] ITU-T Recommendation G.671, Transmission characteristics of 2398 optical components and subsystems, January 2005. 2400 [G.872] ITU-T Recommendation G.872, Architecture of optical 2401 transport networks, November 2001. 2403 [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network 2404 Physical Layer Interfaces, March 2006. 2406 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 2407 applications: DWDM frequency grid, June 2002. 2409 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 2410 applications: CWDM wavelength grid, December 2003. 2412 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and 2413 engineering considerations, February 2006. 2415 [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R 2416 in optical transport networks (OTN), November 2006. 2418 [Imajuku] W. Imajuku, Y. Sone, I. Nishioka, S. Seno, "Routing 2419 Extensions to Support Network Elements with Switching 2420 Constraint", work in progress: draft-imajuku-ccamp-rtg- 2421 switching-constraint-02.txt, July 2007. 2423 [Ozdaglar03] Asuman E. Ozdaglar and Dimitri P. Bertsekas, "Routing 2424 and wavelength assignment in optical networks," IEEE/ACM 2425 Transactions on Networking, vol. 11, 2003, pp. 259 -272. 2427 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 2428 on Optical Layer Routing", RFC 4054, May 2005. 2430 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 2431 Protocol Label Switching (GMPLS) Extensions for Synchronous 2432 Optical Network (SONET) and Synchronous Digital Hierarchy 2433 (SDH) Control", RFC 4606, August 2006. 2435 11. Contributors 2437 Snigdho Bardalai 2438 Fujitsu 2439 Email: Snigdho.Bardalai@us.fujitsu.com 2441 Diego Caviglia 2442 Ericsson 2443 Via A. Negrone 1/A 16153 2444 Genoa Italy 2446 Phone: +39 010 600 3736 2447 Email: diego.caviglia@(marconi.com, ericsson.com) 2449 Daniel King 2450 Old Dog Consulting 2451 UK 2452 Aria Networks 2453 Email: daniel@olddog.co.uk 2455 Itaru Nishioka 2456 NEC Corp. 2457 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 2458 Japan 2459 Phone: +81 44 396 3287 2460 Email: i-nishioka@cb.jp.nec.com 2462 Lyndon Ong 2463 Ciena 2464 Email: Lyong@Ciena.com 2466 Pierre Peloso 2467 Alcatel-Lucent 2468 Route de Villejust - 91620 Nozay - France 2469 Email: pierre.peloso@alcatel-lucent.fr 2471 Jonathan Sadler 2472 Tellabs 2473 Email: Jonathan.Sadler@tellabs.com 2475 Dirk Schroetter 2476 Cisco 2477 Email: dschroet@cisco.com 2479 Jonas Martensson 2480 Acreo 2481 Electrum 236 2482 16440 Kista, Sweden 2483 Email:Jonas.Martensson@acreo.se 2485 Author's Addresses 2487 Greg M. Bernstein (ed.) 2488 Grotto Networking 2489 Fremont California, USA 2491 Phone: (510) 573-2237 2492 Email: gregb@grotto-networking.com 2494 Young Lee (ed.) 2495 Huawei Technologies 2496 1700 Alma Drive, Suite 100 2497 Plano, TX 75075 2498 USA 2500 Phone: (972) 509-5599 (x2240) 2501 Email: ylee@huawei.com 2503 Wataru Imajuku 2504 NTT Network Innovation Labs 2505 1-1 Hikari-no-oka, Yokosuka, Kanagawa 2506 Japan 2508 Phone: +81-(46) 859-4315 2509 Email: imajuku.wataru@lab.ntt.co.jp 2511 Intellectual Property Statement 2513 The IETF Trust takes no position regarding the validity or scope of 2514 any Intellectual Property Rights or other rights that might be 2515 claimed to pertain to the implementation or use of the technology 2516 described in any IETF Document or the extent to which any license 2517 under such rights might or might not be available; nor does it 2518 represent that it has made any independent effort to identify any 2519 such rights. 2521 Copies of Intellectual Property disclosures made to the IETF 2522 Secretariat and any assurances of licenses to be made available, or 2523 the result of an attempt made to obtain a general license or 2524 permission for the use of such proprietary rights by implementers or 2525 users of this specification can be obtained from the IETF on-line IPR 2526 repository at http://www.ietf.org/ipr 2528 The IETF invites any interested party to bring to its attention any 2529 copyrights, patents or patent applications, or other proprietary 2530 rights that may cover technology that may be required to implement 2531 any standard or specification contained in an IETF Document. Please 2532 address the information to the IETF at ietf-ipr@ietf.org. 2534 Disclaimer of Validity 2536 All IETF Documents and the information contained therein are provided 2537 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2538 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2539 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2540 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2541 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 2542 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2543 FOR A PARTICULAR PURPOSE. 2545 Acknowledgment 2547 Funding for the RFC Editor function is currently provided by the 2548 Internet Society.