idnits 2.17.1 draft-bernstein-ccamp-wson-info-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 602. 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 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 (July 7, 2008) is 5769 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.7715' is mentioned on line 231, but not defined == Unused Reference: 'RFC3784' is defined on line 477, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-03) exists of draft-bernstein-ccamp-wavelength-switched-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). 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: January 2009 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 July 7, 2008 11 Routing and Wavelength Assignment Information Model for Wavelength 12 Switched Optical Networks 14 draft-bernstein-ccamp-wson-info-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on January 7, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document provides an information model of information needed by 49 the routing and wavelength assignment (RWA) process in wavelength 50 switched optical networks (WSONs). The purpose of information 51 described in this model is to facilitate constrained lightpath 52 computation in WSONs. In particular in cases where there are no or a 53 limited number of wavelength converters available in the WSON. This 54 model currently does not include optical impairments. 56 Table of Contents 58 1. Introduction...................................................3 59 2. Terminology....................................................3 60 3. Routing and Wavelength Assignment Information Model............4 61 3.1. Dynamic and Relatively Static Information.................4 62 3.2. Node Information..........................................4 63 3.2.1. Switched Connectivity Matrix.........................5 64 3.2.2. Fixed Connectivity Matrix............................5 65 3.2.3. Shared Risk Node Group...............................6 66 3.2.4. Wavelength Converter Pool............................6 67 3.2.4.1. OEO Wavelength Converter Info...................6 68 3.3. Link Information..........................................7 69 3.3.1. Link ID..............................................7 70 3.3.2. Administrative Group.................................8 71 3.3.3. Interface Switching Capability Descriptor............8 72 3.3.4. Link Protection Type (for this link).................8 73 3.3.5. Shared Risk Link Group Information...................8 74 3.3.6. Traffic Engineering Metric...........................8 75 3.3.7. Maximum Bandwidth Per Channel........................8 76 3.3.8. Switched and Fixed Port Wavelength Restrictions......9 77 3.4. Dynamic Link Information.................................10 78 3.5. Dynamic Node Information.................................10 79 4. Security Considerations.......................................10 80 5. IANA Considerations...........................................11 81 6. Acknowledgments...............................................11 82 7. References....................................................12 83 7.1. Normative References.....................................12 84 7.2. Informative References...................................12 85 8. Contributors..................................................13 86 Author's Addresses...............................................13 87 Intellectual Property Statement..................................14 88 Disclaimer of Validity...........................................15 90 1. Introduction 92 The purpose of the following information model for WSONs is to 93 facilitate constrained lightpath computation and as such this is not 94 a general purpose network management information model. In particular 95 this model has particular value in the cases where there are no or a 96 limited number of wavelength converters available in the WSON. This 97 constraint is frequently referred to as the "wavelength continuity" 98 constraint, and the corresponding constrained lightpath computation 99 is known as the routing and wavelength assignment (RWA) problem. 100 Hence the information model must provide sufficient topology and 101 wavelength restriction and availability information to support this 102 computation. More details on the RWA process and WSON subsystems and 103 their properties can be found in [WSON-Frame]. The model defined here 104 does not currently include impairments however optical impairments 105 can be accommodated by the general framework presented here. 107 2. Terminology 109 CWDM: Coarse Wavelength Division Multiplexing. 111 DWDM: Dense Wavelength Division Multiplexing. 113 FOADM: Fixed Optical Add/Drop Multiplexer. 115 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 116 count wavelength selective switching element featuring ingress and 117 egress line side ports as well as add/drop side ports. 119 RWA: Routing and Wavelength Assignment. 121 Wavelength Conversion. The process of converting an information 122 bearing optical signal centered at a given wavelength to one with 123 "equivalent" content centered at a different wavelength. Wavelength 124 conversion can be implemented via an optical-electronic-optical (OEO) 125 process or via a strictly optical process. 127 WDM: Wavelength Division Multiplexing. 129 Wavelength Switched Optical Network (WSON): A WDM based optical 130 network in which switching is performed selectively based on the 131 center wavelength of an optical signal. 133 3. Routing and Wavelength Assignment Information Model 135 We group the following WSON RWA information model into four 136 categories regardless of whether they stem from a switching subsystem 137 or from a line subsystem: 139 o Node Information 141 o Link Information 143 o Dynamic Node Information 145 o Dynamic Link Information 147 Note that this is roughly the categorization used in [G.7715] section 148 7. 150 In the following we use a BNF/Regular expression like syntax where 151 the symbol "|" indicates a choice between two or more elements; the 152 symbol "*" indicates zero or more occurrences of an element; the 153 symbol "?" indicates zero or one occurrences; and the symbol "+" 154 indicates one or more occurrences. 156 3.1. Dynamic and Relatively Static Information 158 All the RWA information of concern in a WSON network is subject to 159 change over time. Equipment can be upgraded; links may be placed in 160 or out of service and the like. However, from the point of view of 161 RWA computations there is a difference between information that can 162 change with each successive connection establishment in the network 163 and that information that is relatively static on the time scales of 164 connection establishment. A key example of the former is link 165 wavelength usage since this can change with connection setup/teardown 166 and this information is a key input to the RWA process. Examples of 167 relatively static information are the internal connectivity of a WDM 168 ROADM, and the channel spacing on a WDM link. 170 In this document we will separate, where possible, dynamic and static 171 information so that these can be kept separate in possible encodings 172 and hence allowing for separate updates of these two types of 173 information thereby reducing processing and traffic load caused by 174 the timely distribution of the more dynamic RWA WSON information. 176 3.2. Node Information 178 The node information described here contains the relatively static 179 information related to a WSON node. This includes connectivity 180 constraints amongst ports and wavelengths since WSON switches can 181 exhibit asymmetric switching properties. Additional information could 182 include properties of wavelength converters in the node if any are 183 present. In [Switch] it was shown that the wavelength connectivity 184 constraints for a large class of practical WSON devices can be 185 modeled via switched and fixed connectivity matrices along with 186 corresponding switched and fixed port constraints. We include these 187 connectivity matrices with our node information the switched and 188 fixed port wavelength constraints with the link information. 190 Formally, 192 Node Information := Node_ID, SwitchedConnectivityMatrix?, 193 FixedConnectivityMatrix?, SRNG?, WavelengthConverterPool? 195 Where the Node_ID would be an appropriate identifier for the node 196 within the WSON RWA context. 198 3.2.1. Switched Connectivity Matrix 200 The switched connectivity matrix (SwitchConnectivityMatrix) 201 represents the potential connectivity matrix for asymmetric switches 202 (e.g. ROADMs and such). This is a conceptual M by N matrix 203 representing the switched connectivity, where M represents the number 204 of ingress ports and N the number of egress ports. We say this is a 205 "conceptual" since this matrix tends to exhibit structure that allows 206 for very compact representations that are useful for both 207 transmission and path computation [Encode] 209 SwitchedConnectivityMatrix(i, j) = 0 or 1 depending on whether 210 ingress port i can connect to egress port j for one or more 211 wavelengths. 213 3.2.2. Fixed Connectivity Matrix 215 The fixed connectivity matrix (FixedConnectivityMatrix) represents 216 the connectivity for asymmetric fixed devices or the fixed part of a 217 "hybrid" device [Switch]. This is a conceptual M by N matrix, where M 218 represents the number of ingress ports and N the number of egress 219 ports. We say this is a "conceptual" since this matrix tends to 220 exhibit structure that allows for very compact representations. 222 FixedConnectivityMatrix(i, j) = 0 or 1 depending on whether ingress 223 port i is connected to egress port j for one or more wavelengths. 225 3.2.3. Shared Risk Node Group 227 SRNG: Shared risk group for nodes. The concept of a shared risk link 228 group was defined in [RFC4202]. This can be used to achieve a desired 229 "amount" of link diversity. It is also desirable to have a similar 230 capability to achieve various degrees of node diversity. This is 231 explained in [G.7715]. Typical risk groupings for nodes can include 232 those nodes in the same building, within the same city, or geographic 233 region. 235 3.2.4. Wavelength Converter Pool 237 A WSON node may include wavelength converters. These are usually 238 arranged into some type of pool to promote resource sharing. There 239 are a number of different approaches used in the design of switches 240 with converter pools. However, from the point of view of path 241 computation we need to know the following: 243 1. The nodes that support wavelength conversion. 245 2. The accessibility of the wavelength converter pool from a 246 particular port and wavelength. 248 3. Limitations on the types of signals that can be converted and the 249 conversions that can be performed. 251 A general representation of the converter pool with respect to 252 resource availability from a particular port and wavelength is TBD 253 and will be furnished in a subsequent revision of this draft. 254 Particular types of individual wavelength converters, such as those 255 based on an OEO approach can be characterized fairly completely as 256 specified below. 258 3.2.4.1. OEO Wavelength Converter Info 260 An OEO based wavelength converter can be characterized by an input 261 wavelength set and an output wavelength set. In addition any 262 constraints on the signal formats and rates accommodated by the 263 converter must be described. Such a wavelength converter can be 264 modeled by: 266 OEOWavelengthConverterInfo := RegeneratorType, 267 IngressWavelengthRange, EgressWavelengthRange, BitRateRange?, 268 AcceptableSignals? 270 Where the RegeneratorType is used to model an OEO regenerator. 271 Regenerators are usually classified into three types. Level 1 272 provides signal amplification, level 2 amplification and pulse 273 shaping, and level 3 amplification, pulse shaping and timing 274 regeneration. Level 2 regenerators can have a restricted bit rate 275 range, while level 3 regenerators can also be specialized to a 276 particular signal type. 278 IngressWavelengthRange and EgressWavelengthRange are sets of 279 wavelengths that characterize the input wavelengths acceptable to the 280 wavelength converter and the outputs that can be generated by the 281 wavelength converter. 283 BitRateRange: indicates the range of bit rates that can be 284 accommodated by the wavelength converter. 286 AcceptableSignals: is a list of signals that the wavelength converter 287 can handle. This could be fairly general for Level 1 and Level 2 288 regenerators, e.g., characterized by general signal properties such 289 as modulation type and related parameters, or fairly specific signal 290 types for Level 3 based regenerators. 292 3.3. Link Information 294 MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630, 295 RFC3784] along with GMPLS routing protocol extensions for OSPF and 296 IS-IS [RFC4203, RFC4205] provide the bulk of the relatively static 297 link information needed by the RWA process. WSON networks bring in 298 additional link related constraints. These stem from WDM line system 299 characterization, laser transmitter tuning restrictions, and 300 switching subsystem port wavelength constraints, e.g., colored ROADM 301 drop ports. 303 In the following summarize both information from existing route 304 protocols and new information that maybe needed by the RWA process. 306 LinkInfo := LinkID, AdministrativeGroup?, InterfaceCapDesc?, 307 Protection?, SRLG*, TrafficEngineeringMetric?, 308 MaximumBandwidthPerChannel?, SwitchedPortWavelengthRestriction?, 309 FixedPortWavelengthRestriction? 311 3.3.1. Link ID 313 LinkID: LocalLinkID, LocalNodeID, RemoteLinkID, RemoteNodeID 315 Here we can generally identify a link via a combination of local and 316 remote node identifiers along with the corresponding local and remote 317 link identifiers per [RFC4202, RFC4203, RFC4205]. Note that reference 319 [RFC3630] provides other ways to identify local and remote link ends 320 in the case of numbered links. 322 3.3.2. Administrative Group 324 AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds 325 to one administrative group assigned to the interface. A link may 326 belong to multiple groups. This is a configured quantity and can be 327 used to influence routing decisions. 329 3.3.3. Interface Switching Capability Descriptor 331 InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different 332 switching capabilities on this GMPLS interface. In both [RFC4203] and 333 [RFC4205] this information gets combined with the maximum LSP 334 bandwidth that can be used on this link at eight different priority 335 levels. 337 3.3.4. Link Protection Type (for this link) 339 Protection: Defined in [RFC4202] and implemented in [RFC4203, 340 RFC4205]. Used to indicate what protection, if any, is guarding this 341 link. 343 3.3.5. Shared Risk Link Group Information 345 SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC4205]. 346 This allows for the grouping of links into shared risk groups, i.e., 347 those links that are likely, for some reason, to fail at the same 348 time. 350 3.3.6. Traffic Engineering Metric 352 TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the 353 definition of one additional link metric value for traffic 354 engineering separate from the IP link state routing protocols link 355 metric. Note that multiple "link metric values" could find use in 356 optical networks, however it would be more useful to the RWA process 357 to assign these specific meanings such as link mile metric, or 358 probability of failure metric, etc... 360 3.3.7. Maximum Bandwidth Per Channel 362 TBD: Need to check if we still want this. 364 3.3.8. Switched and Fixed Port Wavelength Restrictions 366 Switch and fixed port wavelength 367 restrictions(SwitchedPortWavelengthRestriction, 368 FixedPortWavelengthRestriction) model the wavelength restrictions 369 that various optical devices such as OXCs, ROADMs, and waveband 370 mulitplexers may impose on a port. This plays an important role in 371 fully characterizing a WSON switching device[Switch]. The 372 SwitchedPortWavelengthRestriction is used with ports specified in the 373 SwitchedConnectivityMatrix while the FixedPortWavelengthRestriction 374 is used with ports specified in the FixedConnectivityMatrix. 375 Reference [Switch] gives an example where both switch and fixed 376 connectivity matrices are used and both types of constraints are 377 occur on the same port. 379 SwitchedPortWavelengthRestriction := PortWavelengthRestriction 381 FixedPortWavelengthRestriction := PortWavelengthRestriction 383 PortWavelengthRestriction := RestrictionKind, RestrictionParameters, 384 WavelengthSet 386 RestrictionParameters := MaxNumChannels, OthersTBD? 388 Where WavelengthSet is a conceptual set of wavelengths, 389 MaxNumChannels is the number of channels permitted on the port, and 390 RestrictionKind can take the following values and meanings: 392 SIMPLE: Simple wavelength selective restriction. Max number of 393 channels indicates the number of wavelengths permitted on the port 394 and the accompanying wavelength set indicates the permitted values. 396 WAVEBAND1: Waveband device with a tunable center frequency and 397 passband. In this case the maximum number of channels indicates the 398 maximum width of the waveband in terms of the channels spacing given 399 in the wavelength set. The corresponding wavelength set is used to 400 indicate the overall tuning range. Specific center frequency tuning 401 information can be obtained from dynamic channel in use information. 402 It is assumed that both center frequency and bandwidth (Q) tuning can 403 be done without causing faults in existing signals. 405 For example, if the port is a "colored" drop port of a ROADM then the 406 value of RestrictionKind = SIMPLE for a simple wavelength selective 407 restriction, the MaxNumberOfChannels = 1, and the wavelength 408 restriction is just a wavelength set consisting of a single member 409 corresponding to the frequency of the permitted wavelength. See 410 [Switch] for a complete waveband example. 412 3.4. Dynamic Link Information 414 By dynamic information we mean information that is subject to change 415 on a link with subsequent connection establishment or teardown. 416 Currently for WSON the only information we currently envision is 417 wavelength availability and wavelength in use for shared backup 418 purposes. 420 DynamicLinkInfo := LinkID, AvailableWavelengths, 421 SharedBackupWavelengths? 423 Where 425 LinkID: LocalLinkID, LocalNodeID, RemoteLinkID, RemoteNodeID 427 AvailableWavelengths is a set of wavelengths available on the link. 429 SharedBackupWavelengths is a set of wavelengths currently used for 430 shared backup protection on the link. An example usage of this 431 information in a WSON setting is given in [Shared]. 433 3.5. Dynamic Node Information 435 Dynamic node information is used to hold information for a node that 436 can change frequently. Currently only wavelength converter pool 437 information is included as a possible (but not required) information 438 sub-element. 440 DynamicNodeInfo := NodeID, WavelengthConverterPoolStatus? 442 Where NodeID is a node identifier and the exact form of the 443 wavelength converter pool status information is TBD. 445 4. Security Considerations 447 This document discussed an information model for RWA computation in 448 WSONs. Such a model is very similar from a security standpoint of the 449 information that can be currently conveyed via GMPLS routing 450 protocols. Such information includes network topology, link state 451 and current utilization, and well as the capabilities of switches and 452 routers within the network. As such this information should be 453 protected from disclosure to unintended recipients. In addition, the 454 intentional modification of this information can significantly affect 455 network operations, particularly due to the large capacity of the 456 optical infrastructure to be controlled. 458 5. IANA Considerations 460 This informational document does not make any requests for IANA 461 action. 463 6. Acknowledgments 465 This document was prepared using 2-Word-v2.0.template.dot. 467 7. References 469 7.1. Normative References 471 [Encode] Reference the encoding draft here. 473 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 474 (TE) Extensions to OSPF Version 2", RFC 3630, September 475 2003. 477 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 478 System (IS-IS) Extensions for Traffic Engineering (TE)", 479 RFC 3784, June 2004. 481 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 482 in Support of Generalized Multi-Protocol Label Switching 483 (GMPLS)", RFC 4202, October 2005 485 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 486 Support of Generalized Multi-Protocol Label Switching 487 (GMPLS)", RFC 4203, October 2005. 489 [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate 490 System to Intermediate System (IS-IS) Extensions in Support 491 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 492 4205, October 2005. 494 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 495 and PCE Control of Wavelength Switched Optical Networks", 496 work in progress: draft-bernstein-ccamp-wavelength- 497 switched-02.txt, February 2008. 499 7.2. Informative References 501 [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in PCE- 502 based WSON Networks", iPOP 2008, http://www.grotto- 503 networking.com/wson/iPOP2008_WSON-shared-mesh-poster.pdf . 505 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 506 WDM Wavelength Switching Systems for use in Automated Path 507 Computation", http://www.grotto- 508 networking.com/wson/ModelingWSONswitchesV2a.pdf , June, 2008 510 8. Contributors 512 Diego Caviglia 513 Ericsson 514 Via A. Negrone 1/A 16153 515 Genoa Italy 517 Phone: +39 010 600 3736 518 Email: diego.caviglia@(marconi.com, ericsson.com) 520 Anders Gavler 521 Acreo AB 522 Electrum 236 523 SE - 164 40 Kista Sweden 525 Email: Anders.Gavler@acreo.se 527 Jonas Martensson 528 Acreo AB 529 Electrum 236 530 SE - 164 40 Kista, Sweden 532 Email: Jonas.Martensson@acreo.se 534 Itaru Nishioka 535 NEC Corp. 536 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 537 Japan 539 Phone: +81 44 396 3287 540 Email: i-nishioka@cb.jp.nec.com 542 Lyndon Ong 543 Ciena 544 Email: lyong@ciena.com 546 Author's Addresses 548 Greg Bernstein (ed.) 549 Grotto Networking 550 Fremont, CA, USA 552 Phone: (510) 573-2237 553 Email: gregb@grotto-networking.com 554 Young Lee (ed.) 555 Huawei Technologies 556 1700 Alma Drive, Suite 100 557 Plano, TX 75075 558 USA 560 Phone: (972) 509-5599 (x2240) 561 Email: ylee@huawei.com 563 Dan Li 564 Huawei Technologies Co., Ltd. 565 F3-5-B R&D Center, Huawei Base, 566 Bantian, Longgang District 567 Shenzhen 518129 P.R.China 569 Phone: +86-755-28973237 570 Email: danli@huawei.com 572 Wataru Imajuku 573 NTT Network Innovation Labs 574 1-1 Hikari-no-oka, Yokosuka, Kanagawa 575 Japan 577 Phone: +81-(46) 859-4315 578 Email: imajuku.wataru@lab.ntt.co.jp 580 Intellectual Property Statement 582 The IETF takes no position regarding the validity or scope of any 583 Intellectual Property Rights or other rights that might be claimed to 584 pertain to the implementation or use of the technology described in 585 this document or the extent to which any license under such rights 586 might or might not be available; nor does it represent that it has 587 made any independent effort to identify any such rights. Information 588 on the procedures with respect to rights in RFC documents can be 589 found in BCP 78 and BCP 79. 591 Copies of IPR disclosures made to the IETF Secretariat and any 592 assurances of licenses to be made available, or the result of an 593 attempt made to obtain a general license or permission for the use of 594 such proprietary rights by implementers or users of this 595 specification can be obtained from the IETF on-line IPR repository at 596 http://www.ietf.org/ipr. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at 602 ietf-ipr@ietf.org. 604 Disclaimer of Validity 606 This document and the information contained herein are provided on an 607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 609 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 610 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 611 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 614 Copyright Statement 616 Copyright (C) The IETF Trust (2008). 618 This document is subject to the rights, licenses and restrictions 619 contained in BCP 78, and except as set forth therein, the authors 620 retain all their rights. 622 Acknowledgment 624 Funding for the RFC Editor function is currently provided by the 625 Internet Society.