idnits 2.17.1 draft-bernstein-ccamp-wson-signal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (May 21, 2009) is 5454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.698.1' is mentioned on line 344, but not defined == Missing Reference: 'G.698.2' is mentioned on line 371, but not defined == Missing Reference: 'G.707' is mentioned on line 401, but not defined == Missing Reference: 'G.709' is mentioned on line 404, but not defined == Unused Reference: 'G.694.1' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-rwa-wson-framework-02 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-rwa-wson-encode-01 == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-gmpls-g-694-lambda-labels-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Informational Y. Lee 4 Expires: November 2009 Huawei 5 Ben Mack-Crane 6 Huawei 8 May 21, 2009 10 WSON Signal Characteristics and Network Element Compatibility 11 Constraints for GMPLS 12 draft-bernstein-ccamp-wson-signal-00.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 November 21, 2009. 37 Copyright Notice 39 Copyright (c) 2009 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 in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 While the current GMPLS WSON formalism can deal with many types of 51 wavelength switching systems there is a desire to extend this control 52 plane to include other common optical or hybrid electro optical 53 systems such as OEO switches, regenerators, and wavelength 54 converters. 56 This document provides a WSON signal definition and characterization 57 based on ITU-T interface and signal class standards and describes the 58 signal compatibility constraints of this extended set of network 59 elements. The signal characterization and network element 60 compatibility constraints enable GMPLS routing and signaling to 61 control these devices and PCE to compute optical light-paths subject 62 to signal compatibility attributes. 64 Table of Contents 66 1. Introduction and Requirements..................................3 67 1.1. Regenerators..............................................3 68 1.2. OEO Switches..............................................6 69 1.3. Wavelength Converters.....................................7 70 2. Describing Optical Signals in GMPLS............................8 71 2.1. Optical Interfaces........................................8 72 2.2. Optical Tributary Signals.................................8 73 2.3. Proposed GMPLS WSON Signal Definition.....................9 74 2.4. Implications for GMPLS Signaling and PCEP................10 75 3. Characterizing WSON Network Elements in GMPLS.................11 76 3.1. Proposed Link and Network Element (NE) Model Extensions..11 77 4. Security Considerations.......................................12 78 5. IANA Considerations...........................................12 79 6. Acknowledgments...............................................12 80 7. References....................................................13 81 7.1. Normative References.....................................13 82 7.2. Informative References...................................14 83 Author's Addresses...............................................14 84 Intellectual Property Statement..................................14 85 Disclaimer of Validity...........................................15 87 1. Introduction and Requirements 89 While the current GMPLS WSON formalism can deal with many types of 90 wavelength switching systems, these systems must be located within 91 optical signal networks to provide useful services. Therefore there 92 is a desire to extend this control plane to include other common 93 optical or hybrid electro optical systems required to build a 94 complete optical signal network. In particular at the March 2009 IETF 95 meeting the working group expressed a desire to include OEO switches, 96 regenerators, and wavelength converters within the WSON GMPLS 97 extensions. In the following we will describe these devices and their 98 properties. We then show that a combination of additional signal 99 attributes and network element attributes can be used to accommodate 100 these devices, relate these attributes to ITU-T recommendations and 101 describe the implications for GMPLS signaling, PCEP, and the WSON 102 information model [WSON-Info]. 104 It turns out OEO switches, wavelength converters and regenerators all 105 share a similar property: they can be more or less "transparent" to 106 an "optical signal" depending on their functionality and/or 107 implementation. Regenerators have been fairly well characterized in 108 this regard so we start by describing their properties. 110 Our approach to efficiently extend WSON GMPLS to networks that 111 include regenerators, OEO switches and wavelength converters is to 112 add attributes characterizing the WSON signal in line with ITU-T 113 standards, and add attributes describing signal compatibility 114 constraints to WSON network elements. This way the control plane 115 signaling and path computation functions can ensure "signal" 116 compatibility between source, sink and any links or network elements 117 as part of path selection process, and configure devices 118 appropriately via signaling as part of the connection provisioning 119 process. This enables integration of a WSON into the operations of a 120 signal network for which it provides connectivity instead of 121 requiring the WSON to be separately managed and controlled. 123 1.1. Regenerators 124 The various approaches to regeneration are discussed in ITU-T G.872 125 Annex A [G.872]. They map a number of functions into the so-called 126 1R, 2R and 3R categories of regenerators as summarized in Table 1 127 below: 129 Table 1 Regenerator functionality mapped to general regenerator 130 classes from [G.872]. 132 --------------------------------------------------------------------- 133 1R | Equal amplification of all frequencies within the amplification 134 | bandwidth. There is no restriction upon information formats. 135 +----------------------------------------------------------------- 136 | Amplification with different gain for frequencies within the 137 | amplification bandwidth. This could be applied to both single- 138 | channel and multi-channel systems. 139 +----------------------------------------------------------------- 140 | Dispersion compensation (phase distortion). This analogue 141 | process can be applied in either single-channel or multi- 142 | channel systems. 143 --------------------------------------------------------------------- 144 2R | Any or all 1R functions. Noise suppression. 145 +----------------------------------------------------------------- 146 | Digital reshaping (Schmitt Trigger function) with no clock 147 | recovery. This is applicable to individual channels and can be 148 | used for different bit rates but is not transparent to line 149 | coding (modulation). 150 -------------------------------------------------------------------- 151 3R | Any or all 1R and 2R functions. Complete regeneration of the 152 | pulse shape including clock recovery and retiming within 153 | required jitter limits. 154 -------------------------------------------------------------------- 156 From the previous table we can see that 1R regenerators are generally 157 independent of signal modulation format (also known as line coding), 158 but may work over a limited range of wavelength/frequencies. We see 159 that 2R regenerators are generally applicable to a single digital 160 stream and are dependent upon modulation format (line coding) and to 161 a lesser extent are limited to a range of bit rates (but not a 162 specific bit rate). Finally, 3R regenerators apply to a single 163 channel, are dependent upon the modulation format and generally 164 sensitive to the bit rate of digital signal, i.e., either are 165 designed to only handle a specific bit rate or need to be programmed 166 to accept and regenerate a specific bit rate. In all these types of 167 regenerators the digital bit stream(s) contained within the optical 168 or electrical is/(are) not modified. 170 In the most common usage of regenerators the digital bit stream may 171 be slightly modified for performance monitoring and fault management 172 purposes. SONET, SDH and G.709 all have a digital signal "envelope" 173 designed to be used between "regenerators" (in this case 3R 174 regenerators). In SONET this is known as the "section" signal, in SDH 175 this is known as the "regenerator section" signal, in G.709 this is 176 known as an OTUk (Optical Channel Transport Unit-k). These signals 177 reserve a portion of their frame structure (known as overhead) for 178 use by regenerators. The nature of this overhead is summarized in 179 Table 2. 181 Table 2. SONET, SDH, and G.709 regenerator related overhead. 183 +-----------------------------------------------------------------+ 184 |Function | SONET/SDH | G.709 OTUk | 185 | | Regenerator | | 186 | | Section | | 187 |------------------+----------------------+-----------------------| 188 |Signal | J0 (section | Trail Trace | 189 |Identifier | trace) | Identifier (TTI) | 190 |------------------+----------------------+-----------------------| 191 |Performance | BIP-8 (B1) | BIP-8 (within SM) | 192 |Monitoring | | | 193 |------------------+----------------------+-----------------------| 194 |Management | D1-D3 bytes | GCC0 (general | 195 |Communications | | communications | 196 | | | channel) | 197 |------------------+----------------------+-----------------------| 198 |Fault Management | A1, A2 framing | FAS (frame alignment | 199 | | bytes | signal), BDI(backward| 200 | | | defect indication)BEI| 201 | | | (backward error | 202 | | | indication) | 203 +------------------+----------------------+-----------------------| 204 |Forward Error | P1,Q1 bytes | OTUk FEC | 205 |Correction (FEC) | | | 206 +-----------------------------------------------------------------+ 208 In the previous table we see support for frame alignment, signal 209 identification, and FEC. What this table also shows by its omission 210 is that no switching or multiplexing occurs at this layer. This is a 211 significant simplification for the control plane since control plane 212 standards require a multi-layer approach when there are multiple 213 switching layers, but not for "layering" to provide the management 214 functions of Table 2. That is, many existing technologies covered by 215 GMPLS contain extra management related layers that are essentially 216 ignored by the control plane (though not by the management plane!). 217 Hence, the approach here is to include regenerators and other devices 218 at the WSON layer unless they provide higher layer switching and then 219 a multi-layer or multi-region approach [RFC5212] is called for. 221 In a sense dependence on client signal type represents a fourth 222 regenerator type, i.e., 4R, that includes all the capabilities and 223 restrictions of a 3R, 2R, and 1R, and in addition is depending upon 224 the format of the digital stream, i.e., these regenerators can accept 225 only one type of stream or must be programmed to accommodate 226 different stream types. 228 Hence we see that depending upon the regenerator technology we may 229 have the following constraints imposed by a regenerator device: 231 List 1. Network Element Compatibility Constraints 233 1. Limited wavelength range (1R) -- Already modeled in GMPLS for 234 WSON 236 2. Modulation type restriction (2R) 238 3. Bit rate range restriction (2R, 3R) 240 4. Exact bit rate restriction (3R) 242 5. Client signal dependence (4R) 244 1.2. OEO Switches 245 A common place where optical-to-electrical-to-optical (OEO) 246 processing may take place is in WSON switches that utilize (or 247 contain) regenerators. A vendor may add regenerators to a switching 248 system for a number of reasons. One obvious reason is to restore 249 signal quality either before or after optical processing (switching). 250 Another reason may be to convert the signal to an electronic form for 251 switching then reconverting to an optical signal prior to egress from 252 the switch. In this later case the regeneration is applied to adapt 253 the signal to the switch fabric regardless of whether or not it is 254 needed from a signal quality perspective. 256 In either case these optical switches have the following signal 257 processing restrictions that are essentially the same as those we 258 described for regenerators in List 1. 260 Note that a common system integration function in transport networks 261 is to add multi-channel WDM interfaces to electro-optical switching 262 systems such as G.709, SONET, SDH, IP, or Ethernet switching systems. 263 Although such systems may have high layer switching functionality 264 they, by their nature contain WSON functionality, though this maybe 265 in the form of fixed WDM multiplexing and de-multiplexing 266 functionality. See [WSON-FRAME] for how GMPLS WSON can model fixed 267 devices. If they only contain higher layer (IP, Ethernet, SONET path, 268 etc...) functionality then these systems act as a termination point 269 for the WSON switching layer, otherwise they look like a combination 270 of WSON end system and WSON switching system and could contain OEO 271 conversions. 273 Integrating WSON capabilities into electro-optical switching systems 274 brings the WSON network into the operational domain of these systems 275 and higher layer networks. By adding optical tributary attributes to 276 the GMPLS control protocols this draft enables the integration of 277 WSON subnetworks into the higher layer networks within which they 278 reside and to which they provide flexible connectivity. This 279 streamlines network operations by enabling a single request to 280 establish a connection across both electro-optical and all optical 281 elements within a higher layer network. The optical tributary 282 attributes for a connection may be set based on the related 283 attributes of the network element at the boundary of each new WSON 284 subnetwork traversed by the connection. 286 1.3. Wavelength Converters 287 In [WSON-FRAME] the motivation for utilizing wavelength converters 288 was discussed. In essence a wavelength converter would take one or 289 more optical channels on specific wavelengths and convert them to 290 corresponding new specific wavelengths. Currently all optical 291 wavelength converters exist but have not been widely deployed, hence 292 the majority of wavelength converters are based on demodulation to an 293 electrical signal and then re-modulation onto a new optical carrier, 294 i.e., an OEO process. This process is very similar to that used for a 295 regenerator except that the output optical wavelength will be 296 different from the input optical wavelength. Hence in general 297 wavelength converters have signal processing restrictions that are 298 essentially the same as those we described for regenerators in List 299 1: 301 (a) Limited input wavelength range (1R), Limited output wavelength 302 range 304 (b) Modulation type restriction (2R) 306 (c) Bit rate range restriction (2R, 3R) 308 (d) Exact bit rate restriction (3R) 310 (e) Client signal dependence (4R) 312 2. Describing Optical Signals in GMPLS 314 In the previous section we saw that each of the additional network 315 elements (OEO switches, regenerators, and wavelength converters) can 316 impose constraints on the types of signals they can "process". Hence 317 to enable the use of a larger set of network elements the first step 318 is to define and characterize our "optical signal". 320 2.1. Optical Interfaces 322 In wavelength switched optical networks (WSONs) our fundamental unit 323 of switching is intuitively that of a "wavelength". The transmitters 324 and receivers in these networks will deal with one wavelength at a 325 time, while the switching systems themselves can deal with multiple 326 wavelengths at a time. Hence we are generally concerned with 327 multichannel dense wavelength division multiplexing (DWDM) networks 328 with single channel interfaces. Interfaces of this type are defined 329 in ITU-T recommendations [G.698.1] and [G.698.1]. Key non-impairment 330 related parameters defined in [G.698.1] and [G.698.2] are: 332 (a) Minimum Channel Spacing (GHz) 334 (b) Bit-rate/Line coding of optical tributary signals 336 (c) Minimum and Maximum central frequency 338 We see that (a) and (c) above are related to properties of the link 339 and have been modeled in [Otani],[WSON-FRAME], [WSON-Info] and (b) is 340 related to the "signal". 342 2.2. Optical Tributary Signals 344 The optical interface specifications [G.698.1], [G.698.2], and 345 [G.959.1] all use the concept of an Optical Tributary Signal which is 346 defined as "a single channel signal that is placed within an optical 347 channel for transport across the optical network". Note the use of 348 the qualifier "tributary" to indicate that this is a single channel 349 entity and not a multichannel optical signal. This is our candidate 350 terminology for the entity that we will be controlling in our GMPLS 351 extensions for WSONs. 353 There are a currently a number of different "flavors" of optical 354 tributary signals, known as "optical tributary signal classes". These 355 are currently characterized by a modulation format and bit rate range 356 [G.959.1]: 358 (a) optical tributary signal class NRZ 1.25G 359 (b) optical tributary signal class NRZ 2.5G 361 (c) optical tributary signal class NRZ 10G 363 (d) optical tributary signal class NRZ 40G 365 (e) optical tributary signal class RZ 40G 367 Note that with advances in technology more optical tributary signal 368 classes will be added and that this is currently an active area for 369 standardization. 371 Note that according to [G.698.2] it is important to fully specify the 372 bit rate of the optical tributary signal: 374 "When an optical system uses one of these codes, therefore, it is 375 necessary to specify both the application code and also the exact bit 376 rate of the system. In other words, there is no requirement for 377 equipment compliant with one of these codes to operate over the 378 complete range of bit rates specified for its optical tributary 379 signal class." 381 Hence we see that modulation format (optical tributary signal class) 382 and bit rate are key in characterizing the optical tributary signal. 384 2.3. Proposed GMPLS WSON Signal Definition 385 We proposed to call the signal that we will be working with an 386 optical tributary signal like that defined in ITU-T G.698.1 and .2. 387 This is an "entity" that can be put on an optical communications 388 channel formed from links and network elements in a WSON. 390 An optical tributary signal has the following attributes: 392 List 2. Optical Tributary Signal Attributes 394 1. Optical tributary signal class: This relates to the specifics of 395 modulation format, and bit rate range. Could possibly change along 396 the path. For example when running through a 3R regenerator a 397 different output modulation format could be used. This could be 398 more prevalent if we are controlling combined metro and long haul 399 networks. 400 2. FEC: Indicates whether forward error correction is used in the 401 digital stream. Note that in [G.707] this is indicated in the 402 signal itself via the FEC status indication (FSI) byte, while in 404 [G.709] this can be inferred from whether the FEC field of the OTUk 405 is all zeros or not. 406 3. Bit rate. This typically would not change since we are not changing 407 the digital bit stream in any end-to-end meaningful way. 408 4. Center frequency (wavelength). Can change along path if there are 409 wavelength converters. This is already modeled via labels in GMPLS. 410 5. G-PID: General Protocol Identifier for the information format. This 411 would not change since this describes the encoded bit stream. This 412 is already present in GMPLS signaling. A set of G-PID values are 413 already defined for lambda switching in [RFC3471], [RFC4328]. 414 6. (Optional) A signal identifier or name distinguishing a particular 415 tributary signal from others in the network that may be used to 416 detect misconnection of signals. For example this can be used in 417 setting up the section trace in SDH or the trail trace identifier 418 in G.709 between format aware regenerators. This is not used in 419 determining signal compatibility with network elements and hence is 420 optional. 422 These attributes are used during RWA to select a compatible path for 423 the optical tributary signal. These attributes are used during 424 signaling to configure devices such as wavelength converters or 425 parameter sensitive devices such as 3R regenerators. Some of these 426 attributes such as wavelength may change as the optical tributary 427 signal traverses the path from source to sink. 429 2.4. Implications for GMPLS Signaling and PCEP 431 When establishing a connection or requesting a path computation the 432 attributes of the optical tributary signal given in List 2 in section 433 2.3. needs to be furnished. However of these five attributes two are 434 already supplied in GMPLS signaling: wavelength and G-PID. This 435 leaves only four new types of attributes: 437 1. Signal Class with possible qualifying parameters 439 2. Bit Rate 441 3. FEC information 443 4. Optional signal identifier 445 For RSVP-TE signaling these could be put in a new WSON T_SPEC object. 446 For PCEP these signal attributes would need to be included in various 447 request and response messages. 449 3. Characterizing WSON Network Elements in GMPLS 451 A number of processes may operate on an "optical tributary signal" as 452 it traverses a path through a network these include: Generation 453 (including modulation), Regeneration, Wavelength Conversion, 454 Switching and Reception (including demodulation). In any of these 455 processes a number of attributes of the "optical tributary signal" 456 may be either constrained or incompatible with those of the 457 processing elements. These attributes include: 459 (a) Optical tributary signal class (modulation format and 460 approximate bit rate, FEC) 462 (b) Exact bit rate 464 (c) Center frequency (wavelength) 466 (d) Digital stream format information 468 Qualification of a route involves determining that the route provides 469 a signal path capable of propagating the physical layer network 470 signal and meeting the input signal requirements of the termination 471 sink function (receiver). 473 Some of the previously mentioned attributes of our optical tributary 474 signal may change as the signal traverses its path across a network. 475 The most common of these would be center frequency (wavelength). 476 GMPLS signaling currently supports the specification of wavelength to 477 be used at a given point on a path. Less common, although, possible 478 would be a change in modulation format of the signal, particularly 479 after some type of OEO regeneration or switching. Currently GMPLS 480 signaling doesn't support indicating a change of modulation at a 481 particular point in the network. 483 The bulk of compatibility checking of network element capabilities 484 against optical tributary signal attributes would fall on the path 485 computation entity whose traffic engineering database is typically 486 constructed with the help of a link state IGP. Currently, only layer 487 type information is given in the form of the interface switching 488 capability descriptor (ISCD) from [RFC4202]. 490 3.1. Proposed Link and Network Element (NE) Model Extensions 491 Other drafts [WSON-FRAME],[WSON-Info] provide NE models that include 492 switching asymmetry and port wavelength constraints here we add 493 parameters to our existing node and link models to take into account 494 restrictions on the optical tributary signal attributes that a 495 network element can accept. These are: 497 1. Permitted optical tributary signal classes: A list of optical 498 tributary signal classes that can be processed by this network 499 element or carried over this link. 500 2. Acceptable Bit Rate Set: A list of specific bit rates or bit rate 501 ranges that the device can accommodate. Coarse bit rate info is 502 included with the optical tributary signal class restrictions. 503 3. Acceptable G-PID list: A list of G-PIDs corresponding to the 504 "client" digital streams that are compatible with this device. 506 Note that such parameters could be specified on an (a) Network 507 element wide basis, (b) a per port basis, (c) on a per regenerator 508 basis. Typically such information has been on a per port basis, 509 e.g., the GMPLS interface switching capability descriptor [RFC4202]. 510 However, in [WSON-FRAME] we give examples of shared wavelength 511 converters within a switching system, and hence this would be on a 512 subsystem basis. The exact form would be defined in the [WSON-Info] 513 and [WSON-Encoding] drafts. 515 4. Security Considerations 517 This document has no requirement for a change to the security models 518 within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, 519 and PCEP [RFC5540] security models could be operated unchanged. 521 Furthermore the additional information distributed in order to extend 522 GMPLS capabilities to the additional network elements discussed in 523 this document represents a disclosure of network capabilities that an 524 operator may wish to keep private. Consideration should be given to 525 securing this information. 527 5. IANA Considerations 529 This document makes no request for IANA actions. 531 6. Acknowledgments 533 This document was prepared using 2-Word-v2.0.template.dot. 535 7. References 537 7.1. Normative References 539 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 540 (GMPLS) Signaling Functional Description", RFC 3471, 541 January 2003. 543 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support 544 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 545 4202, October 2005. 547 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 548 Switching (GMPLS) Signaling Extensions for G.709 Optical 549 Transport Networks Control", RFC 4328, January 2006. 551 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 552 applications: DWDM frequency grid", June, 2002. 554 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 555 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 556 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 557 2008. 559 [RFC5540] J.P. Vasseur and J.L. Le Roux (Editors), "Path Computation 560 Element (PCE) Communication Protocol (PCEP)", RFC 5540, 561 March 2009. 563 [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 564 and PCE Control of Wavelength Switched Optical Networks 565 (WSON)", draft-ietf-ccamp-rwa-wson-framework-02.txt, March 566 2009. 568 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 569 Wavelength Assignment Information for Wavelength Switched 570 Optical Networks", draft-bernstein-ccamp-wson-info-03.txt, 571 March, 2009. 573 [WSON-Encoding] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 574 Wavelength Assignment Information Encoding for Wavelength 575 Switched Optical networks", work in progress, draft-ietf- 576 ccamp-rwa-wson-encode-01.txt, March 2009. 578 7.2. Informative References 580 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 581 Labels for G.694 Lambda-Switching Capable Label Switching 582 Routers (LSR)", work in progress, draft-ietf-ccamp-gmpls-g- 583 694-lambda-labels-04.txt 585 [G.872] ITU-T Recommendation G.872, Architecture of optical 586 transport networks, November 2001. 588 [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network 589 Physical Layer Interfaces, March 2006. 591 Author's Addresses 593 Greg M. Bernstein 594 Grotto Networking 595 Fremont California, USA 597 Phone: (510) 573-2237 598 Email: gregb@grotto-networking.com 600 Young Lee 601 Huawei Technologies 602 1700 Alma Drive, Suite 100 603 Plano, TX 75075 604 USA 606 Phone: (972) 509-5599 (x2240) 607 Email: ylee@huawei.com 609 T. Benjamin Mack-Crane 610 Huawei Technologies 611 Downers Grove, Illinois 613 Email: tmackcrane@huawei.com 615 Intellectual Property Statement 617 The IETF Trust takes no position regarding the validity or scope of 618 any Intellectual Property Rights or other rights that might be 619 claimed to pertain to the implementation or use of the technology 620 described in any IETF Document or the extent to which any license 621 under such rights might or might not be available; nor does it 622 represent that it has made any independent effort to identify any 623 such rights. 625 Copies of Intellectual Property disclosures made to the IETF 626 Secretariat and any assurances of licenses to be made available, or 627 the result of an attempt made to obtain a general license or 628 permission for the use of such proprietary rights by implementers or 629 users of this specification can be obtained from the IETF on-line IPR 630 repository at http://www.ietf.org/ipr 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 any standard or specification contained in an IETF Document. Please 636 address the information to the IETF at ietf-ipr@ietf.org. 638 Disclaimer of Validity 640 All IETF Documents and the information contained therein are provided 641 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 642 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 643 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 644 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 645 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 646 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 647 FOR A PARTICULAR PURPOSE. 649 Acknowledgment 651 Funding for the RFC Editor function is currently provided by the 652 Internet Society.