idnits 2.17.1 draft-zhang-ccamp-rwa-wson-routing-ospf-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 324 has weird spacing: '... Type sub-...' == Line 339 has weird spacing: '... Type sub-...' -- The document date (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RWA-Encode' is mentioned on line 270, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 308, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 308, but not defined == Unused Reference: 'RFC3471' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'Lambda-Labels' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'Switch' is defined on line 410, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-gmpls-g-694-lambda-labels-03 -- No information found for draft-ietf-ccamp-rwa-WSON-Framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'WSON-Frame' == Outdated reference: A later version (-24) exists of draft-ietf-ccamp-rwa-info-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-rwa-info (ref. 'WSON-Info') == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-rwa-wson-encode-00 ** Downref: Normative reference to an Informational draft: draft-li-ccamp-wson-igp-eval (ref. 'WSON-IGP-Eval') -- Possible downref: Non-RFC (?) normative reference: ref. 'Switch' Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Fatai Zhang 2 Internet Draft Young Lee 3 Intended status: Standards Track Jianrui Han 4 Expires: January 2010 Huawei 5 G. Bernstein 6 Grotto Networking 7 Yunbin Xu 8 CATR 9 July 13, 2009 11 OSPF Extensions in Support of Routing and Wavelength 12 Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) 14 draft-zhang-ccamp-rwa-wson-routing-ospf-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 13, 2010. 39 Abstract 41 This document describes OSPF routing protocols extensions to support 42 Routing and Wavelength Assignment (RWA) in Wavelength Switched 43 Optical Networks (WSON) under the control of Generalized MPLS (GMPLS). 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [RFC2119]. 51 Table of Contents 53 1. Introduction.................................................2 54 2. Node Information.............................................3 55 2.1. Connectivity Matrix.....................................4 56 2.2. Wavelength Converter Pool...............................4 57 2.2.1. Wavelength Converter Accessibility.................4 58 2.2.2. Wavelength Conversion Range........................5 59 2.2.3. WC Usage State.....................................5 60 3. Link Information.............................................5 61 3.1. WSON Port Wavelength Restrictions.......................6 62 3.2. Available Wavelengths...................................6 63 3.3. Shared Backup Wavelengths...............................6 64 4. Procedures for Routing Flooding..............................7 65 5. Security Considerations......................................7 66 6. IANA Considerations..........................................7 67 6.1. Node Information........................................8 68 6.2. Link Information........................................8 69 7. References...................................................8 70 8. Authors' Addresses...........................................11 71 Acknowledgment..................................................12 73 1. Introduction 75 Wavelength switched optical networks (WSONs) are based on Wavelength 76 Division Multiplexing (WDM) in which user traffic is carried by data 77 channels of different optical wavelengths. In traditional WDM 78 Networks, each wavelength path is statically configured. With the 79 deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 80 photonic cross-connects (PXCs), and tunable laser, WSONs have become 81 more dynamic, and operators can flexibly set up wavelength paths to 82 carry user traffic. 84 In WSONs where there are no or a limited number of switches capable 85 of wavelength conversion paths must be set up subject to the 86 "wavelength continuity" constraint. This leads to a path computation 87 problem known as routing and wavelength assignment (RWA). In order to 88 perform such computations, it is necessary to collect information 89 about the available wavelengths within the network. 91 [WSON-Frame] provides a framework for applying GMPLS [RFC3945] and 92 the Path Computation Element (PCE) architecture [RFC4655] to the 93 control of WSONs to address the RWA problem. [WSON-Info] describes an 94 information model that specifies the information needed at various 95 points in a WSON in order to compute paths and establish Label 96 Switched Paths (LSPs). Based on the information model of [WSON-Info], 97 [WSON-Encode] provides efficient protocol-independent encodings of 98 the information needed by the RWA process in a WSON. Such encodings 99 can be used to extend GMPLS signaling and routing protocols. 101 Therefore, in order to enable GMPLS to support Routing and Wavelength 102 Assignment (RWA) in Wavelength Switched Optical Networks (WSON) 103 networks, this document follows on from [WSON-Info], [WSON-Encode], 104 and [WSON-IGP-Eval] to define extensions to the OSPF routing protocol 105 to enhance the Traffic Engineering (TE) properties of GMPLS TE which 106 are defined in [RFC3630], [RFC4202], and [RFC4203]. The enhancements 107 to the Traffic Engineering (TE) properties of GMPLS TE links can be 108 announced in OSPF TE LSAs. The TE LSA, which is an opaque LSA with 109 area flooding scope [RFC3630], has only one top-level 110 Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs 111 for extensibility. The top-level TLV can take one of three values (1) 112 Router Address [RFC3630], (2) Link [RFC3630], (3) Node Attribute 113 [OSPF-Node]. In this document, we enhance the sub-TLVs for the Link 114 TLV and Node Attribute TLV in support of RWA in WSON under the 115 control of GMPLS. 117 The detail encoding of OSPF extensions is not defined in this 118 document. [WSON-Encode] provides encoding detail. 120 No consideration of optical impairment routing related information is 121 included in this document. 123 2. Node Information 125 According to [WSON-Info] and [WSON-Encode], the node information 126 about WSON nodes includes Node ID, connectivity matrix, wavelength 127 converter pool information. Except for the Node ID which should 128 comply with Routing Address described in [RFC3630], the other pieces 129 of information are defined in this document. 131 [OSPF-Node] defines a new top TLV named the Node Attribute TLV which 132 carries attributes related to a router/node. This Node Attribute TLV 133 contains one or more sub-TLVs. 135 From [WSON-Encode] we have identified the following new Sub-TLVs that 136 must be supported that can be nested under Node Attribute TLV. Detail 137 description for each newly defined Sub-TLV is provided in subsequent 138 sections: 140 Sub-TLV Type Length Name 142 TBD variable Connectivity Matrix 144 TBD variable Wavelength Converter Accessibility 146 TBD variable Wavelength Conversion Range 148 TBD variable WC Usage State 150 2.1. Connectivity Matrix 152 It is necessary to identify which ingress ports and wavelengths can 153 be connected to (the same wavelength on) a specific egress port, 154 because the switching devices in a WSON are highly asymmetric. 156 The Connectivity Matrix is used to identify these restrictions, which 157 can represent either the potential connectivity matrix for asymmetric 158 switches (e.g. ROADMs and such) or fixed connectivity for an 159 asymmetric device such as a multiplexer as defined in [WSON-Info]. 161 The Connectivity Matrix is a sub-TLV (the type is TBD by IANA) of the 162 Node Attribute TLV. The length is the length of value field in octets. 163 The meaning and format of this sub-TLV are defined in [WSON-Info] and 164 [WSON-Encode]. One sub-TLV contains one matrix. The Connectivity 165 Matrix sub-TLV may occur more than once to contain multi-matrices 166 within the Node Attribute TLV. 168 2.2. Wavelength Converter Pool 170 A WSON node may include wavelength converters. The encoding of 171 structure and properties of a general wavelength converter pool 172 utilizes a converter accessibility sub-TLV, a wavelength converter 173 range sub-TLV, and a wavelength converter state sub-TLV as described 174 in [WSON-Encode]. 176 2.2.1. Wavelength Converter Accessibility 178 Wavelength Converter Accessibility represents the ability of an 179 ingress port to reach a wavelength converter and of a wavelength 180 converter to reach a particular egress port as described in [WSON- 181 Encode]. 183 The Wavelength Converter Accessibility is a sub-TLV (the type is TBD 184 by IANA) of the Node Attribute TLV. The length is the length of value 185 field in octets. The meaning and format of this sub-TLV are defined 186 in [WSON-Info] and [WSON-Encode]. The Wavelength Converter 187 Accessibility sub-TLV may occur at most once within the Node 188 Attribute TLV. 190 2.2.2. Wavelength Conversion Range 192 Wavelength converters may have a limited input or output range which 193 can be described using one or more Wavelength Conversion Range sub- 194 TLV as described in [WSON-Encode]. 196 The Wavelength Converter Range is a sub-TLV (the type is TBD by IANA) 197 of the Node Attribute TLV. The length is the length of value field in 198 octets. The meaning and format of this sub-TLV are defined in [WSON- 199 Info] and [WSON-Encode]. The Wavelength Converter Range sub-TLV may 200 occur more than once within the Node Attribute TLV. 202 2.2.3. WC Usage State 204 WC Usage Sate indicates the usage state of wavelength converters as 205 described in [WSON-Encode] 207 The WC Usage State is a sub-TLV (the type is TBD by IANA) of the Node 208 Attribute TLV. The length is the length of value field in octets. The 209 meaning and format of this sub-TLV are defined in [WSON-Info] and 210 [WSON-Encode]. The WC Usage State sub-TLV may occur at most once 211 within the Node Attribute TLV. 213 3. Link Information 215 The most common link sub-TLVs nested to link top-level TLV are 216 already defined in [RFC3630], [RFC4203]. For example, Link ID, 217 Administrative Group, Interface Switching Capability Descriptor 218 (ISCD), Link Protection Type, Shared Risk Link Group Information 219 (SRLG), and Traffic Engineering Metric are among the typical link 220 sub-TLVs. 222 For WSONs, per [WSON-Info] and [WSON-Encode], we add the following 223 additional link sub-TLVs to the link-TLV in this document. 225 Sub-TLV Type Length Name 227 TBD variable WSON Port Wavelength Restrictions 228 TBD variable Available Wavelengths 230 TBD variable Shared Backup Wavelengths 232 3.1. WSON Port Wavelength Restrictions 234 Port Wavelength Restrictions describes the wavelength (label) 235 restrictions that the link and various optical devices such as OXCs, 236 ROADMs, and waveband multiplexers may impose on a port. These 237 restrictions represent what wavelength may or may not be used on a 238 link and are relatively static. The detailed information about Port 239 wavelength restrictions is described in [WSON-Info]. 241 The WSON Port Wavelength Restrictions is a sub-TLV (the type is TBD 242 by IANA) of the Link TLV. The length is the length of value field in 243 octets. The meaning and format of this sub-TLV are defined in [WSON- 244 Info] and [WSON-Encode]. The WSON Port Wavelength Restrictions sub- 245 TLV may occur more than once to specify a complex port constraint 246 within the link TLV. 248 3.2. Available Wavelengths 250 Available Wavelengths indicates the wavelengths available for use on 251 a link as described in [RWA-Encode].The Available Wavelengths is a 252 sub-TLV (the type is TBD by IANA) of the Link TLV. The length is the 253 length of value field in octets. The meaning and format of this sub- 254 TLV are defined in [WSON-Info] and [WSON-Encode]. The Available 255 Wavelengths sub-TLV may occur at most once within the link TLV. 257 Note that there are five approaches for Wavelength Set which is used 258 to represent the Available Wavelengths described in [WSON-Encode]. 259 Considering that the continuity of the available or unavailable 260 wavelength set can be scattered for the dynamic wavelength 261 availability, so it may burden the routing to reorganize the 262 wavelength set information when the Inclusive (/Exclusive) List 263 (/Range) approaches are used to represent Available Wavelengths 264 information. Therefore, it is RECOMMENDED that only the Bitmap Set be 265 used for representation Available Wavelengths information. 267 3.3. Shared Backup Wavelengths 269 Shared Backup Wavelengths indicates the wavelengths available for 270 shared backup use on a link as described in [RWA-Encode]. 272 The Shared Backup Wavelengths is a sub-TLV (the type is TBD by IANA) 273 of the Link TLV. The length is the length of value field in octets. 274 The meaning and format of this sub-TLV are defined in [WSON-Info] and 275 [WSON-Encode]. The Shared Backup Wavelengths sub-TLV may occur at 276 most once within the link TLV. 278 4. Procedures for Routing Flooding 280 All the sub-TLVs are nested to top-level TLV(s) and contained in 281 Opaque LSAs. The flooding of Opaque LSAs must follow the rules 282 specified in [RFC2328], [RFC2370], [RFC3630], [RFC4203], [OSPF-Node]. 284 In the WSON networks, the node information and link information can 285 be classified as two kinds: one is relatively static information such 286 as Node ID, Connectivity Matrix information; the other is dynamic 287 information such as WC Usage State, Available Wavelengths information. 288 [WSON-Encode] give recommendations of typical usage of previously 289 defined sub-TLVs which contain relatively static information and 290 dynamic information. An implementation SHOULD take measures to avoid 291 frequent updates of relatively static information when the relatively 292 static information is not changed. A mechanism MAY be applied such 293 that static information and dynamic information are contained in 294 separate Opaque LSAs to avoid unnecessary updates of static 295 information when dynamic information is changed. 297 Note that as with other TE information, an implementation SHOULD take 298 measures to avoid rapid and frequent updates of routing information 299 that could cause the routing network to become swamped. A threshold 300 mechanism MAY be applied such that updates are only flooded when a 301 number of changes have been made to the wavelength availability 302 information within a specific time. Such mechanisms MUST be 303 configurable if they are implemented. 305 5. Security Considerations 307 This document does not introduce any further security issues other 308 than those discussed in [RFC 3630], [RFC 4203]. 310 6. IANA Considerations 312 [RFC3630] says that the top level Types in a TE LSA and Types for 313 sub-TLVs for each top level Types must be assigned by Expert Review, 314 and must be registered with IANA. 316 IANA is requested to allocate new Types for the sub-TLVs as defined 317 in Sections 2.1, 2.2, 3.1, 3.2 and 3.3 as follows: 319 6.1. Node Information 321 This document introduces the following sub-TLV of Node Attribute TLV 322 (Value TBD, see [OSPF-Node]) 324 Type sub-TLV 326 TBD Connectivity Matrix 328 TBD Wavelength Converter Accessibility 330 TBD Wavelength Conversion Range 332 TBD WC Usage State 334 6.2. Link Information 336 This document introduces the following sub-TLV of TE Link TLV (Value 337 2) 339 Type sub-TLV 341 TBD WSON Port Wavelength Restrictions 343 TBD Available Wavelengths 345 TBD Shared Backup Wavelengths 347 7. References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 353 (GMPLS) Signaling Functional Description", RFC 3471, 354 January 2003. 356 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 357 Engineering (TE) Extensions to OSPF Version 2", RFC 358 3630, September 2003. 360 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 361 in Support of Generalized Multi-Protocol Label Switching 362 (GMPLS)", RFC 4202, October 2005 364 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 365 Support of Generalized Multi-Protocol Label Switching 366 (GMPLS)", RFC 4203, October 2005. 368 [RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS) 369 Architecture", RFC 3945, October 2004. 371 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 372 Computation Element (PCE)-Based Architecture ", RFC 4655, 373 August 2006. 375 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 377 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 378 1998. 380 [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's 381 Local Addresses in OSPF TE Extensions", draft-ietf-ospf- 382 te-node-addr, work in progress. 384 [Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 385 "Generalized Labels for G.694 Lambda-Switching 386 Capable Label Switching Routers", work in progress: 387 draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt, 388 January 2009. 390 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 391 and PCE Control of Wavelength Switched Optical 392 Networks", work in progress: draft-ietf-ccamp-rwa-WSON- 393 Framework-00.txt, December 2008. 395 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 396 Wavelength Assignment Information Model for Wavelength 397 Switched Optical Networks", work in progress: draft-ietf- 398 ccamp-rwa-info-01.txt, October 2008. 400 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 401 Wavelength Assignment Information Encoding for 402 Wavelength Switched Optical Networks", work in progress: 403 draft-ietf-ccamp-rwa-wson-encode-00.txt, December 2008. 405 [WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible 406 Interior Gateway Protocol Extensions for Wavelength 407 Switching Optical Networks", work in progress: 408 draft-li-ccamp-wson-igp-eval-01.txt, July 2008. 410 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 411 WDM Wavelength Switching Systems for use in Automated Path 412 Computation", http://www.grotto- 413 networking.com/wson/ModelingWSONswitchesV2a.pdf , June, 415 8. Authors' Addresses 417 Fatai Zhang 418 Huawei Technologies 419 F3-5-B R&D Center, Huawei Base 420 Bantian, Longgang District 421 Shenzhen 518129 P.R.China 423 Phone: +86-755-28972912 424 Email: zhangfatai@huawei.com 426 Young Lee 427 Huawei Technologies 428 1700 Alma Drive, Suite 100 429 Plano, TX 75075 430 USA 432 Phone: (972) 509-5599 (x2240) 433 Email: ylee@huawei.com 435 Jianrui Han 436 Huawei Technologies Co., Ltd. 437 F3-5-B R&D Center, Huawei Base 438 Bantian, Longgang District 439 Shenzhen 518129 P.R.China 441 Phone: +86-755-28972913 442 Email: hanjianrui@huawei.com 444 Greg Bernstein 445 Grotto Networking 446 Fremont CA, USA 448 Phone: (510) 573-2237 449 Email: gregb@grotto-networking.com 451 Yunbin Xu 452 China Academy of Telecommunication Research of MII 453 11 Yue Tan Nan Jie Beijing, P.R.China 454 Phone: +86-10-68094134 455 Email: xuyunbin@mail.ritt.com.cn 456 Guoying Zhang 457 China Academy of Telecommunication Research of MII 458 11 Yue Tan Nan Jie Beijing, P.R.China 459 Phone: +86-10-68094272 460 Email: zhangguoying@mail.ritt.com.cn 462 Dan Li 463 Huawei Technologies Co., Ltd. 464 F3-5-B R&D Center, Huawei Base 465 Bantian, Longgang District 466 Shenzhen 518129 P.R.China 468 Phone: +86-755-28973237 469 Email: danli@huawei.com 471 Ming Chen 472 Huawei Technologies Deutschland GmbH 473 Riesstr. 25, 80992 Munchen, Germany 475 Phone: 0049-89158834072 476 Email: minc@huawei.com 478 Acknowledgment 480 TBD. 482 Intellectual Property 484 The IETF Trust takes no position regarding the validity or scope of 485 any Intellectual Property Rights or other rights that might be 486 claimed to pertain to the implementation or use of the technology 487 described in any IETF Document or the extent to which any license 488 under such rights might or might not be available; nor does it 489 represent that it has made any independent effort to identify any 490 such rights. 492 Copies of Intellectual Property disclosures made to the IETF 493 Secretariat and any assurances of licenses to be made available, or 494 the result of an attempt made to obtain a general license or 495 permission for the use of such proprietary rights by implementers or 496 users of this specification can be obtained from the IETF on-line IPR 497 repository at http://www.ietf.org/ipr 499 The IETF invites any interested party to bring to its attention any 500 copyrights, patents or patent applications, or other proprietary 501 rights that may cover technology that may be required to implement 502 any standard or specification contained in an IETF Document. Please 503 address the information to the IETF at ietf-ipr@ietf.org. 505 The definitive version of an IETF Document is that published by, or 506 under the auspices of, the IETF. Versions of IETF Documents that are 507 published by third parties, including those that are translated into 508 other languages, should not be considered to be definitive versions 509 of IETF Documents. The definitive version of these Legal Provisions 510 is that published by, or under the auspices of, the IETF. Versions of 511 these Legal Provisions that are published by third parties, including 512 those that are translated into other languages, should not be 513 considered to be definitive versions of these Legal Provisions. 515 For the avoidance of doubt, each Contributor to the IETF Standards 516 Process licenses each Contribution that he or she makes as part of 517 the IETF Standards Process to the IETF Trust pursuant to the 518 provisions of RFC 5378. No language to the contrary, or terms, 519 conditions or rights that differ from or are inconsistent with the 520 rights and licenses granted under RFC 5378, shall have any effect and 521 shall be null and void, whether published or posted by such 522 Contributor, or included with or in such Contribution. 524 Disclaimer of Validity 526 All IETF Documents and the information contained therein are provided 527 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 528 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 529 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 530 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 531 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 532 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 533 FOR A PARTICULAR PURPOSE. 535 Full Copyright Statement 537 Copyright (c) 2009 IETF Trust and the persons identified as the 538 document authors. All rights reserved. 540 This document is subject to BCP 78 and the IETF Trust's Legal 541 Provisions Relating to IETF Documents in effect on the date of 542 publication of this document (http://trustee.ietf.org/license-info). 543 Please review these documents carefully, as they describe your rights 544 and restrictions with respect to this document.