idnits 2.17.1 draft-ietf-ccamp-te-node-cap-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 26. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. 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 (November 2006) is 6372 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 92, but not defined == Missing Reference: 'OSPFv3-TE' is mentioned on line 98, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 360, but not defined == Missing Reference: 'ISIS-HMAC' is mentioned on line 344, but not defined == Missing Reference: 'OSPF-SIG' is mentioned on line 344, but not defined == Unused Reference: 'RFC2119' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC3567' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC2154' is defined on line 433, 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 (~~), 10 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 S. Yasukawa 7 Expires: May 2007 NTT 8 S. Previdi 9 P. Psenak 10 Cisco Systems, Inc. 11 Paul Mabey 12 Comcast 14 November 2006 16 IGP Routing Protocol Extensions for Discovery of Traffic Engineering 17 Node Capabilities 19 draft-ietf-ccamp-te-node-cap-03.txt 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that other 30 groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 It is highly desired in several cases, to take into account Traffic 46 Engineering (TE) node capabilities during Multi Protocol Label 47 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered 48 Label Switched Path (TE-LSP) selection, such as for instance the 49 capability to act as a branch Label Switching Router (LSR) of a 50 Point-To-MultiPoint (P2MP) LSP. This requires advertising these 51 capabilities within the Interior Gateway Protocol (IGP). For that 52 purpose, this document specifies Open Shortest Path First (OSPF) and 53 Intermediate System-Intermediate System (IS-IS) traffic engineering 54 extensions for the advertisement of control plane and data plane 55 traffic engineering node capabilities. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119. 63 Table of Contents 65 1. Terminology.................................................3 66 2. Introduction................................................3 67 3. TE Node Capability Descriptor...............................4 68 3.1. Description.................................................4 69 3.2. Required Information........................................4 70 4. TE Node Capability Descriptor TLV formats...................5 71 4.1. OSPF TE Node Capability Descriptor TLV format...............5 72 4.2. IS-IS TE Node Capability Descriptor sub-TLV format..........6 73 5. Elements of procedure.......................................7 74 5.1. OSPF........................................................7 75 5.2. IS-IS.......................................................8 76 6. Backward compatibility......................................8 77 7. Security Considerations.....................................9 78 8. IANA considerations.........................................9 79 8.1. OSPF TLV....................................................9 80 8.2. ISIS sub-TLV................................................9 81 8.3. Capability Registry.........................................9 82 9. Acknowledgments............................................10 83 10. References.................................................10 84 10.1. Normative references.......................................10 85 10.2. Informative References.....................................11 86 11. Editors' Addresses.........................................11 87 12. Contributors' Addresses....................................11 88 13. Intellectual Property Statement............................12 90 1. Terminology 92 This document uses terminologies defined in [RFC3031], [RFC3209] and 93 [RFC4461]. 95 2. Introduction 97 Multi Protocol Label Switching-Traffic Engineering (MPLS-TE) routing 98 ([RFC3784], [RFC3630], [OSPFv3-TE]) relies on extensions to link 99 state Interior Gateway Protocols (IGP) ([IS-IS], [RFC2328], 100 [RFC2740]) in order to advertise Traffic Engineering (TE) link 101 information used for constraint based routing. Further Generalized 102 MPLS (GMPLS) related routing extensions are defined in [RFC4205] and 103 [RFC4203]. 105 It is desired to complement these routing extensions in order to 106 advertise TE node capabilities, in addition to TE link information. 107 These TE node capabilities will be taken into account as constraints 108 during path selection. 110 Indeed, it is useful to advertise data plane TE node capabilities, 111 such as the capability for a Label Switching Router (LSR) to be a 112 branch LSR or a bud-LSR of a Point-To-MultiPoint (P2MP) Label 113 Switched Path (LSP). These capabilities can then be taken into 114 account as constraints when computing the route of TE LSPs. 116 It is also useful to advertise control plane TE node capabilities 117 such as the capability to support GMPLS signaling for a packet LSR, 118 or the capability to support P2MP (Point to Multipoint) TE LSP 119 signaling. This allows selecting a path that avoids nodes that do 120 not support a given control plane feature, or triggering a mechanism 121 to support such nodes on a path. Hence this facilitates backward 122 compatibility. 124 For that purpose, this document specifies IGP (OSPF and IS-IS) 125 traffic engineering node capability TLVs in order to advertise data 126 plane and control plane capabilities of a node. 128 A new TLV is defined for ISIS and OSPF: the TE Node Capability 129 Descriptor TLV, to be carried within: 130 - The ISIS Capability TLV ([ISIS-CAP]) for ISIS 131 - The Router Information LSA ([OSPF-CAP]) for OSPF. 133 3. TE Node Capability Descriptor 135 3.1. Description 137 LSRs in a network may have distinct control plane and data plane 138 Traffic Engineering capabilities. The TE Node Capability Descriptor 139 information defined in this document describes data and control plane 140 capabilities of an LSR. Such information can be used during path 141 computation so as to avoid nodes that do not support a given TE 142 feature either in the control or data plane, or to trigger procedures 143 to handle these nodes along the path (e.g, trigger LSP hierarchy to 144 support a legacy transit LSR on a P2MP LSP (see [RSVP-P2MP])). 146 3.2. Required Information 148 The TE Node Capability Descriptor contains a variable length set of 149 bit flags, where each bit corresponds to a given TE node capability. 151 Five TE Node Capabilities are defined in this document: 153 - B bit: when set, this flag indicates that the LSR can act 154 as a branch node on a P2MP LSP (see [RFC4461]); 155 - E bit: when set, this flag indicates that the LSR can act 156 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 157 transit and egress (see [RFC4461]). 158 - M bit: when set, this flag indicates that the LSR supports 159 MPLS-TE signaling ([RFC3209]); 160 - G bit: when set this flag indicates that the LSR supports 161 GMPLS signaling ([RFC3473]); 162 - P bit: when set, this flag indicates that the LSR supports 163 P2MP MPLS-TE signaling ([RSVP-P2MP]). 165 Note that new capability bits may be added in the future if required. 167 4. TE Node Capability Descriptor TLV formats 169 4.1. OSPF TE Node Capability Descriptor TLV format 171 The OSPF TE Node Capability Descriptor TLV is a variable length TLV 172 that contains a series of bit flags, where each bit correspond to a 173 TE node capability. 175 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 176 Router Information LSA which is defined in [OSPF-CAP]. 178 The format of the OSPF TE Node Capability Descriptor TLV is the same 179 as the TLV format used by the Traffic Engineering Extensions to OSPF 180 [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 181 octets specifying the length of the value field and a value field. 183 The OSPF TE Node Capability Descriptor TLV has the following format: 185 TYPE To be assigned by IANA (suggested value =1). 186 LENGTH Variable (multiple of 4). 187 VALUE Array of units of 32 flags numbered from the most 188 significant bit as bit zero, where each bit represents 189 a TE node capability. 191 The following bits are defined: 193 Bit Capabilities 195 0 B bit: P2MP Branch Node capability: When set this indicates 196 that the LSR can act as a branch node on a P2MP LSP 197 [RFC4461]. 198 1 E bit: P2MP Bud-LSR capability: When set, this indicates 199 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 200 LSR that is both transit and egress [RFC4461]. 201 2 M bit: If set this indicates that the LSR supports MPLS-TE 202 signaling ([RFC3209]). 203 3 G bit: If set this indicates that the LSR supports GMPLS 204 signaling ([RFC3473]). 205 4 P bit: If set this indicates that the LSR supports P2MP 206 MPLS-TE signaling ([RSVP-P2MP]). 208 5-31 Reserved for future assignments by IANA. 210 4.2. IS-IS TE Node Capability Descriptor sub-TLV format 212 The IS-IS TE Node Capability Descriptor sub-TLV is a variable length 213 sub-TLV that contains a series of bit flags, where each bit 214 correspond to a TE node capability. 216 The IS-IS TE Node Capability Descriptor TLV is carried within an IS- 217 IS CAPABILITY TLV which is defined in [OSPF-CAP]. 219 The format of the IS-IS TE Node Capability sub-TLV is the same as the 220 TLV format used by the Traffic Engineering Extensions to IS-IS 221 [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 222 octet specifying the TLV length and a value field. 224 The IS-IS TE Node Capability Descriptor sub-TLV has the following 225 format: 227 TYPE: To be assigned by IANA (Suggested value =1) 228 LENGTH: Variable 229 VALUE: Array of units of 8 flags numbered from the most 230 significant bit as bit zero, where each bit represents 231 a TE node capability. 233 The following bits are defined: 235 Bit Capabilities 237 0 B bit: P2MP Branch Node capability: When set this indicates 238 that the LSR can act as a branch node on a P2MP LSP 239 [RFC4461]. 240 1 E bit: P2MP Bud-LSR capability: When set, this indicates 241 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 242 LSR that is both transit and egress [RFC4461]. 243 2 M bit: If set this indicates that the LSR supports MPLS-TE 244 signaling ([RFC3209]). 245 3 G bit: If set this indicates that the LSR supports GMPLS 246 signaling ([RFC3473]). 247 4 P bit: If set this indicates that the LSR supports P2MP 248 MPLS-TE signaling ([RSVP-P2MP]). 250 5-7 Reserved for future assignments by IANA. 252 5. Elements of procedure 254 5.1. OSPF 256 The TE Node Capability Descriptor TLV is advertised, within an OSPFv2 257 Router Information LSA (Opaque type of 4 and Opaque ID of 0) 258 or an OSPFv3 Router Information LSA (function code of 12) which are 259 defined in [OSPF-CAP]. As such, elements of procedure are inherited 260 from those defined in [RFC2328], [RFC2740], and [OSPF-CAP]. 262 The TE Node Capability Descriptor TLV advertises capabilities that 263 may be taken into account as constraints during path selection. Hence 264 its flooding scope is area-local, and it MUST be carried within 265 OSPFv2 type 10 Router Information LSA (as defined in [RFC2370]) or an 266 OSPFv3 Router Information LSA with the S1 bit set and the S2 bit 267 cleared (as defined in [RFC2740]). 269 A router MUST originate a new OSPF router information LSA whenever 270 the content of the TE Node Capability Descriptor TLV changes or 271 whenever required by the regular OSPF procedure (LSA refresh (every 272 LSRefreshTime)). 274 The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear 275 more than once in an OSPF Router Information LSA. If a TE Node 276 Capability Descriptor TLV appears more than once in an OSPF Router 277 Information LSA, only the first occurrence MUST be processed and 278 other MUST be ignored. 280 When an OSPF LSA does not contain any TE Node capability Descriptor 281 TLV, this means that the TE Capabilities of that LSR are unknown. 283 Note that a change in any of these capabilities MAY trigger CSPF 284 computation, but MUST NOT trigger normal SPF computation. 286 Note also that TE node capabilities are expected to be fairly static. 287 They may change as the result of configuration change, or software 288 upgrade. This is expected not to appear more than once a day. 290 5.2. IS-IS 292 The TE Node Capability sub-TLV is carried within an IS-IS CAPABILITY 293 TLV defined in [IS-IS-CAP]. As such, elements of procedure are 294 inherited from those defined in [IS-IS-CAP]. 296 The TE Node Capability Descriptor TLV advertises capabilities that 297 may be taken into account as constraints during path selection. Hence 298 its flooding is area-local, and MUST be carried within an IS-IS 299 CAPABILITY TLV having the S flag cleared. 301 An IS-IS router MUST originate a new IS-IS LSP whenever the content 302 of any of the TE Node Capability TLV changes or whenever required by 303 the regular IS-IS procedure (LSP refresh). 305 The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear 306 more than once in an ISIS Router Capability TLV. If a TE Node 307 Capability Descriptor TLV appears more than once in an ISIS 308 Capability TLV, only the first occurrence MUST be processed, other 309 occurrences MUST be ignored. 311 When an IS-IS LSP does not contain any TE Node capability Descriptor 312 TLV, this means that the TE Capabilities of that LSR are unknown. 314 Note that a change in any of these capabilities MAY trigger CSPF 315 computation, but MUST NOT trigger normal SPF computation. 317 Note also that TE node capabilities are expected to be fairly static. 318 They may change as the result of configuration change, or software 319 upgrade. This is expected not to appear more than once a day. 321 6. Backward compatibility 323 The TE Node Capability Descriptor TLVs defined in this document do 324 not introduce any interoperability issue. For OSPF, a router not 325 supporting the TE Node Capability Descriptor TLV will just silently 326 ignore the TLV as specified in [OSPF-CAP]. For IS-IS a router not 327 supporting the TE Node Capability Descriptor TLV will just silently 328 ignore the TLV as specified in [IS-IS-CAP]. 330 When the TE Node capability Descriptor TLV is absent, this means that 331 the TE Capabilities of that LSR are unknown. 333 The absence of a word of capability flags in OSPF or an octet of 334 capability flags in IS-IS means that these capabilities are unknown. 336 7. Security Considerations 338 This document specifies the content of the TE Node Capability 339 Descriptor TLV in ISIS and OSPF, to be used for (G)MPLS-TE path 340 computation. As this TLV is not used for SPF computation or normal 341 routing, the extensions specified here have no direct effect on IP 342 routing. Tampering with this TLV may have an effect on Traffic 343 Engineering computation. Mechanisms defined to secure ISIS Link State 344 PDUs [ISIS-HMAC], OSPF LSAs [OSPF-SIG], and their TLVs, can be used 345 to secure this TLV as well. 347 8. IANA Considerations 349 8.1. OSPF TLV 351 IANA is in charge of the assignment of TLV code points for the Router 352 Information LSA defined in [OSPF-CAP]. 353 IANA will assign a new codepoint for the TE Node Capability 354 Descriptor TLV defined in this document and carried within the Router 355 Information LSA (suggested value = 1). 357 8.2. ISIS sub-TLV 359 IANA is in charge of the assignment of sub-TLV code points for the 360 ISIS CAPABILITY TLV defined in [ISIS-CAP]. 361 IANA will assign a new codepoint for the TE Node Capability 362 Descriptor sub-TLV defined in this document, and carried within the 363 ISIS CAPABILITY TLV (suggested value = 1). 365 8.3. Capability Registry 367 IANA is requested to manage the space of capability bit flags carried 368 within the OSPF and ISIS TE Node Capability Descriptor, numbering 369 them in the usual IETF notation starting at zero, with the most 370 significant bit as bit zero. A single registry must be defined for 371 both protocols. 372 New bit numbers may be allocated only by an IETF Consensus action. 373 Each bit should be tracked with the following qualities: 374 - Bit number 375 - Defining RFC 376 - Name of bit 378 Five TE node capabilities are defined in this document and must be 379 assigned by IANA. Here are the suggested values: 380 1 : B Bit = P2MP Branch LSR capability ([RFC4461]) 381 2 : E bit = P2MP Bud LSR capability ([RFC4461]) 382 3 : M bit = MPLS-TE support ([RFC3209]) 383 4 : G bit = GMPLS support (RFC3473)) 384 5 : P bit = P2MP RSVP-TE support ([RSVP-P2MP]) 386 9. Acknowledgments 388 We would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri 389 Papadimitriou, Acee Lindem and David Ward for their useful comments 390 and suggestions. 392 We would also like to thank authors of [RFC4420] and [OSPF-CAP] from 393 which some text of this document has been inspired. 395 10. References 397 10.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 404 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 405 RFC 2740, December 1999. 407 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 408 July 1998. 410 [RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to 411 Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. 413 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 414 Routing Exchange Protocol " ISO 10589. 416 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 417 Extensions to OSPF Version 2", RFC 3630, September 2003. 419 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 420 Engineering", RFC 3784, June 2004. 422 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 423 J.P., "Extensions to OSPF for advertising Optional Router 424 Capabilities", draft-ietf-ospf-cap, work in progress. 426 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 427 router information", draft-ietf-isis-caps, work in progress. 429 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 430 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 431 July 2003. 433 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 434 Digital Signatures", RFC 2154, June 1997. 436 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 437 tunnels", RFC 3209, December 2001. 439 [RFC3473] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 440 RFC 3473, January 2003. 442 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 443 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 444 p2mp, work in progress. 446 10.2. Informative References 448 [RFC4203] Kompella, K., Rekhter, Y., "OSPF extensions in support of 449 Generalized Multi-protocol Label Switching", RFC4203, October 2005. 451 [RFC4205] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 452 Generalized Multi-protocol Label Switching", RFC4205, October 2005. 454 [RFC4420] Farrel, A., and al., "Encoding of attributes for MPLS LSPs 455 establishment Using RSVP-TE", RFC4420, February 2006. 457 11. Editors' Addresses 459 Jean-Philippe Vasseur 460 Cisco Systems, Inc. 461 1414 Massachusetts Avenue 462 Boxborough , MA - 01719 463 USA 464 Email: jpv@cisco.com 466 Jean-Louis Le Roux 467 France Telecom 468 2, avenue Pierre-Marzin 469 22307 Lannion Cedex 470 FRANCE 471 Email: jeanlouis.leroux@orange-ftgroup.com 473 12. Contributors' Addresses 475 Seisho Yasukawa 476 NTT 477 3-9-11 Midori-cho, 478 Musashino-shi, Tokyo 180-8585, Japan 479 Email: s.yasukawa@hco.ntt.co.jp 481 Stefano Previdi 482 Cisco Systems, Inc 483 Via Del Serafico 200 484 Roma, 00142 485 Italy 486 Email: sprevidi@cisco.com 487 Peter Psenak 488 Cisco Systems, Inc 489 Pegasus Park DE Kleetlaan 6A 490 Diegmen, 1831 491 BELGIUM 492 Email: ppsenak@cisco.com 494 Paul Mabbey 495 Comcast 496 USA 498 13. Intellectual Property Statement 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org. 522 Disclaimer of Validity 524 This document and the information contained herein are provided 525 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 526 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 527 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 528 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 529 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 530 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 531 FOR A PARTICULAR PURPOSE. 533 Copyright Statement 535 Copyright (C) The IETF Trust (2006). This document is subject to the 536 rights, licenses and restrictions contained in BCP 78, and except as 537 set forth therein, the authors retain all their rights.