idnits 2.17.1 draft-ietf-ccamp-te-node-cap-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2007) is 6213 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) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 3567 (Obsoleted by RFC 5304) -- 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: 4 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J.P. Vasseur (Editor) 3 Network Working Group Cisco Systems, Inc. 4 Intended Status: Proposed Standard J.L. Le Roux (Editor) 5 France Telecom 6 Expires: October 2007 7 April 2007 9 IGP Routing Protocol Extensions for Discovery of Traffic Engineering 10 Node Capabilities 12 draft-ietf-ccamp-te-node-cap-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of 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 Abstract 39 It is highly desired in several cases, to take into account Traffic 40 Engineering (TE) node capabilities during Multi Protocol Label 41 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered 42 Label Switched Path (TE-LSP) selection, such as for instance the 43 capability to act as a branch Label Switching Router (LSR) of a 44 Point-To-MultiPoint (P2MP) LSP. This requires advertising these 45 capabilities within the Interior Gateway Protocol (IGP). For that 46 purpose, this document specifies Open Shortest Path First (OSPF) and 47 Intermediate System-Intermediate System (IS-IS) traffic engineering 48 extensions for the advertisement of control plane and data plane 49 traffic engineering node capabilities. 51 Table of Contents 53 1. Terminology.................................................3 54 2. Introduction................................................3 55 3. TE Node Capability Descriptor...............................4 56 3.1. Description.................................................4 57 3.2. Required Information........................................4 58 4. TE Node Capability Descriptor TLV formats...................5 59 4.1. OSPF TE Node Capability Descriptor TLV format...............5 60 4.2. IS-IS TE Node Capability Descriptor sub-TLV format..........6 61 5. Elements of procedure.......................................7 62 5.1. OSPF........................................................7 63 5.2. IS-IS.......................................................8 64 6. Backward compatibility......................................8 65 7. Security Considerations.....................................9 66 8. IANA considerations.........................................9 67 8.1. OSPF TLV....................................................9 68 8.2. ISIS sub-TLV................................................9 69 8.3. Capability Registry.........................................9 70 9. Acknowledgments............................................10 71 10. References.................................................10 72 10.1. Normative references.......................................10 73 10.2. Informative References.....................................11 74 11. Editors' Addresses.........................................11 75 12. Contributors' Addresses....................................11 76 13. Intellectual Property Statement............................12 78 1. Terminology 80 This document uses terminologies defined in [RFC3031], [RFC3209] and 81 [RFC4461]. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Introduction 89 Multi Protocol Label Switching-Traffic Engineering (MPLS-TE) routing 90 ([RFC3784], [RFC3630], [OSPFv3-TE]) relies on extensions to link 91 state Interior Gateway Protocols (IGP) ([IS-IS], [RFC1195], 92 [RFC2328], [RFC2740]) in order to advertise Traffic Engineering (TE) 93 link information used for constraint based routing. Further 94 Generalized MPLS (GMPLS) related routing extensions are defined in 95 [RFC4205] and [RFC4203]. 97 It is desired to complement these routing extensions in order to 98 advertise TE node capabilities, in addition to TE link information. 99 These TE node capabilities will be taken into account as constraints 100 during path selection. 102 Indeed, it is useful to advertise data plane TE node capabilities, 103 such as the capability for a Label Switching Router (LSR) to be a 104 branch LSR or a bud-LSR of a Point-To-MultiPoint (P2MP) Label 105 Switched Path (LSP). These capabilities can then be taken into 106 account as constraints when computing the route of TE LSPs. 108 It is also useful to advertise control plane TE node capabilities 109 such as the capability to support GMPLS signaling for a packet LSR, 110 or the capability to support P2MP (Point to Multipoint) TE LSP 111 signaling. This allows selecting a path that avoids nodes that do 112 not support a given control plane feature, or triggering a mechanism 113 to support such nodes on a path. Hence this facilitates backward 114 compatibility. 116 For that purpose, this document specifies IGP (OSPF and IS-IS) 117 extensions in order to advertise data plane and control plane 118 capabilities of a node. 120 A new TLV is defined for OSPF, the TE Node Capability Descriptor TLV, 121 to be carried within the Router Information LSA ([OSPF-CAP]). 122 A new sub-TLV is defined for IS-IS, the TE Node Capability Descriptor 123 sub-TLV, to be carried within the IS-IS Capability TLV ([IS-IS-CAP]). 125 3. TE Node Capability Descriptor 127 3.1. Description 129 LSRs in a network may have distinct control plane and data plane 130 Traffic Engineering capabilities. The TE Node Capability Descriptor 131 information defined in this document describes data and control plane 132 capabilities of an LSR. Such information can be used during path 133 computation so as to avoid nodes that do not support a given TE 134 feature either in the control or data plane, or to trigger procedures 135 to handle these nodes along the path (e.g, trigger LSP hierarchy to 136 support a legacy transit LSR on a P2MP LSP (see [RSVP-P2MP])). 138 3.2. Required Information 140 The TE Node Capability Descriptor contains a variable length set of 141 bit flags, where each bit corresponds to a given TE node capability. 143 Five TE Node Capabilities are defined in this document: 145 - B bit: when set, this flag indicates that the LSR can act 146 as a branch node on a P2MP LSP (see [RFC4461]); 147 - E bit: when set, this flag indicates that the LSR can act 148 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 149 transit and egress (see [RFC4461]). 150 - M bit: when set, this flag indicates that the LSR supports 151 MPLS-TE signaling ([RFC3209]); 152 - G bit: when set this flag indicates that the LSR supports 153 GMPLS signaling ([RFC3473]); 154 - P bit: when set, this flag indicates that the LSR supports 155 P2MP MPLS-TE signaling ([RSVP-P2MP]). 157 Note that new capability bits may be added in the future if required. 159 4. TE Node Capability Descriptor TLV formats 161 4.1. OSPF TE Node Capability Descriptor TLV format 163 The OSPF TE Node Capability Descriptor TLV is a variable length TLV 164 that contains a series of bit flags, where each bit correspond to a 165 TE node capability. 167 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 168 Router Information LSA which is defined in [OSPF-CAP]. 170 The format of the OSPF TE Node Capability Descriptor TLV is the same 171 as the TLV format used by the Traffic Engineering Extensions to OSPF 172 [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 173 octets specifying the length of the value field and a value field. 175 The OSPF TE Node Capability Descriptor TLV has the following format: 177 TYPE: Assigned by IANA - see Section 8.1. 178 LENGTH: Variable (multiple of 4). 179 VALUE: Array of units of 32 flags numbered from the most 180 significant bit as bit zero, where each bit represents 181 a TE node capability. 183 The following bits are defined: 185 Bit Capabilities 187 0 B bit: P2MP Branch Node capability: When set this indicates 188 that the LSR can act as a branch node on a P2MP LSP 189 [RFC4461]. 190 1 E bit: P2MP Bud-LSR capability: When set, this indicates 191 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 192 LSR that is both transit and egress [RFC4461]. 193 2 M bit: If set this indicates that the LSR supports MPLS-TE 194 signaling ([RFC3209]). 195 3 G bit: If set this indicates that the LSR supports GMPLS 196 signaling ([RFC3473]). 197 4 P bit: If set this indicates that the LSR supports P2MP 198 MPLS-TE signaling ([RSVP-P2MP]). 200 5-31 Reserved for future assignments by IANA. 202 4.2. IS-IS TE Node Capability Descriptor sub-TLV format 204 The IS-IS TE Node Capability Descriptor sub-TLV is a variable length 205 sub-TLV that contains a series of bit flags, where each bit 206 correspond to a TE node capability. 208 The IS-IS TE Node Capability Descriptor sub-TLV is carried within an 209 IS-IS CAPABILITY TLV which is defined in [IS-IS-CAP]. 211 The format of the IS-IS TE Node Capability sub-TLV is the same as the 212 TLV format used by the Traffic Engineering Extensions to IS-IS 213 [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 214 octet specifying the TLV length and a value field. 216 The IS-IS TE Node Capability Descriptor sub-TLV has the following 217 format: 219 TYPE: Assigned by IANA - see Section 8.2. 220 LENGTH: Variable 221 VALUE: Array of units of 8 flags numbered from the most 222 significant bit as bit zero, where each bit represents 223 a TE node capability. 225 The following bits are defined: 227 Bit Capabilities 229 0 B bit: P2MP Branch Node capability: When set this indicates 230 that the LSR can act as a branch node on a P2MP LSP 231 [RFC4461]. 232 1 E bit: P2MP Bud-LSR capability: When set, this indicates 233 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 234 LSR that is both transit and egress [RFC4461]. 235 2 M bit: If set this indicates that the LSR supports MPLS-TE 236 signaling ([RFC3209]). 237 3 G bit: If set this indicates that the LSR supports GMPLS 238 signaling ([RFC3473]). 239 4 P bit: If set this indicates that the LSR supports P2MP 240 MPLS-TE signaling ([RSVP-P2MP]). 242 5-7 Reserved for future assignments by IANA. 244 5. Elements of procedure 246 5.1. OSPF 248 The TE Node Capability Descriptor TLV is advertised, within an OSPFv2 249 Router Information LSA (Opaque type of 4 and Opaque ID of 0) 250 or an OSPFv3 Router Information LSA (function code of 12) which are 251 defined in [OSPF-CAP]. As such, elements of procedure are inherited 252 from those defined in [RFC2328], [RFC2740], and [OSPF-CAP]. 254 The TE Node Capability Descriptor TLV advertises capabilities that 255 may be taken into account as constraints during path selection. Hence 256 its flooding scope is area-local, and it MUST be carried within 257 OSPFv2 type 10 Router Information LSA (as defined in [RFC2370]) or an 258 OSPFv3 Router Information LSA with the S1 bit set and the S2 bit 259 cleared (as defined in [RFC2740]). 261 A router MUST originate a new OSPF router information LSA whenever 262 the content of the TE Node Capability Descriptor TLV changes or 263 whenever required by the regular OSPF procedure (LSA refresh (every 264 LSRefreshTime)). 266 The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear 267 more than once in an OSPF Router Information LSA. If a TE Node 268 Capability Descriptor TLV appears more than once in an OSPF Router 269 Information LSA, only the first occurrence MUST be processed and 270 other MUST be ignored. 272 When an OSPF LSA does not contain any TE Node capability Descriptor 273 TLV, this means that the TE Capabilities of that LSR are unknown. 275 Note that a change in any of these capabilities MAY trigger CSPF 276 computation, but MUST NOT trigger normal SPF computation. 278 Note also that TE node capabilities are expected to be fairly static. 279 They may change as the result of configuration change, or software 280 upgrade. This is expected not to appear more than once a day. 282 5.2. IS-IS 284 The TE Node Capability sub-TLV is carried within an IS-IS CAPABILITY 285 TLV defined in [IS-IS-CAP]. As such, elements of procedure are 286 inherited from those defined in [IS-IS-CAP]. 288 The TE Node Capability Descriptor sub-TLV advertises capabilities 289 that may be taken into account as constraints during path selection. 290 Hence its flooding is area-local, and MUST be carried within an IS-IS 291 CAPABILITY TLV having the S flag cleared. 293 An IS-IS router MUST originate a new IS-IS LSP whenever the content 294 of any of the TE Node Capability sub-TLV changes or whenever required 295 by the regular IS-IS procedure (LSP refresh). 297 The TE Node Capability Descriptor sub-TLV is OPTIONAL and MUST NOT 298 appear more than once in an ISIS Router Capability TLV. 300 When an IS-IS LSP does not contain any TE Node capability Descriptor 301 sub-TLV, this means that the TE Capabilities of that LSR are unknown. 303 Note that a change in any of these capabilities MAY trigger CSPF 304 computation, but MUST NOT trigger normal SPF computation. 306 Note also that TE node capabilities are expected to be fairly static. 307 They may change as the result of configuration change, or software 308 upgrade. This is expected not to appear more than once a day. 310 6. Backward Compatibility 312 The TE Node Capability Descriptor TLVs defined in this document do 313 not introduce any interoperability issue. For OSPF, a router not 314 supporting the TE Node Capability Descriptor TLV will just silently 315 ignore the TLV as specified in [OSPF-CAP]. For IS-IS a router not 316 supporting the TE Node Capability Descriptor sub-TLV will just 317 silently ignore the sub-TLV as specified in [IS-IS-CAP]. 319 When the TE Node capability Descriptor TLV is absent, this means that 320 the TE Capabilities of that LSR are unknown. 322 The absence of a word of capability flags in OSPF or an octet of 323 capability flags in IS-IS means that these capabilities are unknown. 325 7. Security Considerations 327 This document specifies the content of the TE Node Capability 328 Descriptor TLV in ISIS and OSPF, to be used for (G)MPLS-TE path 329 computation. As this TLV is not used for SPF computation or normal 330 routing, the extensions specified here have no direct effect on IP 331 routing. Tampering with this TLV may have an effect on Traffic 332 Engineering computation. Mechanisms defined to secure ISIS Link State 333 PDUs [RFC3567], OSPF LSAs [RFC2154], and their TLVs, can be used to 334 secure this TLV as well. 336 8. IANA considerations 338 8.1. OSPF TLV 340 [OSPF-CAP] defines a new code point registry for TLVs carried in the 341 Router Information LSA defined in [OSPF-CAP]. 343 IANA is requested to make a new codepoint assignment from that 344 registry for the TE Node Capability Descriptor TLV defined in this 345 document and carried within the Router Information LSA. The value 1 346 is suggested. See Section 4.1 of this document. 348 8.2. ISIS sub-TLV 350 [IS-IS-CAP] defines a new code point registry for sub-TLVs carried in 351 the ISIS CAPABILITY TLV defined in [IS-IS-CAP]. 353 IANA is requested to make a new codepoint assignment from that 354 registry for the TE Node Capability Descriptor sub-TLV defined in 355 this document, and carried within the ISIS CAPABILITY TLV. The value 356 1 is suggested. See Section 4.2 of this document. 358 8.3. Capability Registry 360 IANA is requested to create a new registry to manage the space of 361 capability bit flags carried within the OSPF and ISIS TE Node 362 Capability Descriptor. 364 A single registry must be defined for both protocols. It is suggested 365 that a new base registry be created to cover IGP-TE registries that 366 apply to both OSPF and ISIS, and that the new registry requested by 367 this document should be a sub-registry of this new bas registry. 369 Bits in the new regstry should be numbered in the usual IETF notation 370 starting with the most significant bit as bit zero. 372 New bit numbers may be allocated only by an IETF Consensus action. 374 Each bit should be tracked with the following qualities: 375 - Bit number 376 - Defining RFC 377 - Name of bit 379 IANA is requested to make assignments for the five TE node 380 capabilities defined in this document (see Sections 8.1 and 8.2) 381 using the following suggested values: 383 Bit No. Name Reference 384 --------+---------------------------------------+----------- 385 1 B bit: P2MP Branch LSR capability [This.I-D] 386 2 E bit: P2MP Bud LSR capability [This.I-D] 387 3 M bit: MPLS-TE support [This.I-D] 388 4 G bit: GMPLS support [This.I-D] 389 5 P bit: P2MP RSVP-TE support [This.I-D] 391 9. Acknowledgments 393 We would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri 394 Papadimitriou, Acee Lindem and David Ward for their useful comments 395 and suggestions. 397 We would also like to thank authors of [RFC4420] and [OSPF-CAP] by 398 which some text of this document has been inspired. 400 Adrian Farrel prpeared the final version of this document for 401 submission to the IESG. 403 10. References 405 10.1. Normative references 407 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 408 dual environments", RFC 1195, December 1990. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 415 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 416 July 1998. 418 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 419 RFC 2740, December 1999. 421 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 422 Label Switching Architecture", RFC 3031, January 2001. 424 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 425 tunnels", RFC 3209, December 2001. 427 [RFC3473] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 428 RFC 3473, January 2003. 430 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 431 Extensions to OSPF Version 2", RFC 3630, September 2003. 433 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 434 Engineering", RFC 3784, June 2004. 436 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 437 Routeing Exchange Protocol for use in Conjunction with the 438 Protocol for Providing the Connectionless-mode Network 439 Service (ISO 8473)", ISO 10589. 441 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 442 router information", draft-ietf-isis-caps, work in 443 progress. 445 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 446 J.P., "Extensions to OSPF for advertising Optional Router 447 Capabilities", draft-ietf-ospf-cap, work in progress. 449 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 450 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls- 451 rsvp-te-p2mp, work in progress. 453 10.2. Informative References 455 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 456 Digital Signatures", RFC 2154, June 1997. 458 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 459 Intermediate System (IS-IS) Cryptographic Authentication", 460 RFC 3567, July 2003. 462 [RFC4203] Kompella, K., Rekhter, Y., "OSPF extensions in support of 463 Generalized Multi-protocol Label Switching", RFC4203, 464 October 2005. 466 [RFC4205] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 467 Generalized Multi-protocol Label Switching", RFC4205, 468 October 2005. 470 [RFC4420] Farrel, A., and al., "Encoding of attributes for MPLS LSPs 471 establishment Using RSVP-TE", RFC4420, February 2006. 473 [RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to 474 Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 475 2006. 477 [OSPFv3-TE] Ishiguro K., Manral V., Davey A., and Lindem A. "Traffic 478 Engineering Extensions to OSPF version 3", draft-ietf-ospf- 479 ospfv3-traffic, work in progress. 481 11. Editors' Addresses 483 Jean-Philippe Vasseur 484 Cisco Systems, Inc. 485 1414 Massachusetts Avenue 486 Boxborough , MA - 01719 487 USA 488 Email: jpv@cisco.com 490 Jean-Louis Le Roux 491 France Telecom 492 2, avenue Pierre-Marzin 493 22307 Lannion Cedex 494 FRANCE 495 Email: jeanlouis.leroux@orange-ftgroup.com 497 12. Contributors' Addresses 499 Seisho Yasukawa 500 NTT 501 3-9-11 Midori-cho, 502 Musashino-shi, Tokyo 180-8585, Japan 503 Email: s.yasukawa@hco.ntt.co.jp 505 Stefano Previdi 506 Cisco Systems, Inc 507 Via Del Serafico 200 508 Roma, 00142 509 Italy 510 Email: sprevidi@cisco.com 512 Peter Psenak 513 Cisco Systems, Inc 514 Pegasus Park DE Kleetlaan 6A 515 Diegmen, 1831 516 BELGIUM 517 Email: ppsenak@cisco.com 519 Paul Mabbey 520 Comcast 521 USA 523 13. Intellectual Property Statement 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the procedures with respect to rights in RFC documents can be 532 found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org. 547 Disclaimer of Validity 549 This document and the information contained herein are provided 550 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 551 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 552 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 553 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 554 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 555 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 556 FOR A PARTICULAR PURPOSE. 558 Copyright Statement 560 Copyright (C) The IETF Trust (2007). This document is subject to the 561 rights, licenses and restrictions contained in BCP 78, and except as 562 set forth therein, the authors retain all their rights.