idnits 2.17.1 draft-bernstein-ccamp-wavelength-switched-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1476. 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 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2008) is 5904 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC4203' is defined on line 1280, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-pce-global-concurrent-optimization-01 == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-10 == Outdated reference: A later version (-06) exists of draft-ietf-pce-of-01 == Outdated reference: A later version (-03) exists of draft-bernstein-ccamp-wson-info-02 == Outdated reference: A later version (-02) exists of draft-otani-ccamp-gmpls-lambda-labels-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein (ed.) 2 Internet Draft Grotto Networking 3 Intended status: Informational Y. Lee (ed.) 4 Expires: August 2008 Huawei 5 Wataru Imajuku 6 NTT 8 February 19, 2008 10 Framework for GMPLS and PCE Control of Wavelength Switched Optical 11 Networks 12 draft-bernstein-ccamp-wavelength-switched-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on August 19, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 45 This memo provides a framework for applying Generalized Multi- 46 Protocol Label Switching (GMPLS) and the Path Computation Element 47 (PCE) architecture to the control of wavelength switched optical 48 networks (WSON). In particular we provide control plane models for 49 key wavelength switched optical network subsystems and processes. The 50 subsystems include wavelength division multiplexed links, tunable 51 laser transmitters, reconfigurable optical add/drop multiplexers 52 (ROADM) and wavelength converters. 54 Lightpath provisioning, in general, requires the routing and 55 wavelength assignment (RWA) process. This process is reviewed and the 56 information requirements, both static and dynamic for this process 57 are presented, along with alternative implementation scenarios that 58 could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. 59 This memo does NOT address optical impairments in any depth and 60 focuses on topological elements and path selection constraints that 61 are common across different WSON environments. It is expected that a 62 variety of different techniques will be applied to optical 63 impairments depending on the type of WSON, such as access, metro or 64 long haul. 66 Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC-2119 [RFC2119]. 72 Table of Contents 74 1. Introduction...................................................3 75 2. Terminology....................................................4 76 3. Wavelength Switched Optical Networks...........................5 77 3.1. WDM and CWDM Links........................................5 78 3.2. Optical Transmitters......................................7 79 3.2.1. Lasers...............................................7 80 3.2.2. Spectral Characteristics & Modulation Type...........8 81 3.2.3. Signal Rates and Error Correction....................9 82 3.3. ROADMs, OXCs, Splitters, Combiners and FOADMs............10 83 3.3.1. Reconfigurable Add/Drop Multiplexers and OXCs.......10 84 3.3.2. Splitters...........................................11 85 3.3.3. Combiners...........................................12 86 3.3.4. Fixed Optical Add/Drop Multiplexers.................12 87 3.4. Wavelength Converters....................................13 88 4. Routing and Wavelength Assignment.............................15 89 4.1. Lightpath Temporal Characteristics.......................16 90 4.2. RWA Algorithmic Approaches: Combined vs. Two-step........17 91 4.3. RWA Computation Architectures............................17 92 4.4. Conveying information needed by RWA......................18 93 5. GMPLS & PCE Implications......................................19 94 5.1. Implications for GMPLS signaling.........................19 95 5.1.1. Identifying Wavelengths and Signals.................19 96 5.1.2. Combined RWA/Separate Routing WA support............20 97 5.1.3. Distributed Wavelength Assignment: Unidirectional, No 98 Converters.................................................20 99 5.1.4. Distributed Wavelength Assignment: Unidirectional, 100 Limited Converters.........................................21 101 5.1.5. Distributed Wavelength Assignment: Bidirectional, No 102 Converters.................................................21 103 5.2. Implications for GMPLS Routing...........................21 104 5.2.1. Need for Wavelength-Specific Maximum Bandwidth 105 Information................................................22 106 5.2.2. Need for Wavelength-Specific Availability Information22 107 5.2.3. Relationship to Link Bundling and Layering..........23 108 5.2.4. WSON Routing Information Summary....................23 109 5.3. Optical Path Computation and Implications for PCE........25 110 5.3.1. Lightpath Constraints and Characteristics...........25 111 5.3.2. Computation Architecture Implications...............26 112 5.3.3. Discovery of RWA Capable PCEs.......................26 113 5.4. Scaling Implications.....................................26 114 5.4.1. Routing.............................................27 115 5.4.2. Signaling...........................................27 116 5.4.3. Path computation....................................27 117 6. Security Considerations.......................................27 118 7. IANA Considerations...........................................27 119 8. Acknowledgments...............................................27 120 9. References....................................................29 121 9.1. Normative References.....................................29 122 9.2. Informative References...................................30 123 10. Contributors.................................................32 124 Author's Addresses...............................................32 125 Intellectual Property Statement..................................33 126 Disclaimer of Validity...........................................34 128 1. Introduction 130 From its beginning Generalized Multi-Protocol Label Switching (GMPLS) 131 was intended to control wavelength switched optical networks (WSON) 132 with the GMPLS architecture document [RFC3945] explicitly mentioning 133 both wavelength and waveband switching and equating wavelengths 134 (lambdas) with GMPLS labels. In addition a discussion of optical 135 impairments and other constraints on optical routing can be found in 136 [RFC4054]. However, optical technologies have advanced in ways that 137 make them significantly different from other circuit switched 138 technologies such as Time Division Multiplexing (TDM). Service 139 providers have already deployed many of these new optical 140 technologies such as ROADMs and tunable lasers and desire the same 141 automation and restoration capabilities that GMPLS has provided to 142 TDM and packet switched networks. Another important application of an 143 automated control plane such as GMPLS is the possibility to improve, 144 via recovery schemes, the availability of the network. One of the 145 key points of GMPLS based recovery schemes is the capability to 146 survive multiple failures while legacy protection mechanism such as 147 1+1 path protection can survive to a single failure. Moreover this 148 improved availability can be obtained using less network resources. 150 This document will focus on the unique properties of links, switches 151 and path selection constraints that occur in WSONs. Different WSONs 152 such as access, metro and long haul may apply different techniques 153 for dealing with optical impairments hence this document will NOT 154 address optical impairments in any depth, but instead focus on 155 properties that are common across a variety of WSONs. 157 This memo provides a framework for applying GMPLS and the Path 158 Computation Element (PCE) architecture to the control of WSONs. In 159 particular we provide control plane models for key wavelength 160 switched optical network subsystems and processes. The subsystems 161 include wavelength division multiplexed links, tunable laser 162 transmitters, reconfigurable optical add/drop multiplexers (ROADM) 163 and wavelength converters. 165 Lightpath provisioning, in general, requires the routing and 166 wavelength assignment (RWA) process. This process is reviewed and the 167 information requirements, both static and dynamic for this process 168 are presented, along with alternative implementation architectures 169 that could be realized via various combinations of extended GMPLS and 170 PCE protocols. 172 2. Terminology 174 CWDM: Coarse Wavelength Division Multiplexing. 176 DWDM: Dense Wavelength Division Multiplexing. 178 FOADM: Fixed Optical Add/Drop Multiplexer. 180 OXC: Optical cross connect. A symmetric optical switching element in 181 which a signal on any ingress port can reach any egress port. 183 ROADM: Reconfigurable Optical Add/Drop Multiplexer. An asymmetric 184 wavelength selective switching element featuring ingress and egress 185 line side ports as well as add/drop side ports. 187 RWA: Routing and Wavelength Assignment. 189 Wavelength Conversion/Converters: The process of converting an 190 information bearing optical signal centered at a given wavelength to 191 one with "equivalent" content centered at a different wavelength. 192 Wavelength conversion can be implemented via an optical-electronic- 193 optical (OEO) process or via a strictly optical process. 195 WDM: Wavelength Division Multiplexing. 197 Wavelength Switched Optical Networks (WSON): WDM based optical 198 networks in which switching is performed selectively based on the 199 center wavelength of an optical signal. 201 3. Wavelength Switched Optical Networks 203 WSONs come in a variety of shapes and sizes from continent spanning 204 long haul networks, to metropolitan networks, to residential access 205 networks. In all these cases we are concerned with those properties 206 that constrain the choice of wavelengths that can be used, i.e., 207 restrict the wavelength label set, impact the path selection process, 208 and limit the topological connectivity. To do so we will examine and 209 model some major subsystems of a WSON: WDM links, Optical 210 Transmitters, ROADMs, and Wavelength Converters. 212 3.1. WDM and CWDM Links 214 WDM and CWDM links run over optical fibers, and optical fibers come 215 in a wide range of types that tend to be optimized for various 216 applications from access networks, metro, long haul, and submarine 217 links to name a few. ITU-T and IEC standards exist for various types 218 of fibers. For the purposes here we are concerned only with single 219 mode fibers (SMF). The following SMF fiber types are typically 220 encountered in optical networks: 222 ITU-T Standard | Common Name 223 ------------------------------------------------------------ 224 G.652 [G.652] | Standard SMF | 225 G.653 [G.653] | Dispersion shifted SMF | 226 G.654 [G.654] | Cut-off shifted SMF | 227 G.655 [G.655] | Non-zero dispersion shifted SMF | 228 G.656 [G.656] | Wideband non-zero dispersion shifted SMF | 229 ------------------------------------------------------------ 230 These fiber types are differentiated by their optical impairment 231 characteristics such as attenuation, chromatic dispersion, 232 polarization mode dispersion, four wave mixing, etc. Since these 233 effects can be dependent upon wavelength, channel spacing and input 234 power level, the net effect for our modeling purposes here is to 235 restrict the range of wavelengths that can be used. 237 Typically WDM links operate in one or more of the approximately 238 defined optical bands [G.Sup39]: 240 Band Range (nm) Common Name Raw Bandwidth (THz) 241 O-band 1260-1360 Original 17.5 242 E-band 1360-1460 Extended 15.1 243 S-band 1460-1530 Short 9.4 244 C-band 1530-1565 Conventional 4.4 245 L-band 1565-1625 Long 7.1 246 U-band 1625-1675 Ultra-long 5.5 248 Not all of a band may be usable, for example in many fibers that 249 support E-band there is significant attenuation due to a water 250 absorption peak at 1383nm. Hence we can have a discontinuous 251 acceptable wavelength range for a particular link. Also some systems 252 will utilize more than one band. This is particularly true for coarse 253 WDM (CWDM) systems. 255 [Editor's note: the previous text is primarily tutorial in nature and 256 maybe deleted or moved to an appendix in a future draft] 258 Current technology breaks up the bandwidth capacity of fibers into 259 distinct channels based on either wavelength or frequency. There are 260 two standards covering wavelengths and channel spacing. ITU-T 261 recommendation [G.694.1] describes a DWDM grid defined in terms of 262 frequency grids of 12.5GHz, 25GHz, 50GHz, 100GHz, and other multiples 263 of 100GHz around a 193.1THz center frequency. At the narrowest 264 channel spacing this provides less than 4800 channels across the O 265 through U bands. ITU-T recommendation [G.694.2] describes a CWDM grid 266 define in terms of wavelength increments of 20nm running from 1271nm 267 to 1611nm for 18 or so channels. The number of channels is 268 significantly smaller than the 32 bit GMPLS label space allocated to 269 lambda switching. A fixed mapping between the GMPLS label space and 270 these ITU-T WDM grids as proposed in [Otani] would not only allow a 271 common vocabulary to be used in signaling lightpaths but also in 272 describing WDM links, ROADM ports, and wavelength converters for the 273 purposes path selection. 275 With a tremendous existing base of fiber many WDM links are designed 276 to take advantage of particular fiber characteristics or to try to 277 avoid undesirable properties. For example dispersion shifted SMF 278 [G.653] was originally designed for good long distance performance in 279 single channel systems, however putting WDM over this type of fiber 280 requires much system engineering and a fairly limited range of 281 wavelengths. Hence for our basic, impairment unaware, modeling of a 282 WDM link we will need the following information: 284 o Wavelength range(s): Given a mapping between labels and the ITU-T 285 grids each range could be expressed in terms of a doublet 286 (lambda1, lambda2) or (freq1, freq1) where the lambdas or 287 frequencies can be represented by 32 bit integers. 289 o Channel spacing: currently there are about five channel spacings 290 used in DWDM systems 12.5GHz to 200GHz and one defined CWDM 291 spacing. 293 For a particular link this information is relatively static, i.e., 294 changes to these properties generally require hardware upgrades. Such 295 information could be used locally during wavelength assignment via 296 signaling, similar to label restrictions in MPLS or used by a PCE in 297 solving the combined routing and wavelength assignment problem. 299 3.2. Optical Transmitters 301 3.2.1. Lasers 303 WDM optical systems make use of laser transmitters utilizing 304 different wavelengths (frequencies). Some laser transmitters were and 305 are manufactured for a specific wavelength of operation, that is, the 306 manufactured frequency cannot be changed. First introduced to reduce 307 inventory costs, tunable optical laser transmitters are becoming 308 widely deployed in some systems [Coldren04], [Buus06]. This allows 309 flexibility in the wavelength used for optical transmission and aids 310 in the control of path selection. 312 Fundamental modeling parameters from the control plane perspective 313 optical transmitters are: 315 o Tunable: Is this transmitter tunable or fixed. 317 o Tuning range: This is the frequency or wavelength range over which 318 the laser can be tuned. With the fixed mapping of labels to 319 lambda's of [Otani] this can be expressed as a doublet (lambda1, 320 lambda2) or (freq1, freq2) where lambda1 and lambda2 or freq1 and 321 freq2 are the labels representing the lower and upper bounds in 322 wavelength or frequency. 324 o Tuning time: Tuning times highly depend on the technology used. 325 Thermal drift based tuning may take seconds to stabilize, whilst 326 electronic tuning might provide sub-ms tuning times. Depending on 327 the application this might be critical. For example, thermal drift 328 might not be applicable for fast protection applications. 330 o Spectral Characteristics and stability: The spectral shape of the 331 laser's emissions and its frequency stability put limits on 332 various properties of the overall WDM system. One relatively easy 333 to characterize constraint is the finest channel spacing on which 334 the transmitter can be used. 336 Note that ITU-T recommendations specify many other aspects of a 337 laser's such as spectral characteristics and stability. Many of these 338 parameters a key in designing WDM subsystems consisting of 339 transmitters, WDM links and receivers however they do not furnish 340 additional information that will influence label switched path (LSP) 341 provisioning in a properly designed system. 343 Also note that lasers transmitters as a component can degrade and 344 fail over time. This presents the possibility of the failure of a LSP 345 (lightpath) without either a node or link failure. Hence, additional 346 mechanisms may be necessary to detect and differentiate this failure 347 from the others, e.g., one doesn't not want to initiate mesh 348 restoration if the source transmitter has failed, since the laser 349 transmitter will still be failed on the alternate optical path. 351 3.2.2. Spectral Characteristics & Modulation Type 353 Contrary to some marketing claims optical systems are not truly 354 "transparent" to the content of the signals that they carry. Each 355 lightpath will have spectral characteristics based on its content, 356 and the spacing of wavelengths in a WDM link will ultimately put 357 constraints on that spectrum. 359 For analog signals such as used in closed access television (CATV) or 360 "radio over fiber" links spectral characteristics are given in terms 361 of various bandwidth measures. However digital signals consist of our 362 main focus here and in the ITU-T G series optical specifications. In 363 this case the spectral characteristics can be more accurately 364 inferred from the modulation format and the bit rate. 366 Although Non-Return to Zero (NRZ) is currently the dominant form of 367 optical modulation, new modulation formats are being researched 368 [Winzer06] and deployed. With a choice in modulation formats we no 369 longer have a one to one relationship between digital bandwidth in 370 bytes or bits per second and the amount of optical spectrum (optical 371 bandwidth) consumed. To simplify the specification of optical signals 372 the ITU-T, in recommendation G.959.1, combined a rate bound and 373 modulation format designator [G.959.1]. For example, two of the 374 signal classes defined in [G.959.1] are: 376 Optical tributary signal class NRZ 1.25G: 378 "Applies to continuous digital signals with non-return to zero line 379 coding, from nominally 622 Mbit/s to nominally 1.25 Gbit/s. Optical 380 tributary signal class NRZ 1.25G includes a signal with STM-4 bit 381 rate according to ITU-T Rec. G.707/Y.1322." Note that Gigabit 382 Ethernet falls into this signaling class as well. 384 Optical tributary signal class RZ 40G: 386 "Applies to continuous digital signals with return to zero line 387 coding, from nominally 9.9 Gbit/s to nominally 43.02 Gbit/s. 388 Optical tributary signal class RZ 40G includes a signal with STM- 389 256 bit rate according to ITU-T Rec. G.707/Y.1322 and OTU3 bit rate 390 according to ITU-T Rec. G.709/Y.1331." 392 From a modeling perspective we have: 394 o Analog signals: bandwidth parameters, e.g., 3dB parameters and 395 similar. 397 o Digital signals: there are predefined modulation bit rate classes 398 that we can encode. 400 This information can be important in constraining route selection, 401 for example some signals may not be compatible with some links or 402 wavelength converters. In addition it lets the endpoints understand 403 if it can process the signal. 405 3.2.3. Signal Rates and Error Correction 407 Although, the spectral characteristics of a signal determine its 408 basic compatibility with a WDM system, more information is generally 409 needed for various processing activities such as regeneration and 410 reception. Many digital signals such as Ethernet, G.709, and SDH have 411 well defined encoding which includes forward error correction (FEC). 412 However many subsystem vendors offer additional FEC options for a 413 given signal type. The use of different FECs can lead to different 414 overall signal rates. If the FEC and rate used is not compatible 415 between the sender and receiver the signal can not be correctly 416 processed. Note that the rates of "standard" signals may be extended 417 to accommodate different payloads. For example there are 418 transmitters capable of directly mapping 10GE LAN-PHY traffic into 419 G.709 ODU2 frame with slightly higher clock rate [G.Sup43]. 421 3.3. ROADMs, OXCs, Splitters, Combiners and FOADMs 423 3.3.1. Reconfigurable Add/Drop Multiplexers and OXCs 425 Reconfigurable add/drop optical multiplexers (ROADM) have matured and 426 are available in different forms and technologies [Basch06]. This is 427 a key technology that allows wavelength based optical switching. A 428 classic degree-2 ROADM is shown in Figure 1. 430 Line side ingress +---------------------+ Line side egress 431 --->| |---> 432 | | 433 | ROADM | 434 | | 435 | | 436 +---------------------+ 437 | | | | o o o o 438 | | | | | | | | 439 O O O O | | | | 440 Tributary Side: Drop (egress) Add (ingress) 442 Figure 1 Degree-2 ROADM 444 The key feature across all ROADM types is their highly asymmetric 445 switching capability. In the ROADM of Figure 1, the "add" ingress 446 ports can only egress on the line side egress port and not on any of 447 the "drop" egress ports. The degree of a ROADM or switch is given by 448 the number of line side ports (ingress and egress) and does not 449 include the number of "add" or "drop" ports. Sometimes the "add" 450 "drop" ports are also called tributary ports. As the degree of the 451 ROADM increases beyond two it can have properties of both a switch 452 (OXC)and a multiplexer and hence we must know the potential 453 connectivity offered by such a network element to effectively utilize 454 it. A straight forward way to do this is via a "potential 455 connectivity" matrix A where Amn = 0 or 1, depending upon whether a 456 wavelength on ingress port m can be connected to egress port n 457 [Imajuku]. For the ROADM of Figure 1 the potential connectivity 458 matrix can be expressed as 459 Ingress Egress Port 460 Port #1 #2 #3 #4 #5 461 -------------- 462 #1: 1 1 1 1 1 463 #2 1 0 0 0 0 464 A = #3 1 0 0 0 0 465 #4 1 0 0 0 0 466 #5 1 0 0 0 0 468 Where ingress ports 2-5 are add ports, egress ports 2-5 are drop 469 ports and ingress port #1 and egress port #1 are the line side (WDM) 470 ports. 472 For ROADMs this matrix will be very sparse, and for OXCs the 473 complement of the matrix will be very sparse hence even relatively 474 high degree ROADMs/OXCs can be compactly characterized. 476 Additional constraints may also apply to the various ports in a 477 ROADM/OXC. In the literature of optical switches and ROADMs the 478 following restrictions/terms are used: 480 Colored port: An ingress or more typically an egress (drop) port 481 restricted to a single channel of fixed wavelength. 483 Colorless port: An ingress or more typically an egress (drop) port 484 restricted to a single channel of arbitrary wavelength. 486 In general a port on a ROADM could have any of the following 487 wavelength restrictions: 489 o Multiple wavelengths, full range port 491 o Single wavelength, full range port 493 o Single wavelength, fixed lambda port 495 o Multiple wavelengths, reduced range port (like wave band 496 switching) 498 To model these restrictions we need two pieces of information for 499 each port: (a) number of wavelengths, (b) wavelength range and 500 spacing. Note that this information is relatively static. 502 3.3.2. Splitters 504 An optical splitter consists of a single ingress port and two or more 505 egress ports. The ingress optical signaled is essentially copied 506 (with loss) to all egress ports. 508 Using the modeling notions of section 3.3.1. the ingress and egress 509 ports of a splitter would have the same wavelength restrictions. In 510 addition we can describe a splitter by a connectivity matrix Amn as 511 follows: 513 Ingress Egress Port 514 Port #1 #2 #3 ... #N 515 ----------------- 516 A = #1 1 1 1 ... 1 518 The difference from a simple ROADM is that this is not a "potential" 519 connectivity matrix but the fixed connectivity of the device. Hence 520 to differentiate between a simple ROADM and a splitter we'd need an 521 indicator as to whether the device is reconfigurable. 523 3.3.3. Combiners 525 A optical combiner is somewhat the dual of a splitter in that it has 526 a single multi-wavelength egress port and multiple ingress ports. 527 The contents of all the ingress ports are copied and combined to the 528 single egress port. The various ports may have different wavelength 529 restrictions. It is generally the responsibility of those using the 530 combiner to assure that wavelength collision does not occur on the 531 egress port. The connectivity matrix Amn for a combiner would look 532 like: 534 Ingress Egress Port 535 Port #1 536 --- 537 #1: 1 538 #2 1 539 A = #3 1 540 ... 1 541 #N 1 543 Once again this connectivity is fixed. 545 3.3.4. Fixed Optical Add/Drop Multiplexers 547 A fixed optical add/drop multiplexer can alter the course of an 548 ingress wavelength in a preset way. In particular a particular 549 wavelength (or waveband) from a line side ingress port would be 550 dropped to a particular "tributary" egress port. Depending on the 551 device's fixed configuration that same wavelength may or may not be 552 "continued" to the line side egress port ("drop and continue" 553 operation). Further there may exist tributary ingress ports ("add" 554 ports) whose signals are combined with each other and "continued" 555 line side signals. 557 In general to represent the routing properties of an FOADM we need 558 the connectivity matrix Amn as previously discussed and we need the 559 precise wavelength restrictions for all ingress and egress ports. 560 From the wavelength restrictions on the tributary egress ports (drop 561 ports) we can see what wavelengths have been dropped. From the 562 wavelength restrictions on the tributary ingress (add) ports we can 563 see which wavelengths have been added to the line side egress port. 564 Finally from the added wavelength information and the line side 565 egress wavelength restrictions we can infer which wavelengths have 566 been continued. 568 To summarize, the modeling methodology introduced in section 3.3.1. 569 consisting of a connectivity matrix and port wavelength restrictions 570 can be used to describe a large set of fixed optical devices such as 571 combiners, splitters and FOADMs with the inclusion of an indicator as 572 to whether the device is Fixed or Reconfigurable and the appropriate 573 interpretations detailed previously. 575 3.4. Wavelength Converters 577 Wavelength converters take an ingress optical signal at one 578 wavelength and emit an equivalent content optical signal at another 579 wavelength on egress. There are currently two approaches to building 580 wavelength converters. One approach is based on optical to electrical 581 to optical (OEO) conversion with tunable lasers on egress. This 582 approach can be dependent upon the signal rate and format, i.e., this 583 is basically an electrical regenerator combined with a tunable laser. 584 The other approach performs the wavelength conversion, optically via 585 non-linear optical effects, similar in spirit to the familiar 586 frequency mixing used in radio frequency systems, but significantly 587 harder to implement. Such processes/effects may place limits on the 588 range of achievable conversion. These may depend on the wavelength of 589 the input signal and the properties of the converter as opposed to 590 the only the properties of the converter in the OEO case. Different 591 WSON system designs may choose to utilize this component to varying 592 degrees or not at all. 594 Current or envisioned contexts for wavelength converters are: 596 1. Wavelength conversion associated with OEO switches and tunable 597 laser transmitters. In this case there are plenty of converters to 598 go around since we can think of each tunable output laser 599 transmitter on an OEO switch as a potential wavelength converter. 601 2. Wavelength conversion associated with ROADMs/OXCs. In this case we 602 may have a limited amount of conversion available. Conversion could 603 be either all optical or via an OEO method. 605 3. Wavelength conversion associated with fixed devices such as FOADMs. 606 In this case we may have a limited amount of conversion. Also in 607 this case the conversion may be used as part of light path routing. 609 Based on the above contexts a tentative modeling approach for 610 wavelength converters could be as follows: 612 1. Wavelength converters can always be modeled as associated with 613 network elements. This includes fixed wavelength routing elements. 615 2. A network element may have full wavelength conversion capability, 616 i.e., any ingress port and wavelength, or a limited number of 617 wavelengths and ports. On a box with a limited number of 618 converters there also may exist restrictions on which ports can 619 reach the converters. Hence regardless of where the converters 620 actually are we can associate them with ingress ports. 622 3. Wavelength converters have range restrictions that are either 623 independent or dependent upon the ingress wavelength. [TBD: for 624 those that depend on ingress wavelength can we have a standard 625 formula? Also note that this type of converter introduces 626 additional optical impairments.] 628 4. Wavelength converters that are O-E-O based will have a restriction 629 based on the modulation format and transmission speed. 631 Note that since O-E-O wavelength converters also serve as 632 regenerators we can include regenerators in our model of wavelength 633 converters. O-E-O Regenerators come in three general types known as 634 1R, 2R, and 3R regenerators. 1R regenerators re-amplify the signal to 635 combat attenuation, 2R regenerators reshape as well as amplify the 636 signal, 3R regenerators amplify, reshape and retime the signal. As we 637 go from 1R to 3R regenerators the signal is ''cleaned up'' better but 638 at the same time the regeneration process becomes more dependent on 639 the signal characteristics such as format and rate. 641 In WSONs where wavelength converters are sparse we may actually see a 642 light path appear to loop or ''backtrack'' upon itself in order to 643 reach a wavelength converter prior to continuing on to its 644 destination. The lambda used on the "detour" out to the wavelength 645 converter would be different from that coming back from the "detour" 646 to the wavelength converter. 648 A model for an O-E-O wavelength converter would consist of: 650 o Input lambda or frequency range 652 o Output lambda or frequency range 653 o Equivalent regeneration level (1R, 2R, 3R) 655 o Signal restrictions if a 2R or 3R regeneration: formats and rates 657 [FFS: Model for an all optical wavelength converter] 659 4. Routing and Wavelength Assignment 661 In wavelength switched optical networks consisting of tunable lasers 662 and wavelength selective switches with wavelength converters on every 663 interface, path selection is similar to the MPLS and TDM circuit 664 switched cases in that the labels, in this case wavelengths 665 (lambdas), have only local significance. That is, a wavelength- 666 convertible network with full wavelength-conversion capability at 667 each node is equivalent to a circuit-switched TDM network with full 668 time slot interchange capability; thus, the routing problem needs to 669 be addressed only at the level of the traffic engineered (TE) link 670 choice, and wavelength assignment can be resolved locally by the 671 switches on a hop-by-hop basis. 673 However, in the limiting case of an optical network with no 674 wavelength converters, a light path (optical channel - OCh -) needs a 675 route from source to destination and must pick a single wavelength 676 that can be used along that path without "colliding" with the 677 wavelength used by any other light path that may share an optical 678 fiber. This is sometimes referred to as a "wavelength continuity 679 constraint". To ease up on this constraint while keeping network 680 costs in check a limited number of wavelength converters maybe 681 introduce at key points in the network [Chu03]. 683 In the general case of limited or no wavelength converters this 684 computation is known as the Routing and Wavelength Assignment (RWA) 685 problem [HZang00]. The "hardness" of this problem is well documented. 686 There, however, exist a number of reasonable approximate methods for 687 its solution [HZang00]. 689 The inputs to the basic RWA problem are the requested light paths 690 source and destination, the networks topology, the locations and 691 capabilities of any wavelength converters, and the wavelengths 692 available on each optical link. The output from an algorithm solving 693 the RWA problem is an explicit route through ROADMs, a wavelength for 694 the optical transmitter, and a set of locations (generally associated 695 with ROADMs or switches) where wavelength conversion is to occur and 696 the new wavelength to be used on each component link after that point 697 in the route. 699 It is to be noted that choice of specific RWA algorithm is out of the 700 scope for this document. However there are a number of different 701 approaches to dealing with the RWA algorithm that can affect the 702 division of effort between signaling, routing and PCE. 704 4.1. Lightpath Temporal Characteristics 706 Key inputs that can affect the choice of solution to the RWA process 707 are those associated with the temporal characteristics of a light 708 path connection. For our purposes here we look at the timeliness of 709 connection establishment/teardown, and the duration of the 710 connection. 712 Connection Establishment/Teardown Timeliness can be thought of in 713 approximately three time frames: 715 1. Time Critical: For example those lightpath establishments used for 716 restoration of service or other high priority real time service 717 requests. 719 2. Soft time bounds: This is a more typical new connection request. 720 While expected to be responsive, there should be more time to take 721 into account network optimization. 723 3. Scheduled or Advanced reservations. Here lightpath connections are 724 requested significantly ahead of their intended "in service" time. 725 There is the potential for significant network optimization if 726 multiple lightpaths can be computed in parallel to achieve network 727 optimization objectives. 729 Lightpath connection duration has typically been thought of as 730 approximately three time frames: 732 1. Dynamic: those lightpaths with relatively short duration (holding 733 times). 735 2. Pseudo-static: lightpaths with moderately long durations. 737 3. Static: lightpaths with long durations. 739 Different types of RWA algorithms have been developed for dealing 740 with dynamic versus pseudo-static conditions. These can address 741 service provider's needs for: (a) network optimization, (b) 742 restoration, and (c) highly dynamic lightpath provisioning. 744 Hence we can model timescale related lightpath requirements via the 745 following notions: 747 o Batch or Sequential light path connection requests 748 o Timeliness of Connection establishment 750 o Duration of lightpath connection 752 4.2. RWA Algorithmic Approaches: Combined vs. Two-step 754 When solving the RWA problem some algorithms that solve the problem 755 in a two step procedure of path selection followed by wavelength 756 assignment, and others that solve the problem in a combined fashion. 757 These different types of algorithms can have different 758 characteristics with respect to computational complexity and 759 optimality that can influence how and where they may be used. 761 Given a path, the following are a non-exhaustive subset of wavelength 762 assignment (WA) approaches discussed in [HZang00]: 764 1. Random: Looks at all available wavelengths for the light path then 765 chooses from those available at random. 767 2. First Fit: Wavelengths are ordered, first available (on all links) 768 is chosen. 770 3. Most Used: Out of the wavelengths available on the path attempts 771 to select most use wavelength in network. 773 4. Least Loaded: For multi-fiber networks. Chooses the wavelength j 774 that maximizes minimum of the difference between the number of 775 fibers on link l and the number of fibers on link l with 776 wavelength j occupied. 778 As can be seen from the above short list, wavelength assignment 779 methods have differing information or processing requirements. When a 780 two step RWA algorithm is used there is also the possibility of 781 utilizing the signaling system to perform distributed wavelength 782 assignment. The details would differ according to the WA algorithm 783 chosen but at a minimum all would take an intersection of available 784 wavelength sets as seen at each link along the path to produce the 785 available wavelength set for the path. 787 4.3. RWA Computation Architectures 789 The previous discussion leads to the following possible RWA 790 computation architectures. As will be seen in the GMPLS/PCE 791 evaluation section these architectures have different impacts on 792 their needs with respect to protocol extensions. 794 o Combined RWA --- Both routing and wavelength assignment are 795 performed at a single computational entity. This choice assumes 796 that computational entity has sufficient WSON network link/nodal 797 information and topology to be able to compute RWA. The amount of 798 information can vary depending on the RWA approach/algorithm 799 utilized. Good for network optimization and for smaller WSONs. 801 o Separate Routing and WA --- Separate entities perform routing and 802 wavelength assignment. The path obtained from the routing 803 computational entity must be furnished to the entity performing 804 wavelength assignment. Good for offloading some of the 805 computational burden and for reducing the number of entities that 806 need exact network link wavelength utilization, i.e., there can be 807 fewer nodes that perform WA than perform routing. 809 o Routing with Distributed WA --- Routing is performed at a 810 computational entity while wavelength assignment is performed in a 811 distributed fashion across nodes along the path. Good in that it 812 does not require exact network link wavelength information at any 813 node, but can have higher blocking probabilities compared to other 814 methods. 816 4.4. Conveying information needed by RWA 818 The previous sections have characterized WSONs and lightpath 819 requests. In particular high level models of the information by the 820 RWA process were presented. We can view this information as either 821 static, changing with hardware changes (including possibly failures), 822 or dynamic, can change with subsequent lightpath provisioning. The 823 timeliness in which an entity involved in the RWA process is notified 824 of such changes is fairly situational. For example, for network 825 restoration purposes, learning of a hardware failure or of new 826 hardware coming online to provide restoration capability can be 827 critical. 828 Currently there are various methods for communicating RWA relevant 829 information, these include, but are not limited to: 831 o Existing control plane protocols such as GMPLS routing and 832 signaling. Note that routing protocols can be used to convey both 833 static and dynamic information. Static information currently 834 conveyed includes items like router options and such. 836 o Management protocols such as NetConf, SNMPv3, CLI, CORBA, or 837 others. 839 o Directory services and accompanying protocols. These are good for 840 the dissemination of relatively static information. Not intended 841 for dynamic information. 843 o Other techniques for dynamic information: messaging straight from 844 NEs to PCE to avoid flooding. This would be useful if the number 845 of PCEs is significantly less than number of WSON NEs. Or other 846 ways to limit flooding to "interested" NEs. 848 Mechanisms to improve scaling of dynamic information: 850 o Tailor message content to WSON. For example the use of wavelength 851 ranges, or wavelength occupation bit maps. 853 o Utilize incremental updates if feasible. 855 5. GMPLS & PCE Implications 857 The presence and amount of wavelength conversion available at a 858 wavelength switching interface has an impact on the information that 859 needs to be transferred by the control plane (GMPLS) and the PCE 860 architecture. Current GMPLS and PCE standards can address the full 861 wavelength conversion case so the following with only address the 862 limited and no wavelength conversion cases. 864 5.1. Implications for GMPLS signaling 866 Basic support for WSON signaling already exists in GMPLS with the 867 lambda (value 9) LSP encoding type [RFC3471], or for G.709 compatible 868 optical channels, the LSP encoding type (value = 13) "G.709 Optical 869 Channel" from [RFC4328]. However a number of practical issues arise 870 in the identification of wavelengths and signals, and distributed 871 wavelength assignment processes which are discussed below. 873 5.1.1. Identifying Wavelengths and Signals 875 As previously stated a global fixed mapping between wavelengths and 876 labels simplifies the characterization of WDM links and WSON devices. 877 Furthermore such a mapping as described in [Otani] eases 878 communication between PCE and WSON PCCs. 880 An alternative to a global network map of labels to wavelengths would 881 be to use LMP to assign the map for each link then convey that 882 information to any path computation entities, e.g., label switch 883 routers or stand alone PCEs. The local label map approach will 884 require the label-set contents in the RSVP-TE Path message to be 885 translated every time the map changes between an incoming link and 886 the outgoing link. 888 In the future, it maybe worthwhile to define traffic parameters for 889 lambda LSPs that include a signal type field that includes modulation 890 format/rate information. This is similar to what was done in 891 reference [RFC4606] for SONET/SDH signal types. 893 5.1.2. Combined RWA/Separate Routing WA support 895 In either the combined RWA or separate routing WA cases, the node 896 initiating the signaling will have a route from the source to 897 destination along with the wavelengths (generalized labels) to be 898 used along portions of the path. Current GMPLS signaling supports an 899 explicit route object (ERO) and within an ERO an ERO Label subobject 900 can be use to indicate the wavelength to be used at a particular 901 node. In case the local label map approach is used the label sub- 902 object entry in the ERO has to be translated appropriately. 904 5.1.3. Distributed Wavelength Assignment: Unidirectional, No 905 Converters 907 GMPLS signaling for a uni-directional lightpath LSP allows for the 908 use of a label set object in the RSVP-TE path message. The processing 909 of the label set object to take the intersection of available lambdas 910 along a path can be performed resulting in the set of available 911 lambda being known to the destination that can then use a wavelength 912 selection algorithm to choose a lambda. The algorithms that can be 913 used would be limited to the information available at the destination 914 node. The information requirements of the methods discussed in 915 section 4.2. are as follows: 917 1. Random: nothing more than the available wavelength set. 919 2. First Fit: nothing more than the available wavelength set. 921 3. Most Used: the available wavelength set and information on global 922 wavelength use in the network. 924 4. Least Loaded: the available wavelength set and information 925 concerning the wavelength dependent loading for each link (this 926 applies to multi-fiber links). This could be obtained via global 927 information or via supplemental information passed via the 928 signaling protocol. 930 In case (3) above the global information needed by the wavelength 931 assignment could be derived from suitably enhanced GMPLS routing. 932 Note however this information need not be accurate enough for 933 combined RWA computation. Currently, GMPLS signaling does not provide 934 a way to indicate that a particular wavelength assignment algorithm 935 should be used. 937 5.1.4. Distributed Wavelength Assignment: Unidirectional, Limited 938 Converters 940 The previous outlined the case with no wavelength converters. In the 941 case of wavelength converters nodes with wavelength converters would 942 need to make the decision as to whether to perform conversion. One 943 indicator for this would be that the set of available wavelengths 944 which is obtained via the intersection of the incoming label set and 945 the egress links available wavelengths is either null or deemed too 946 small to permit successful completion. 948 At this point the node would need to remember that it will apply 949 wavelength conversion and will be responsible for assigning the 950 wavelength on the previous lambda-contiguous segment when the RSVP-TE 951 RESV message passes by. The node will pass on an enlarged label set 952 reflecting only the limitations of the wavelength converter and the 953 egress link. The record route option in RVSP-TE signaling can be used 954 to show where wavelength conversion has taken place. 956 5.1.5. Distributed Wavelength Assignment: Bidirectional, No 957 Converters 959 There are potential issues in the case of a bi-directional lightpath 960 which requires the use of the same lambda in both directions. We can 961 try to use the above procedure to determine the available 962 bidirectional lambda set if we use the interpretation that the 963 available label set is available in both directions. However, a 964 problem, arises in that bidirectional LSPs setup, according to 965 [RFC3471] section 4.1, is indicated by the presence of an upstream 966 label in the path message. 968 However, until the intersection of the available label sets is 969 obtained, e.g., at the destination node and the wavelength assignment 970 algorithm has been run the upstream label information will not be 971 available. Hence currently distributed wavelength assignment with 972 bidirectional lightpaths is not supported. 974 5.2. Implications for GMPLS Routing 976 GMPLS routing [RFC4202] currently defines an interface capability 977 descriptor for "lambda switch capable" (LSC) which we can use to 978 describe the interfaces on a ROADM or other type of wavelength 979 selective switch. In addition to the topology information typically 980 conveyed via an IGP, we would need to convey the following subsystem 981 properties to minimally characterize a WSON: 983 1. WDM Link properties (allowed wavelengths). 985 2. Laser Transmitters (wavelength range). 987 3. ROADM/FOADM properties (connectivity matrix, port wavelength 988 restrictions). 990 4. Wavelength Converter properties (per network element, may change if 991 a common limited shared pool is used). 993 In most cases we should be able to combine items (1) and (2) into the 994 information in item (3). Except for the number of wavelength 995 converters that are available in a shared pool, and the previous 996 information is fairly static. In the next two sections we discuss 997 dynamic available link bandwidth information. 999 5.2.1. Need for Wavelength-Specific Maximum Bandwidth Information 1001 Difficulties are encountered when trying to use the bandwidth 1002 accounting methods of [RFC4202] and [RFC3630] to describe the 1003 availability of wavelengths on a WDM link. The current RFCs give 1004 three link resource measures: Maximum Bandwidth, Maximum Reservable 1005 Bandwidth, and Unreserved Bandwidth. Although these can be used to 1006 describe a WDM span they do not provide the fundamental information 1007 needed for RWA. We are not given the maximum bandwidth per wavelength 1008 for the span. If we did then we could use the aforementioned measures 1009 to tell us the maximum wavelength count and the number of available 1010 wavelengths. 1012 For example, suppose we have a 32 channel WDM span, and that the 1013 system in general supports ITU-T NRZ signals up to NRZ 10Gbps. 1014 Further suppose that the first 20 channels are carrying 1Gbps 1015 Ethernet, then the maximum bandwidth would be 320Gbps and the maximum 1016 reservable bandwidth would be 120Gbps (12 wavelengths). 1017 Alternatively, consider the case where the first 8 channels are 1018 carrying 2.5Gbps SDH STM-16 channels, then the maximum bandwidth 1019 would still be 320Gbps and the maximum reservable bandwidth would be 1020 240Gbps (24 wavelengths). 1022 Such information would be useful in the routing with distributed WA 1023 approach of section 4.3. 1025 5.2.2. Need for Wavelength-Specific Availability Information 1027 Even if we know the number of available wavelengths on a link, we 1028 actually need to know which specific wavelengths are available and 1029 which are occupied if we are going to run a combined RWA process or 1030 separate WA process as discussed in section 4.3. This is currently 1031 not possible with GMPLS routing extensions. 1033 In the routing extensions for GMPLS [RFC4202], requirements for 1034 layer-specific TE attributes are discussed. The RWA problem for 1035 optical networks without wavelength converters imposes an additional 1036 requirement for the lambda (or optical channel) layer: that of 1037 knowing which specific wavelengths are in use. Note that current 1038 dense WDM (DWDM) systems range from 16 channels to 128 channels with 1039 advanced laboratory systems with as many as 300 channels. Given these 1040 channel limitations and if we take the approach of a global 1041 wavelength to label mapping or furnishing the local mappings to the 1042 PCEs then representing the use of wavelengths via a simple bit-map is 1043 feasible. 1045 5.2.3. Relationship to Link Bundling and Layering 1047 When dealing with static DWDM systems, particularly from a SONET/SDH 1048 or G.709 digital wrapper layer, each lambda looks like a separate 1049 link. Typically a bunch of unnumbered links, as supported in GMPLS 1050 routing extensions [RFC4202], would be used to describe a static DWDM 1051 system. In addition these links can be bundled into a TE link 1052 ([RFC4202], [RFC4201]) for more efficient dissemination of resource 1053 information. However, in the case discussed here we want to control a 1054 dynamic WDM layer and must deal with wavelengths as labels and not 1055 just as links or component links from the perspective of an upper 1056 (client) layer. In addition, a typical point to point optical cable 1057 contains many optical fibers and hence it may be desirable to bundle 1058 these separate fibers into a TE link. Note that in the no wavelength 1059 conversion or limited wavelength conversion situations that we will 1060 need information on wavelength usage on the individual component 1061 links. 1063 5.2.4. WSON Routing Information Summary 1065 The following table summarizes the WSON information that could be 1066 conveyed via GMPLS routing and attempts to classify that information 1067 as to its static or dynamic nature and whether that information would 1068 tend to be associated with either a link or a node. 1070 Information Static/Dynamic Node/Link 1071 ------------------------------------------------------------------ 1072 Connectivity matrix Static Node 1073 Per port wavelength restrictions Static Node(1) 1074 WDM link (fiber) lambda ranges Static Link 1075 WDM link channel spacing Static Link 1076 Laser Transmitter range Static Link(2) 1077 Wavelength conversion capabilities Static(3) Node 1078 Maximum bandwidth per Wavelength Static Link 1079 Wavelength Availability Dynamic(4) Link 1081 Notes: 1083 1. These are the per port wavelength restrictions of an optical 1084 device such as a ROADM and are independent of any optical 1085 constraints imposed by a fiber link. 1087 2. This could also be viewed as a node capability. 1089 3. This could be dynamic in the case of a limited pool of converters 1090 where the number available can change with connection 1091 establishment. Note we may want to include regeneration 1092 capabilities here since OEO converters are also regenerators. 1094 4. Not necessarily needed in the case of distributed wavelength 1095 assignment via signaling. 1097 While the full complement of the information from the previous table 1098 is needed in the Combined RWA and the separate Routing and WA 1099 architectures, in the case of Routing + distribute WA via signaling 1100 we only need the following information: 1102 Information Static/Dynamic Node/Link 1103 ------------------------------------------------------------------ 1104 Connectivity matrix Static Node 1105 Wavelength conversion capabilities Static(3) Node 1107 Information models and compact encodings for this information is 1108 provided in [WSON-Info]. 1110 5.3. Optical Path Computation and Implications for PCE 1112 As previously noted the RWA problem can be computationally intensive 1113 [HZang00]. Such computationally intensive path computations and 1114 optimizations were part of the impetus for the PCE (path computation 1115 element) architecture. 1117 As the PCEP defines the procedures necessary to support both 1118 sequential [PCEP] and global concurrent path computations [PCE-GCO], 1119 PCE is well positioned to support WSON-enabled RWA computation with 1120 some protocol enhancement. 1122 Implications for PCE generally fall into two main categories: (a) 1123 lightpath constraints and characteristics, (b) computation 1124 architectures. 1126 5.3.1. Lightpath Constraints and Characteristics 1128 For the varying degrees of optimization that may be encountered in a 1129 network the following models of bulk and sequential lightpath 1130 requests are encountered: 1132 o Batch optimization, multiple lightpaths requested at one time. 1134 o Lightpath(s) and backup lightpath(s) requested at one time. 1136 o Single lightpath requested at a time. 1138 PCEP and PCE-GCO can be readily enhanced to support all of the 1139 potential models of RWA computation. 1141 Lightpath constraints include: 1143 o Bidirectional Assignment of wavelengths 1145 o Possible simultaneous assignment of wavelength to primary and 1146 backup paths. 1148 o Tuning range constraint on optical transmitter. 1150 Lightpath characteristics can include: 1152 o Duration information (how long this connection may last) 1154 o Timeliness/Urgency information (how quickly is this connection 1155 needed) 1156 5.3.2. Computation Architecture Implications 1158 When a PCE performs a combined RWA computation per section 4.3. it 1159 requires accurate an up to date wavelength utilization on all links 1160 in the network. 1162 When a PCE is used to perform wavelength assignment (WA) in the 1163 separate routing WA architecture then the entity requesting WA needs 1164 to furnish the pre-selected route to the PCE as well as any of the 1165 lightpath constraints/characteristics previously mentioned. This 1166 architecture also requires the PCE performing WA to have accurate and 1167 up to date network wavelength utilization information. 1169 When a PCE is used to perform routing in a routing with distribute WA 1170 architecture, then the PCE does not necessarily need the most up to 1171 date network wavelength utilization information, however timely 1172 information can contributed to reducing failed signaling attempts 1173 related to blocking. 1175 5.3.3. Discovery of RWA Capable PCEs 1177 The algorithms and network information needed for solving the RWA are 1178 somewhat specialized and computationally intensive hence not all PCEs 1179 within a domain would necessarily need or want this capability. 1180 Hence, it would be useful via the mechanisms being established for 1181 PCE discovery [RFC5088] to indicate that a PCE has the ability to 1182 deal with the RWA problem. Reference [RFC5088] indicates that a sub- 1183 TLV could be allocated for this purpose. 1185 Recent progress on objective functions in PCE [PCE-OF] would allow 1186 the operators to flexibly request differing objective functions per 1187 their need and applications. For instance, this would allow the 1188 operator to choose an objective function that minimizes the total 1189 network cost associated with setting up a set of paths concurrently. 1190 This would also allow operators to choose an objective function that 1191 results in a most evenly distributed link utilization. 1193 This implies that PCEP would easily accommodate wavelength selection 1194 algorithm in its objective function to be able to optimize the path 1195 computation from the perspective of wavelength assignment if chosen 1196 by the operators. 1198 5.4. Scaling Implications 1200 This section provides a summary of the scaling issue for WSON 1201 routing, signaling and path computation introduced by the concepts 1202 discussed in this document. 1204 5.4.1. Routing 1206 In large WSONs label availability and cross connect capability 1207 information being advertised may generate a significant amount of 1208 routing information. 1210 5.4.2. Signaling 1212 When dealing with a large number of simultaneous end-to-end 1213 wavelength service requests and service deletions the network may 1214 have to process a significant number of forward and backward service 1215 messages. Also, similar situation possibly happens in the case of 1216 link or node failure, if the WSON support dynamic restoration 1217 capability. 1219 5.4.3. Path computation 1221 If a PCE is handling path computation requests for end-to-end 1222 wavelength services within the WSON, then the complexity of the 1223 network and number of service path computation requests being sent to 1224 the PCE may have an impact on the PCEs ability to process requests in 1225 a timely manner. 1227 6. Security Considerations 1229 This document has no requirement for a change to the security models 1230 within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, 1231 and PCEP security models could be operated unchanged. 1233 However satisfying the requirements for RWA using the existing 1234 protocols may significantly affect the loading of those protocols. 1235 This makes the operation of the network more vulnerable to denial of 1236 service attacks. Therefore additional care maybe required to ensure 1237 that the protocols are secure in the WSON environment. 1239 Furthermore the additional information distributed in order to 1240 address the RWA problem represents a disclosure of network 1241 capabilities that an operator may wish to keep private. Consideration 1242 should be given to securing this information. 1244 7. IANA Considerations 1246 This document makes no request for IANA actions. 1248 8. Acknowledgments 1250 The authors would like to thank Adrian Farrel for many helpful 1251 comments that greatly improved the contents of this draft. 1253 This document was prepared using 2-Word-v2.0.template.dot. 1255 9. References 1257 9.1. Normative References 1259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1260 Requirement Levels", BCP 14, RFC 2119, March 1997. 1262 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1263 (GMPLS) Signaling Functional Description", RFC 3471, 1264 January 2003. 1266 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1267 (TE) Extensions to OSPF Version 2", RFC 3630, September 1268 2003. 1270 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1271 (GMPLS) Architecture", RFC 3945, October 2004. 1273 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 1274 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 1276 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support 1277 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 1278 4202, October 2005. 1280 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of 1281 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 1282 4203, October 2005. 1284 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 1285 Switching (GMPLS) Signaling Extensions for G.709 Optical 1286 Transport Networks Control", RFC 4328, January 2006. 1288 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 1289 applications: DWDM frequency grid", June, 2002. 1291 [RFC5088] J.L. Le Roux, J.P. Vasseur, Yuichi Ikejiri, and Raymond 1292 Zhang, "OSPF protocol extensions for Path Computation 1293 Element (PCE) Discovery", January 2008. 1295 [PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path 1296 Computation Element Communication Protocol (PCECP) 1297 Requirements and Protocol Extensions In Support of Global 1298 Concurrent Optimization", work in progress, draft-ietf-pce- 1299 global-concurrent-optimization-01.txt, November 2007. 1301 [PCEP] J.P. Vasseur and J.L. Le Roux (Editors), "Path Computation 1302 Element (PCE) Communication Protocol (PCEP)", work in 1303 progress, draft-ietf-pce-pcep-10.txt, February 2008. 1305 [PCE-OF] J.L. Le Roux, J.P. Vasseur, and Y. Lee, "Encoding of 1306 Objective Functions in Path Computation Element (PCE) 1307 communication and discovery protocols", work in progress, 1308 draft-ietf-pce-of-01.txt, February 2008. 1310 [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku," Routing and 1311 Wavelength Assignment Information for Wavelength Switched 1312 Optical Networks", draft-bernstein-ccamp-wson-info-02.txt, 1313 February, 2008. 1315 9.2. Informative References 1317 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and 1318 wavelength assignment approaches for wavelength-routed 1319 optical WDM networks", Optical Networks Magazine, January 1320 2000. 1322 [Coldren04] Larry A. Coldren, G. A. Fish, Y. Akulova, J. S. 1323 Barton, L. Johansson and C. W. Coldren, "Tunable 1324 Seiconductor Lasers: A Tutorial", Journal of Lightwave 1325 Technology, vol. 22, no. 1, pp. 193-202, January 2004. 1327 [Chu03] Xiaowen Chu, Bo Li and Chlamtac I, "Wavelength converter 1328 placement under different RWA algorithms in wavelength- 1329 routed all-optical networks", IEEE Transactions on 1330 Communications, vol. 51, no. 4, pp. 607-617, April 2003. 1332 [Buus06] Jens Buus EJM, "Tunable Lasers in Optical Networks", 1333 Journal of Lightware Technology, vol. 24, no. 1, pp. 5-11, 1334 January 2006. 1336 [Basch06] E. Bert Bash, Roman Egorov, Steven Gringeri and Stuart 1337 Elby, "Architectural Tradeoffs for Reconfigurable Dense 1338 Wavelength-Division Multiplexing Systems", IEEE Journal of 1339 Selected Topics in Quantum Electronics, vol. 12, no. 4, pp. 1340 615-626, July/August 2006. 1342 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 1343 Labels of Lambda-Switching Capable Label Switching Routers 1344 (LSR)", work in progress: draft-otani-ccamp-gmpls-lambda- 1345 labels-01.txt, November 2007. 1347 [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced 1348 Optical Modulation Formats", Proceedings of the IEEE, vol. 1349 94, no. 5, pp. 952-985, May 2006. 1351 [G.652] ITU-T Recommendation G.652, Characteristics of a single-mode 1352 optical fibre and cable, June 2005. 1354 [G.653] ITU-T Recommendation G.653, Characteristics of a dispersion- 1355 shifted single-mode optical fibre and cable, December 2006. 1357 [G.654] ITU-T Recommendation G.654, Characteristics of a cut-off 1358 shifted single-mode optical fibre and cable, December 2006. 1360 [G.655] ITU-T Recommendation G.655, Characteristics of a non-zero 1361 dispersion-shifted single-mode optical fibre and cable, 1362 March 2006. 1364 [G.656] ITU-T Recommendation G.656, Characteristics of a fibre and 1365 cable with non-zero dispersion for wideband optical 1366 transport, December 2006. 1368 [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network 1369 Physical Layer Interfaces, March 2006. 1371 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 1372 applications: DWDM frequency grid, June 2002. 1374 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 1375 applications: CWDM wavelength grid, December 2003. 1377 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and 1378 engineering considerations, February 2006. 1380 [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R 1381 in optical transport networks (OTN), November 2006. 1383 [Imajuku] W. Imajuku, Y. Sone, I. Nishioka, S. Seno, "Routing 1384 Extensions to Support Network Elements with Switching 1385 Constraint", work in progress: draft-imajuku-ccamp-rtg- 1386 switching-constraint-02.txt, July 2007. 1388 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 1389 on Optical Layer Routing", RFC 4054, May 2005. 1391 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 1392 Protocol Label Switching (GMPLS) Extensions for Synchronous 1393 Optical Network (SONET) and Synchronous Digital Hierarchy 1394 (SDH) Control", RFC 4606, August 2006. 1396 10. Contributors 1398 Snigdho Bardalai 1399 Fujitsu 1400 Email: Snigdho.Bardalai@us.fujitsu.com 1402 Diego Caviglia 1403 Ericsson 1404 Via A. Negrone 1/A 16153 1405 Genoa Italy 1407 Phone: +39 010 600 3736 1408 Email: diego.caviglia@(marconi.com, ericsson.com) 1410 Daniel King 1411 Aria Networks 1412 Email: daniel.king@aria-networks.com 1414 Itaru Nishioka 1415 NEC Corp. 1416 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 1417 Japan 1418 Phone: +81 44 396 3287 1419 Email: i-nishioka@cb.jp.nec.com 1421 Lyndon Ong 1422 Ciena 1423 Email: Lyong@Ciena.com 1425 Jonathan Sadler 1426 Tellabs 1427 Email: Jonathan.Sadler@tellabs.com 1429 Author's Addresses 1431 Greg Bernstein (ed.) 1432 Grotto Networking 1433 Fremont, CA, USA 1435 Phone: (510) 573-2237 1436 Email: gregb@grotto-networking.com 1437 Young Lee (ed.) 1438 Huawei Technologies 1439 1700 Alma Drive, Suite 100 1440 Plano, TX 75075 1441 USA 1443 Phone: (972) 509-5599 (x2240) 1444 Email: ylee@huawei.com 1446 Wataru Imajuku 1447 NTT Network Innovation Labs 1448 1-1 Hikari-no-oka, Yokosuka, Kanagawa 1449 Japan 1451 Phone: +81-(46) 859-4315 1452 Email: imajuku.wataru@lab.ntt.co.jp 1454 Intellectual Property Statement 1456 The IETF takes no position regarding the validity or scope of any 1457 Intellectual Property Rights or other rights that might be claimed to 1458 pertain to the implementation or use of the technology described in 1459 this document or the extent to which any license under such rights 1460 might or might not be available; nor does it represent that it has 1461 made any independent effort to identify any such rights. Information 1462 on the procedures with respect to rights in RFC documents can be 1463 found in BCP 78 and BCP 79. 1465 Copies of IPR disclosures made to the IETF Secretariat and any 1466 assurances of licenses to be made available, or the result of an 1467 attempt made to obtain a general license or permission for the use of 1468 such proprietary rights by implementers or users of this 1469 specification can be obtained from the IETF on-line IPR repository at 1470 http://www.ietf.org/ipr. 1472 The IETF invites any interested party to bring to its attention any 1473 copyrights, patents or patent applications, or other proprietary 1474 rights that may cover technology that may be required to implement 1475 this standard. Please address the information to the IETF at 1476 ietf-ipr@ietf.org. 1478 Disclaimer of Validity 1480 This document and the information contained herein are provided on an 1481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1483 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1484 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1485 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1488 Copyright Statement 1490 Copyright (C) The IETF Trust (2008). 1492 This document is subject to the rights, licenses and restrictions 1493 contained in BCP 78, and except as set forth therein, the authors 1494 retain all their rights. 1496 Acknowledgment 1498 Funding for the RFC Editor function is currently provided by the 1499 Internet Society.