idnits 2.17.1 draft-ietf-ccamp-te-node-cap-04.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 27. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 518. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (December 2006) is 6340 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: 'RFC3031' is mentioned on line 93, but not defined == Missing Reference: 'OSPFv3-TE' is mentioned on line 99, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 358, but not defined == Unused Reference: 'RFC2119' is defined on line 397, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Downref: Normative reference to an Informational RFC: RFC 4461 -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) ** Downref: Normative reference to an Experimental RFC: RFC 2154 -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.P. Vasseur (Editor) 3 Cisco Systems, Inc. 4 IETF Internet Draft J.L. Le Roux (Editor) 5 France Telecom 6 Proposed Status: Standard Track 7 Expires: July 2007 S. Yasukawa 8 NTT 9 S. Previdi 10 P. Psenak 11 Cisco Systems, Inc. 12 Paul Mabey 13 Comcast 15 December 2006 17 IGP Routing Protocol Extensions for Discovery of Traffic Engineering 18 Node Capabilities 20 draft-ietf-ccamp-te-node-cap-04.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet- Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 It is highly desired in several cases, to take into account Traffic 47 Engineering (TE) node capabilities during Multi Protocol Label 48 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered 49 Label Switched Path (TE-LSP) selection, such as for instance the 50 capability to act as a branch Label Switching Router (LSR) of a 51 Point-To-MultiPoint (P2MP) LSP. This requires advertising these 52 capabilities within the Interior Gateway Protocol (IGP). For that 53 purpose, this document specifies Open Shortest Path First (OSPF) and 54 Intermediate System-Intermediate System (IS-IS) traffic engineering 55 extensions for the advertisement of control plane and data plane 56 traffic engineering node capabilities. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119. 64 Table of Contents 66 1. Terminology.................................................3 67 2. Introduction................................................3 68 3. TE Node Capability Descriptor...............................4 69 3.1. Description.................................................4 70 3.2. Required Information........................................4 71 4. TE Node Capability Descriptor TLV formats...................5 72 4.1. OSPF TE Node Capability Descriptor TLV format...............5 73 4.2. IS-IS TE Node Capability Descriptor sub-TLV format..........6 74 5. Elements of procedure.......................................7 75 5.1. OSPF........................................................7 76 5.2. IS-IS.......................................................8 77 6. Backward compatibility......................................8 78 7. Security Considerations.....................................9 79 8. IANA considerations.........................................9 80 8.1. OSPF TLV....................................................9 81 8.2. ISIS sub-TLV................................................9 82 8.3. Capability Registry.........................................9 83 9. Acknowledgments............................................10 84 10. References.................................................10 85 10.1. Normative references.......................................10 86 10.2. Informative References.....................................11 87 11. Editors' Addresses.........................................11 88 12. Contributors' Addresses....................................11 89 13. Intellectual Property Statement............................12 91 1. Terminology 93 This document uses terminologies defined in [RFC3031], [RFC3209] and 94 [RFC4461]. 96 2. Introduction 98 Multi Protocol Label Switching-Traffic Engineering (MPLS-TE) routing 99 ([RFC3784], [RFC3630], [OSPFv3-TE]) relies on extensions to link 100 state Interior Gateway Protocols (IGP) ([IS-IS], [RFC2328], 101 [RFC2740]) in order to advertise Traffic Engineering (TE) link 102 information used for constraint based routing. Further Generalized 103 MPLS (GMPLS) related routing extensions are defined in [RFC4205] and 104 [RFC4203]. 106 It is desired to complement these routing extensions in order to 107 advertise TE node capabilities, in addition to TE link information. 108 These TE node capabilities will be taken into account as constraints 109 during path selection. 111 Indeed, it is useful to advertise data plane TE node capabilities, 112 such as the capability for a Label Switching Router (LSR) to be a 113 branch LSR or a bud-LSR of a Point-To-MultiPoint (P2MP) Label 114 Switched Path (LSP). These capabilities can then be taken into 115 account as constraints when computing the route of TE LSPs. 117 It is also useful to advertise control plane TE node capabilities 118 such as the capability to support GMPLS signaling for a packet LSR, 119 or the capability to support P2MP (Point to Multipoint) TE LSP 120 signaling. This allows selecting a path that avoids nodes that do 121 not support a given control plane feature, or triggering a mechanism 122 to support such nodes on a path. Hence this facilitates backward 123 compatibility. 125 For that purpose, this document specifies IGP (OSPF and IS-IS) 126 extensions in order to advertise data plane and control plane 127 capabilities of a node. 129 A new TLV is defined for OSPF, the TE Node Capability Descriptor TLV, 130 to be carried within the Router Information LSA ([OSPF-CAP]). 131 A new sub-TLV is defined for IS-IS, the TE Node Capability Descriptor 132 sub-TLV, to be carried within the IS-IS Capability TLV ([ISIS-CAP]). 134 3. TE Node Capability Descriptor 136 3.1. Description 138 LSRs in a network may have distinct control plane and data plane 139 Traffic Engineering capabilities. The TE Node Capability Descriptor 140 information defined in this document describes data and control plane 141 capabilities of an LSR. Such information can be used during path 142 computation so as to avoid nodes that do not support a given TE 143 feature either in the control or data plane, or to trigger procedures 144 to handle these nodes along the path (e.g, trigger LSP hierarchy to 145 support a legacy transit LSR on a P2MP LSP (see [RSVP-P2MP])). 147 3.2. Required Information 149 The TE Node Capability Descriptor contains a variable length set of 150 bit flags, where each bit corresponds to a given TE node capability. 152 Five TE Node Capabilities are defined in this document: 154 - B bit: when set, this flag indicates that the LSR can act 155 as a branch node on a P2MP LSP (see [RFC4461]); 156 - E bit: when set, this flag indicates that the LSR can act 157 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 158 transit and egress (see [RFC4461]). 159 - M bit: when set, this flag indicates that the LSR supports 160 MPLS-TE signaling ([RFC3209]); 161 - G bit: when set this flag indicates that the LSR supports 162 GMPLS signaling ([RFC3473]); 163 - P bit: when set, this flag indicates that the LSR supports 164 P2MP MPLS-TE signaling ([RSVP-P2MP]). 166 Note that new capability bits may be added in the future if required. 168 4. TE Node Capability Descriptor TLV formats 170 4.1. OSPF TE Node Capability Descriptor TLV format 172 The OSPF TE Node Capability Descriptor TLV is a variable length TLV 173 that contains a series of bit flags, where each bit correspond to a 174 TE node capability. 176 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 177 Router Information LSA which is defined in [OSPF-CAP]. 179 The format of the OSPF TE Node Capability Descriptor TLV is the same 180 as the TLV format used by the Traffic Engineering Extensions to OSPF 181 [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 182 octets specifying the length of the value field and a value field. 184 The OSPF TE Node Capability Descriptor TLV has the following format: 186 TYPE To be assigned by IANA (suggested value =1). 187 LENGTH Variable (multiple of 4). 188 VALUE Array of units of 32 flags numbered from the most 189 significant bit as bit zero, where each bit represents 190 a TE node capability. 192 The following bits are defined: 194 Bit Capabilities 196 0 B bit: P2MP Branch Node capability: When set this indicates 197 that the LSR can act as a branch node on a P2MP LSP 198 [RFC4461]. 199 1 E bit: P2MP Bud-LSR capability: When set, this indicates 200 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 201 LSR that is both transit and egress [RFC4461]. 202 2 M bit: If set this indicates that the LSR supports MPLS-TE 203 signaling ([RFC3209]). 204 3 G bit: If set this indicates that the LSR supports GMPLS 205 signaling ([RFC3473]). 206 4 P bit: If set this indicates that the LSR supports P2MP 207 MPLS-TE signaling ([RSVP-P2MP]). 209 5-31 Reserved for future assignments by IANA. 211 4.2. IS-IS TE Node Capability Descriptor sub-TLV format 213 The IS-IS TE Node Capability Descriptor sub-TLV is a variable length 214 sub-TLV that contains a series of bit flags, where each bit 215 correspond to a TE node capability. 217 The IS-IS TE Node Capability Descriptor sub-TLV is carried within an 218 IS-IS CAPABILITY TLV which is defined in [ISIS-CAP]. 220 The format of the IS-IS TE Node Capability sub-TLV is the same as the 221 TLV format used by the Traffic Engineering Extensions to IS-IS 222 [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 223 octet specifying the TLV length and a value field. 225 The IS-IS TE Node Capability Descriptor sub-TLV has the following 226 format: 228 TYPE: To be assigned by IANA (Suggested value =1) 229 LENGTH: Variable 230 VALUE: Array of units of 8 flags numbered from the most 231 significant bit as bit zero, where each bit represents 232 a TE node capability. 234 The following bits are defined: 236 Bit Capabilities 238 0 B bit: P2MP Branch Node capability: When set this indicates 239 that the LSR can act as a branch node on a P2MP LSP 240 [RFC4461]. 241 1 E bit: P2MP Bud-LSR capability: When set, this indicates 242 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 243 LSR that is both transit and egress [RFC4461]. 244 2 M bit: If set this indicates that the LSR supports MPLS-TE 245 signaling ([RFC3209]). 246 3 G bit: If set this indicates that the LSR supports GMPLS 247 signaling ([RFC3473]). 248 4 P bit: If set this indicates that the LSR supports P2MP 249 MPLS-TE signaling ([RSVP-P2MP]). 251 5-7 Reserved for future assignments by IANA. 253 5. Elements of procedure 255 5.1. OSPF 257 The TE Node Capability Descriptor TLV is advertised, within an OSPFv2 258 Router Information LSA (Opaque type of 4 and Opaque ID of 0) 259 or an OSPFv3 Router Information LSA (function code of 12) which are 260 defined in [OSPF-CAP]. As such, elements of procedure are inherited 261 from those defined in [RFC2328], [RFC2740], and [OSPF-CAP]. 263 The TE Node Capability Descriptor TLV advertises capabilities that 264 may be taken into account as constraints during path selection. Hence 265 its flooding scope is area-local, and it MUST be carried within 266 OSPFv2 type 10 Router Information LSA (as defined in [RFC2370]) or an 267 OSPFv3 Router Information LSA with the S1 bit set and the S2 bit 268 cleared (as defined in [RFC2740]). 270 A router MUST originate a new OSPF router information LSA whenever 271 the content of the TE Node Capability Descriptor TLV changes or 272 whenever required by the regular OSPF procedure (LSA refresh (every 273 LSRefreshTime)). 275 The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear 276 more than once in an OSPF Router Information LSA. If a TE Node 277 Capability Descriptor TLV appears more than once in an OSPF Router 278 Information LSA, only the first occurrence MUST be processed and 279 other MUST be ignored. 281 When an OSPF LSA does not contain any TE Node capability Descriptor 282 TLV, this means that the TE Capabilities of that LSR are unknown. 284 Note that a change in any of these capabilities MAY trigger CSPF 285 computation, but MUST NOT trigger normal SPF computation. 287 Note also that TE node capabilities are expected to be fairly static. 288 They may change as the result of configuration change, or software 289 upgrade. This is expected not to appear more than once a day. 291 5.2. IS-IS 293 The TE Node Capability sub-TLV is carried within an IS-IS CAPABILITY 294 TLV defined in [IS-IS-CAP]. As such, elements of procedure are 295 inherited from those defined in [IS-IS-CAP]. 297 The TE Node Capability Descriptor sub-TLV advertises capabilities 298 that may be taken into account as constraints during path selection. 299 Hence its flooding is area-local, and MUST be carried within an IS-IS 300 CAPABILITY TLV having the S flag cleared. 302 An IS-IS router MUST originate a new IS-IS LSP whenever the content 303 of any of the TE Node Capability sub-TLV changes or whenever required 304 by the regular IS-IS procedure (LSP refresh). 306 The TE Node Capability Descriptor sub-TLV is OPTIONAL and MUST NOT 307 appear more than once in an ISIS Router Capability TLV. 309 When an IS-IS LSP does not contain any TE Node capability Descriptor 310 sub-TLV, this means that the TE Capabilities of that LSR are unknown. 312 Note that a change in any of these capabilities MAY trigger CSPF 313 computation, but MUST NOT trigger normal SPF computation. 315 Note also that TE node capabilities are expected to be fairly static. 316 They may change as the result of configuration change, or software 317 upgrade. This is expected not to appear more than once a day. 319 6. Backward compatibility 321 The TE Node Capability Descriptor TLVs defined in this document do 322 not introduce any interoperability issue. For OSPF, a router not 323 supporting the TE Node Capability Descriptor TLV will just silently 324 ignore the TLV as specified in [OSPF-CAP]. For IS-IS a router not 325 supporting the TE Node Capability Descriptor sub-TLV will just 326 silently ignore the sub-TLV as specified in [IS-IS-CAP]. 328 When the TE Node capability Descriptor TLV is absent, this means that 329 the TE Capabilities of that LSR are unknown. 331 The absence of a word of capability flags in OSPF or an octet of 332 capability flags in IS-IS means that these capabilities are unknown. 334 7. Security Considerations 336 This document specifies the content of the TE Node Capability 337 Descriptor TLV in ISIS and OSPF, to be used for (G)MPLS-TE path 338 computation. As this TLV is not used for SPF computation or normal 339 routing, the extensions specified here have no direct effect on IP 340 routing. Tampering with this TLV may have an effect on Traffic 341 Engineering computation. Mechanisms defined to secure ISIS Link State 342 PDUs [RFC3567], OSPF LSAs [RFC2154], and their TLVs, can be used to 343 secure this TLV as well. 345 8. IANA considerations 347 8.1. OSPF TLV 349 IANA is in charge of the assignment of TLV code points for the Router 350 Information LSA defined in [OSPF-CAP]. 351 IANA will assign a new codepoint for the TE Node Capability 352 Descriptor TLV defined in this document and carried within the Router 353 Information LSA (suggested value = 1). 355 8.2. ISIS sub-TLV 357 IANA is in charge of the assignment of sub-TLV code points for the 358 ISIS CAPABILITY TLV defined in [ISIS-CAP]. 359 IANA will assign a new codepoint for the TE Node Capability 360 Descriptor sub-TLV defined in this document, and carried within the 361 ISIS CAPABILITY TLV (suggested value = 1). 363 8.3. Capability Registry 365 IANA is requested to manage the space of capability bit flags carried 366 within the OSPF and ISIS TE Node Capability Descriptor, numbering 367 them in the usual IETF notation starting at zero, with the most 368 significant bit as bit zero. A single registry must be defined for 369 both protocols. 370 New bit numbers may be allocated only by an IETF Consensus action. 371 Each bit should be tracked with the following qualities: 372 - Bit number 373 - Defining RFC 374 - Name of bit 376 Five TE node capabilities are defined in this document and must be 377 assigned by IANA. Here are the suggested values: 378 1 : B Bit = P2MP Branch LSR capability ([RFC4461]) 379 2 : E bit = P2MP Bud LSR capability ([RFC4461]) 380 3 : M bit = MPLS-TE support ([RFC3209]) 381 4 : G bit = GMPLS support (RFC3473)) 382 5 : P bit = P2MP RSVP-TE support ([RSVP-P2MP]) 384 9. Acknowledgments 386 We would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri 387 Papadimitriou, Acee Lindem and David Ward for their useful comments 388 and suggestions. 390 We would also like to thank authors of [RFC4420] and [OSPF-CAP] from 391 which some text of this document has been inspired. 393 10. References 395 10.1. Normative references 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 402 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 403 RFC 2740, December 1999. 405 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 406 July 1998. 408 [RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to 409 Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. 411 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 412 Routing Exchange Protocol " ISO 10589. 414 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 415 Extensions to OSPF Version 2", RFC 3630, September 2003. 417 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 418 Engineering", RFC 3784, June 2004. 420 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 421 J.P., "Extensions to OSPF for advertising Optional Router 422 Capabilities", draft-ietf-ospf-cap, work in progress. 424 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 425 router information", draft-ietf-isis-caps, work in progress. 427 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 428 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 429 July 2003. 431 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 432 Digital Signatures", RFC 2154, June 1997. 434 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 435 tunnels", RFC 3209, December 2001. 437 [RFC3473] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 438 RFC 3473, January 2003. 440 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 441 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 442 p2mp, work in progress. 444 10.2. Informative References 446 [RFC4203] Kompella, K., Rekhter, Y., "OSPF extensions in support of 447 Generalized Multi-protocol Label Switching", RFC4203, October 2005. 449 [RFC4205] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 450 Generalized Multi-protocol Label Switching", RFC4205, October 2005. 452 [RFC4420] Farrel, A., and al., "Encoding of attributes for MPLS LSPs 453 establishment Using RSVP-TE", RFC4420, February 2006. 455 11. Editors' Addresses 457 Jean-Philippe Vasseur 458 Cisco Systems, Inc. 459 1414 Massachusetts Avenue 460 Boxborough , MA - 01719 461 USA 462 Email: jpv@cisco.com 464 Jean-Louis Le Roux 465 France Telecom 466 2, avenue Pierre-Marzin 467 22307 Lannion Cedex 468 FRANCE 469 Email: jeanlouis.leroux@orange-ftgroup.com 471 12. Contributors' Addresses 473 Seisho Yasukawa 474 NTT 475 3-9-11 Midori-cho, 476 Musashino-shi, Tokyo 180-8585, Japan 477 Email: s.yasukawa@hco.ntt.co.jp 479 Stefano Previdi 480 Cisco Systems, Inc 481 Via Del Serafico 200 482 Roma, 00142 483 Italy 484 Email: sprevidi@cisco.com 485 Peter Psenak 486 Cisco Systems, Inc 487 Pegasus Park DE Kleetlaan 6A 488 Diegmen, 1831 489 BELGIUM 490 Email: ppsenak@cisco.com 492 Paul Mabbey 493 Comcast 494 USA 496 13. Intellectual Property Statement 498 The IETF takes no position regarding the validity or scope of any 499 Intellectual Property Rights or other rights that might be claimed to 500 pertain to the implementation or use of the technology described in 501 this document or the extent to which any license under such rights 502 might or might not be available; nor does it represent that it has 503 made any independent effort to identify any such rights. Information 504 on the procedures with respect to rights in RFC documents can be 505 found in BCP 78 and BCP 79. 507 Copies of IPR disclosures made to the IETF Secretariat and any 508 assurances of licenses to be made available, or the result of an 509 attempt made to obtain a general license or permission for the use of 510 such proprietary rights by implementers or users of this 511 specification can be obtained from the IETF on-line IPR repository at 512 http://www.ietf.org/ipr. 514 The IETF invites any interested party to bring to its attention any 515 copyrights, patents or patent applications, or other proprietary 516 rights that may cover technology that may be required to implement 517 this standard. Please address the information to the IETF at 518 ietf-ipr@ietf.org. 520 Disclaimer of Validity 522 This document and the information contained herein are provided 523 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 524 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 525 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 526 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 527 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 528 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 529 FOR A PARTICULAR PURPOSE. 531 Copyright Statement 533 Copyright (C) The IETF Trust (2006). This document is subject to the 534 rights, licenses and restrictions contained in BCP 78, and except as 535 set forth therein, the authors retain all their rights.