idnits 2.17.1 draft-zhang-ccamp-rwa-wson-routing-ospf-02.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 345 has weird spacing: '... Type sub-...' == Line 360 has weird spacing: '... Type sub-...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In WSON networks, generally all the sub-TLVs above are optional, which depends on the implementations. It is default no restrictions on wavelength, so WSON Port Wavelength Restrictions sub-TLV may not appear in the LSAs. In order to be able to compute RWA, Available Wavelengths sub-TLV may appear in the LSAs. Without available wavelength information, path computation need guess what lambdas may be available (high blocking probability or distributed wavelength assignment may be used). Shared Backup Wavelengths sub-TLV SHOULD not appear in the LSAs, if there is no wavelength backup functionality in the WSON networks. -- The document date (October 23, 2009) is 5292 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: 'RFC 3630' is mentioned on line 329, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 329, but not defined == Unused Reference: 'RFC3471' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'Lambda-Labels' is defined on line 404, 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-04 -- 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-05 ** 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-03 ** Downref: Normative reference to an Informational draft: draft-li-ccamp-wson-igp-eval (ref. 'WSON-IGP-Eval') Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 3 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 Huawei 5 G. Bernstein 6 Grotto Networking 7 Yunbin Xu 8 CATR 9 Expires: April 2010 October 23, 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-02.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 April 22, 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............. 5 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........................... 7 64 4. Procedures for Routing Flooding.......................... 7 65 5. Security Considerations.................................. 8 66 6. IANA Considerations...................................... 8 67 6.1. Node Information.................................... 8 68 6.2. Link Information.................................... 8 69 7. References............................................... 9 70 8. Authors' Addresses...................................... 10 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 Per [WSON-Encode], we have identified the following new Sub-TLVs to 136 the Node Attribute TLV. Detail description for each newly defined 137 Sub-TLV is provided in subsequent sections: 139 Sub-TLV Type Length Name 141 TBD variable Connectivity Matrix 143 TBD variable Wavelength Converter Accessibility 145 TBD variable Wavelength Conversion Range 147 TBD variable WC Usage State 149 In WSON networks, generally all the sub-TLVs above are optional, 150 which depends on the implementations. Usually, Connectivity Matrix 151 sub-TLV may appear in the LSAs because WSON switches are asymmetric 152 at present. It is assumed that the switches are symmetric switching, 153 if there is no Connectivity Matrix sub-TLV in the LSAs. Wavelength 154 Converter Accessibility, Wavelength Conversion Range and WC Usage 155 State sub-TLVs should appear in the LSAs, if there is wavelength 156 conversion functionality in the WSON networks. 158 2.1. Connectivity Matrix 160 It is necessary to identify which ingress ports and wavelengths can 161 be connected to (the same wavelength on) a specific egress port, 162 because the switching devices in a WSON are highly asymmetric. 164 The Connectivity Matrix is used to identify these restrictions, which 165 can represent either the potential connectivity matrix for asymmetric 166 switches (e.g. ROADMs and such) or fixed connectivity for an 167 asymmetric device such as a multiplexer as defined in [WSON-Info]. 169 The Connectivity Matrix is a sub-TLV (the type is TBD by IANA) of the 170 Node Attribute TLV. The length is the length of value field in octets. 171 The meaning and format of this sub-TLV are defined in Section 4.3 of 172 [WSON-Encode]. One sub-TLV contains one matrix. The Connectivity 173 Matrix sub-TLV may occur more than once to contain multi-matrices 174 within the Node Attribute TLV. 176 2.2. Wavelength Converter Pool 178 A WSON node may include wavelength converters. The encoding of 179 structure and properties of a general wavelength converter pool 180 utilizes a Converter Accessibility sub-TLV, a Wavelength Converter 181 Range sub-TLV, and a Wavelength Converter Usage State sub-TLV as 182 described in [WSON-Encode]. 184 2.2.1. Wavelength Converter Accessibility 186 Wavelength Converter Accessibility represents the ability of an 187 ingress port to reach a wavelength converter and of a wavelength 188 converter to reach a particular egress port as described in [WSON- 189 Encode]. 191 The Wavelength Converter Accessibility is a sub-TLV (the type is TBD 192 by IANA) of the Node Attribute TLV. The length is the length of value 193 field in octets. The meaning and format of this sub-TLV are defined 194 in Section 5.2 of [WSON-Encode]. The Wavelength Converter 195 Accessibility sub-TLV may occur at most once within the Node 196 Attribute TLV. 198 2.2.2. Wavelength Conversion Range 200 Wavelength converters may have a limited input or output range which 201 can be described using one or more Wavelength Conversion Range sub- 202 TLV as described in [WSON-Encode]. 204 The Wavelength Converter Range is a sub-TLV (the type is TBD by IANA) 205 of the Node Attribute TLV. The length is the length of value field in 206 octets. The meaning and format of this sub-TLV are defined in Section 207 5.3 of [WSON-Encode]. The Wavelength Converter Range sub-TLV may 208 occur more than once within the Node Attribute TLV. 210 2.2.3. WC Usage State 212 WC Usage Sate indicates the usage state of wavelength converters as 213 described in [WSON-Encode] 215 The WC Usage State is a sub-TLV (the type is TBD by IANA) of the Node 216 Attribute TLV. The length is the length of value field in octets. The 217 meaning and format of this sub-TLV are defined in Section 5.4 of 218 [WSON-Encode]. The WC Usage State sub-TLV may occur at most once 219 within the Node Attribute TLV. 221 3. Link Information 223 The most common link sub-TLVs nested to link top-level TLV are 224 already defined in [RFC3630], [RFC4203]. For example, Link ID, 225 Administrative Group, Interface Switching Capability Descriptor 226 (ISCD), Link Protection Type, Shared Risk Link Group Information 227 (SRLG), and Traffic Engineering Metric are among the typical link 228 sub-TLVs. 230 For WSONs, per [WSON-Info] and [WSON-Encode], we add the following 231 additional link sub-TLVs to the link-TLV in this document. 233 Sub-TLV Type Length Name 235 TBD variable WSON Port Wavelength Restrictions 237 TBD variable Available Wavelengths 239 TBD variable Shared Backup Wavelengths 241 In WSON networks, generally all the sub-TLVs above are optional, 242 which depends on the implementations. It is default no restrictions 243 on wavelength, so WSON Port Wavelength Restrictions sub-TLV may not 244 appear in the LSAs. In order to be able to compute RWA, Available 245 Wavelengths sub-TLV may appear in the LSAs. Without available 246 wavelength information, path computation need guess what lambdas may 247 be available (high blocking probability or distributed wavelength 248 assignment may be used). Shared Backup Wavelengths sub-TLV SHOULD not 249 appear in the LSAs, if there is no wavelength backup functionality in 250 the WSON networks. 252 3.1. WSON Port Wavelength Restrictions 254 Port Wavelength Restrictions describes the wavelength (label) 255 restrictions that the link and various optical devices such as OXCs, 256 ROADMs, and waveband multiplexers may impose on a port. These 257 restrictions represent what wavelength may or may not be used on a 258 link and are relatively static. The detailed information about Port 259 wavelength restrictions is described in [WSON-Info]. 261 The WSON Port Wavelength Restrictions is a sub-TLV (the type is TBD 262 by IANA) of the Link TLV. The length is the length of value field in 263 octets. The meaning and format of this sub-TLV are defined Section 264 4.4 of [WSON-Encode]. The WSON Port Wavelength Restrictions sub-TLV 265 may occur more than once to specify a complex port constraint within 266 the link TLV. 268 3.2. Available Wavelengths 270 Available Wavelengths indicates the wavelengths available for use on 271 a link as described in [WSON-Encode].The Available Wavelengths is a 272 sub-TLV (the type is TBD by IANA) of the Link TLV. The length is the 273 length of value field in octets. The meaning and format of this sub- 274 TLV are defined in Section 4.1 of [WSON-Encode]. The Available 275 Wavelengths sub-TLV may occur at most once within the link TLV. 277 Note that there are five approaches for Wavelength Set which is used 278 to represent the Available Wavelengths described in [WSON-Encode]. 279 Considering that the continuity of the available or unavailable 280 wavelength set can be scattered for the dynamic wavelength 281 availability, so it may burden the routing to reorganize the 282 wavelength set information when the Inclusive (/Exclusive) List 283 (/Range) approaches are used to represent Available Wavelengths 284 information. Therefore, it is RECOMMENDED that only the Bitmap Set be 285 used for representation Available Wavelengths information. 287 3.3. Shared Backup Wavelengths 289 Shared Backup Wavelengths indicates the wavelengths available for 290 shared backup use on a link as described in [WSON-Encode]. 292 The Shared Backup Wavelengths is a sub-TLV (the type is TBD by IANA) 293 of the Link TLV. The length is the length of value field in octets. 294 The meaning and format of this sub-TLV are defined in Section 4.2 of 295 [WSON-Encode]. The Shared Backup Wavelengths sub-TLV may occur at 296 most once within the link TLV. 298 4. Routing Procedures 300 All the sub-TLVs are nested to top-level TLV(s) and contained in 301 Opaque LSAs. The flooding of Opaque LSAs must follow the rules 302 specified in [RFC2328], [RFC2370], [RFC3630], [RFC4203] and [OSPF- 303 Node]. 305 In the WSON networks, the node information and link information can 306 be classified as two kinds: one is relatively static information such 307 as Node ID, Connectivity Matrix information; the other is dynamic 308 information such as WC Usage State, Available Wavelengths information. 309 [WSON-Encode] give recommendations of typical usage of previously 310 defined sub-TLVs which contain relatively static information and 311 dynamic information. An implementation SHOULD take measures to avoid 312 frequent updates of relatively static information when the relatively 313 static information is not changed. A mechanism MAY be applied such 314 that static information and dynamic information are contained in 315 separate Opaque LSAs to avoid unnecessary updates of static 316 information when dynamic information is changed. 318 Note that as with other TE information, an implementation SHOULD take 319 measures to avoid rapid and frequent updates of routing information 320 that could cause the routing network to become swamped. A threshold 321 mechanism MAY be applied such that updates are only flooded when a 322 number of changes have been made to the wavelength availability 323 information within a specific time. Such mechanisms MUST be 324 configurable if they are implemented. 326 5. Security Considerations 328 This document does not introduce any further security issues other 329 than those discussed in [RFC 3630], [RFC 4203]. 331 6. IANA Considerations 333 [RFC3630] says that the top level Types in a TE LSA and Types for 334 sub-TLVs for each top level Types must be assigned by Expert Review, 335 and must be registered with IANA. 337 IANA is requested to allocate new Types for the sub-TLVs as defined 338 in Sections 2.1, 2.2, 3.1, 3.2 and 3.3 as follows: 340 6.1. Node Information 342 This document introduces the following sub-TLVs of Node Attribute TLV 343 (Value TBD, see [OSPF-Node]) 345 Type sub-TLV 347 TBD Connectivity Matrix 349 TBD Wavelength Converter Accessibility 351 TBD Wavelength Conversion Range 353 TBD WC Usage State 355 6.2. Link Information 357 This document introduces the following sub-TLVs of TE Link TLV (Value 358 2) 360 Type sub-TLV 362 TBD WSON Port Wavelength Restrictions 364 TBD Available Wavelengths 365 TBD Shared Backup Wavelengths 367 7. References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 373 (GMPLS) Signaling Functional Description", RFC 3471, 374 January 2003. 376 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 377 Engineering (TE) Extensions to OSPF Version 2", RFC 378 3630, September 2003. 380 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 381 in Support of Generalized Multi-Protocol Label Switching 382 (GMPLS)", RFC 4202, October 2005 384 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 385 Support of Generalized Multi-Protocol Label Switching 386 (GMPLS)", RFC 4203, October 2005. 388 [RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS) 389 Architecture", RFC 3945, October 2004. 391 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 392 Computation Element (PCE)-Based Architecture ", RFC 4655, 393 August 2006. 395 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 397 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 398 1998. 400 [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's 401 Local Addresses in OSPF TE Extensions", draft-ietf-ospf- 402 te-node-addr, work in progress. 404 [Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 405 "Generalized Labels for G.694 Lambda-Switching 406 Capable Label Switching Routers", work in progress: 407 draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt, 408 March 2009. 410 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 411 and PCE Control of Wavelength Switched Optical 412 Networks", work in progress: draft-ietf-ccamp-rwa-WSON- 413 Framework-04.txt, October 2009. 415 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 416 Wavelength Assignment Information Model for Wavelength 417 Switched Optical Networks", work in progress: draft-ietf- 418 ccamp-rwa-info-05.txt, October 2009. 420 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 421 Wavelength Assignment Information Encoding for 422 Wavelength Switched Optical Networks", work in progress: 423 draft-ietf-ccamp-rwa-wson-encode-03.txt, October 2009. 425 [WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible 426 Interior Gateway Protocol Extensions for Wavelength 427 Switching Optical Networks", work in progress: 428 draft-li-ccamp-wson-igp-eval-01.txt, July 2008. 430 8. Authors' Addresses 432 Fatai Zhang 433 Huawei Technologies 434 F3-5-B R&D Center, Huawei Base 435 Bantian, Longgang District 436 Shenzhen 518129 P.R.China 438 Phone: +86-755-28972912 439 Email: zhangfatai@huawei.com 441 Young Lee 442 Huawei Technologies 443 1700 Alma Drive, Suite 100 444 Plano, TX 75075 445 USA 447 Phone: (972) 509-5599 (x2240) 448 Email: ylee@huawei.com 449 Jianrui Han 450 Huawei Technologies Co., Ltd. 451 F3-5-B R&D Center, Huawei Base 452 Bantian, Longgang District 453 Shenzhen 518129 P.R.China 455 Phone: +86-755-28972913 456 Email: hanjianrui@huawei.com 458 Greg Bernstein 459 Grotto Networking 460 Fremont CA, USA 462 Phone: (510) 573-2237 463 Email: gregb@grotto-networking.com 465 Yunbin Xu 466 China Academy of Telecommunication Research of MII 467 11 Yue Tan Nan Jie Beijing, P.R.China 468 Phone: +86-10-68094134 469 Email: xuyunbin@mail.ritt.com.cn 471 Guoying Zhang 472 China Academy of Telecommunication Research of MII 473 11 Yue Tan Nan Jie Beijing, P.R.China 474 Phone: +86-10-68094272 475 Email: zhangguoying@mail.ritt.com.cn 477 Dan Li 478 Huawei Technologies Co., Ltd. 479 F3-5-B R&D Center, Huawei Base 480 Bantian, Longgang District 481 Shenzhen 518129 P.R.China 483 Phone: +86-755-28973237 484 Email: danli@huawei.com 485 Ming Chen 486 European Research Center 487 Huawei Technologies 488 Riesstr. 25, 80992 Munchen, Germany 490 Phone: 0049-89158834072 491 Email: minc@huawei.com 493 Yabin Ye 494 European Research Center 495 Huawei Technologies 496 Riesstr. 25, 80992 Munchen, Germany 498 Phone: 0049-89158834074 499 Email: yabin.ye@huawei.com 501 Acknowledgment 503 We thank Ming Chen and Yabin Ye from DICONNET Project who provided 504 valuable information for this document. 506 Intellectual Property 508 The IETF Trust takes no position regarding the validity or scope of 509 any Intellectual Property Rights or other rights that might be 510 claimed to pertain to the implementation or use of the technology 511 described in any IETF Document or the extent to which any license 512 under such rights might or might not be available; nor does it 513 represent that it has made any independent effort to identify any 514 such rights. 516 Copies of Intellectual Property disclosures made to the IETF 517 Secretariat and any assurances of licenses to be made available, or 518 the result of an attempt made to obtain a general license or 519 permission for the use of such proprietary rights by implementers or 520 users of this specification can be obtained from the IETF on-line IPR 521 repository at http://www.ietf.org/ipr 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights that may cover technology that may be required to implement 526 any standard or specification contained in an IETF Document. Please 527 address the information to the IETF at ietf-ipr@ietf.org. 529 The definitive version of an IETF Document is that published by, or 530 under the auspices of, the IETF. Versions of IETF Documents that are 531 published by third parties, including those that are translated into 532 other languages, should not be considered to be definitive versions 533 of IETF Documents. The definitive version of these Legal Provisions 534 is that published by, or under the auspices of, the IETF. Versions of 535 these Legal Provisions that are published by third parties, including 536 those that are translated into other languages, should not be 537 considered to be definitive versions of these Legal Provisions. 539 For the avoidance of doubt, each Contributor to the IETF Standards 540 Process licenses each Contribution that he or she makes as part of 541 the IETF Standards Process to the IETF Trust pursuant to the 542 provisions of RFC 5378. No language to the contrary, or terms, 543 conditions or rights that differ from or are inconsistent with the 544 rights and licenses granted under RFC 5378, shall have any effect and 545 shall be null and void, whether published or posted by such 546 Contributor, or included with or in such Contribution. 548 Disclaimer of Validity 550 All IETF Documents and the information contained therein are provided 551 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 552 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 553 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 554 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 555 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 556 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 557 FOR A PARTICULAR PURPOSE. 559 Full Copyright Statement 561 Copyright (c) 2009 IETF Trust and the persons identified as the 562 document authors. All rights reserved. 564 This document is subject to BCP 78 and the IETF Trust's Legal 565 Provisions Relating to IETF Documents in effect on the date of 566 publication of this document (http://trustee.ietf.org/license-info). 567 Please review these documents carefully, as they describe your rights 568 and restrictions with respect to this document.