idnits 2.17.1 draft-ietf-isis-wg-extlsp-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 527. 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 abstract seems to contain references ([ISO10589], [RFC3786]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 5, 2007) is 5986 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'ISO 10589' is mentioned on line 43, but not defined == Missing Reference: 'IS- IS' is mentioned on line 80, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 106, but not defined == Unused Reference: 'RFC 3784' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC 4205' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'BCP9' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'BCP14' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'BCP26' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 478, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3786 (Obsoleted by RFC 5311) ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-11 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson (Ed.) 2 Arbor Networks 3 Les Ginsberg 4 Stefano Previdi 5 Mike Shand 6 Cisco Systems 7 Expires: June 2008 December 5, 2007 8 Intended Status: Proposed Standard 10 Simplified Extension of LSP Space for IS-IS 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This draft describes a simplified method for extending the LSP space 43 beyond the 256 Link State PDU (LSP) limit defined in [ISO 10589]. 44 This method is intended as a preferred replacement for the method 45 defined in [RFC 3786]. 47 Table of Contents 49 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Specification of Requirements. . . . . . . . . . . . . . . . . 4 51 3. Definition of Commonly Used Terms. . . . . . . . . . . . . . . 4 52 4. Utilizing Additional System IDs. . . . . . . . . . . . . . . . 5 53 4.1. Additional Information in Extended LSPs . . . . . . . . . . 5 54 4.2. Extended LSP Restrictions . . . . . . . . . . . . . . . . . 6 55 4.2.1. TLVs Which MUST NOT Appear . . . . . . . . . . . . . . . 6 56 4.2.2. Leaf Advertisements in Extended LSPs . . . . . . . . . . 6 57 4.2.3. IS Neigbor Advertisement Restrictions. . . . . . . . . . 7 58 4.2.4. Area Adresses. . . . . . . . . . . . . . . . . . . . . . 8 59 4.2.5. Overload, Attached, Partition Repair Bits. . . . . . . . 8 60 4.3. Originating LSP Requirements. . . . . . . . . . . . . . . . 8 61 4.4. IS Alias ID TLV (IS-Alias). . . . . . . . . . . . . . . . . 8 62 4.5. New TLVs in Support of IS Neighbor Attributes . . . . . . . 9 63 5. Comparison with the RFC 3786 Solution. . . . . . . . . . . . . 10 64 6. Deployment Considerations. . . . . . . . . . . . . . . . . . . 10 65 6.1. Advertising New TLVs in Extended LSPs . . . . . . . . . . . 11 66 6.2. Reachability and non-SPF TLV Staleness. . . . . . . . . . . 11 67 6.3. Normal LSP OL State and Use of Extended LSPs. . . . . . . . 11 68 6.4. Moving Neighbor Attribute Information to Extended LSPs. . . 11 69 6.5. Advertising Leaf Information in Extended LSPs . . . . . . . 12 70 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 71 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. Normative References. . . . . . . . . . . . . . . . . . . . 14 74 9.2. Informative References. . . . . . . . . . . . . . . . . . . 14 75 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 15 77 1. Overview 79 [IS-IS] defines the set of LSP fragments which may be originated by a 80 system at each level. This set is limited to 256 fragments. [IS- IS] 81 also defines a maximum value for an LSP fragment 82 (originatingLxLSPBufferSize) as 1492 bytes. The carrying capacity of 83 an LSP set, while bounded, has thus far been sufficient for 84 advertisements associated with an area/domain in existing deployment 85 scenarios. However, the definition of additional information to be 86 included in LSPs (e.g. multitopology support, traffic engineering 87 information, router capabilities, etc.) has the potential to exceed 88 the carrying capacity of an LSP set. 90 This issue first drew interest when traffic engineering extensions 91 were introduced. This interest resulted in the solution defined in 92 RFC 3786. However, that solution suffers from restrictions required 93 to maintain interoperability with systems which do not support the 94 extensions. 96 This document defines extensions which allow a system to exceed the 97 256 fragment limit and do so in a way which has no interoperability 98 issues with systems which do not support the extension. It is seen as 99 a simpler and therefore preferred solution to the problem. 101 2. Specification of Requirements 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC 2119]. 107 3. Definition of Commonly Used Terms 109 This section provides definitions for terms that are used throughout 110 the text. The terminology is consistent with that used in RFC 3786. 112 Originating System: A physical IS running the IS-IS protocol. As 113 this document describes a method which allows a single physical IS to 114 originate LSPs on behalf of multiple virtual ISs, the Originating 115 System represents the single physical IS. 117 Normal system-id: The system-id of an Originating System as defined 118 by [IS-IS]. 120 Additional system-id: A system-id other than the "Normal system-id" 121 that is assigned by the network administrator to an Originating 122 System in order to allow the generation of extended LSP fragments. 123 The Additional system-id, like the Normal system-id, must be unique 124 throughout the routing area (Level-1) or domain (Level-2). 126 Original LSP: An LSP using the Normal system-id in its LSP ID. 128 Extended LSP: An LSP using an Additional system-id in its LSP ID. 130 LSP set: Logical LSP. A group of LSP fragments (for a given level) 131 which have the same LSPID. This term is used to resolve the ambiguity 132 between a logical LSP and an LSP fragment, both of which are 133 sometimes termed "LSP". 135 Extended LSP set: An LSP set consisting of LSP fragments using an 136 Additional system-id. 138 Extension-capable IS: An IS implementing the mechanisms described in 139 this document. 141 4. Utilizing Additional System IDs 143 This extension allows an Originating System to be assigned additional 144 system-ids which may be used to generate additional LSP sets. The 145 additional system-ids are subject to the same restrictions as normal 146 system-ids i.e. when used at Level-1 the additional system-id MUST be 147 unique within the Level-1 area. When used at Level-2 the additional 148 system-id MUST be unique within the domain. 150 Extended LSPs are treated by the IS-IS Update Process in the same 151 manner as normal LSPs i.e. the same rules as to generation, flooding, 152 purging, etc. apply. In particular, if the Extended LSP with LSP 153 Number zero and remaining lifetime > 0 is not present for a 154 particular additional system-id then none of the extended LSPs in 155 that Extended LSP set shall be processed. 157 4.1. Additional Information in Extended LSPs 159 Fragment 0 of an Extended LSP Set MUST include the new IS alias ID 160 TLV defined in Section 4.4. This allows the Extended LSP set to be 161 associated with the Originating System which generated the LSP(s). 163 4.2. Extended LSP Restrictions 165 The following restrictions on the information which may appear in an 166 Extended LSP are defined in order to avoid interoperability issues 167 with systems which do not support the extensions defined in this 168 document. All TLV references are based on the current definitions in 169 the IANA IS-IS TLV Codepoints Registry. 171 4.2.1. TLVs Which MUST NOT Appear 173 The following TLVs MUST NOT appear in an Extended LSP: 175 TLV Name (#) 176 ----------- 177 ES Neighbors (3) 178 Part. DIS (4) 179 Prefix Neighbors (5) 181 If any of the TLVs listed above appear in an Extended LSP, an 182 Extension Capable IS MUST ignore those TLVs on receipt and SHOULD 183 report an error. Other TLVs in that extended LSP set MUST be 184 processed normally. 186 4.2.2. Leaf Advertisements in Extended LSPs 188 Advertisement of leaf information in Extended LSPs is allowed. 189 Inclusion of such information requires the advertisement of a 190 neighbor between the Originating System and the Virtual IS associated 191 with the extended LSP set in which the leaf advertisements appear. 192 See section 4.2.3. 194 When leaf advertisements for multiple topologies (see [M-IS-IS]) are 195 included in an Extended LSP set, the multi-topology TLV (229) MUST 196 include all topologies for which a leaf advertisement is included. 198 The following TLVs fall into this category: 200 TLV Name (#) 201 ----------- 202 IP Int. Reach (128) 203 IP Ext. Address (130) 204 The extended IP reachability TLV (135) 205 MT IP Reach (235) 206 IPv6 IP Reach (236) 207 MT IPv6 IP Reach (237) 209 4.2.3. IS Neigbor Advertisement Restrictions 211 Advertisement of IS Neighbor Reachability in an Extended LSP is 212 restricted to advertisement of neighbor reachability to the 213 Originating System. A neighbor to the Originating System MUST be 214 advertised in Extended LSPs. If multi-topology capability [M-IS-IS] 215 is supported, an MT IS Neighbor advertisement to the Originating 216 System IS MUST be included for every topology advertised in the 217 Extended LSP set. Neighbor advertisement(s) to the Originating System 218 in an Extended LSP MUST use a non-zero metric and SHOULD use a metric 219 of MaxLinkMetric-1. 221 The restrictions defined here apply to all TLVs used to advertise 222 neighbor reachability. These include the following TLVs: 224 TLV Name (#) 225 ----------- 226 IS Neighbors (2) 227 The extended IS reachability TLV (22) 228 MT-ISN (222) 230 4.2.4. Area Adresses 232 Fragment #0 of an Extended LSP set MUST include an Area Address TLV. 233 The set of area addresses advertised MUST be a subset of the set of 234 Area Addresses advertised in the normal LSP fragment #0 at the 235 corresponding level. Preferably the advertisement SHOULD be 236 syntactically identical to that included in the normal LSP fragment 237 #0 at the corresponding level. 239 4.2.5. Overload, Attached, Partition Repair Bits 241 The Overload (OL), Attached (ATT), and Partition Repair (P) bits MUST 242 be set to 0 in all Extended LSP fragments. 244 Note that ISs NOT supporting these extensions will interpret these 245 bits normally in Extended LSPs they receive. If the ATT bit were set 246 in an Extended LSP this could indicate that the Virtual IS is 247 attached to other areas when the Originating System is not. This 248 might cause legacy systems to use the Virtual IS as a default exit 249 point from the area. 251 4.3. Originating LSP Requirements 253 The Original LSP set MUST include a neighbor to the Virtual IS 254 associated with each Extended LSP set generated. If multi-topology 255 capability [M-IS-IS] is supported, an MT IS Neighbor advertisement to 256 the Virtual IS MUST be included for every topology advertised in the 257 Extended LSP set. The neighbor advertisement(s) in the Original LSP 258 MUST specify a metric of zero. This guarantees that the two way 259 connectivity check between Originating System and Virtual IS will 260 succeed and that the cost of reaching the Virtual IS is the same as 261 the cost to reach the Originating System. 263 4.4. IS Alias ID TLV (IS-Alias) 265 The IS-Alias TLV allows extension-capable ISs to recognize the 266 Originating System of an Extended LSP set. It identifies the Normal 267 system-id of the Originating System. 269 Type 24 270 Length # of octets in the value field (7 to 255) 271 Value 273 No. of octets 274 +-----------------------+ 275 | Normal System-id | 6 276 +-----------------------+ 277 | Sub-TLV length | 1 278 +-----------------------+ 279 | Sub-TLVs (optional) | 0 to 248 280 +-----------------------+ 282 Normal system-id 284 The Normal system-id of the Originating System 286 Sub-TLVs length 288 Total length of all sub-TLVs. 290 Sub-TLVs 292 No subTLVs are defined in this document. Should future extensions 293 define subTLVs, the subTLVs MUST be formatted as described in RFC 294 3784. 296 4.5. New TLVs in Support of IS Neighbor Attributes 298 One of the major sources of additional information in LSPs is the 299 subTLV information associated with the extended IS reachability TLV 300 (22) and MT IS Neighbor TLV (222). This includes (but is not limited 301 to) information required in support of Traffic Engineering (TE) as 302 defined in RFC 3784 and RFC 4205. The restrictions defined in this 303 document prohibit the presence of TLV 22 and/or TLV 222 in Extended 304 LSPs except to advertise the neighbor relationship to the Originating 305 System. In the event that there is a need to advertise in Extended 306 LSPs such information associated with neighbors of the Originating 307 System, it is necessary to define new TLVs to carry the subTLV 308 information. 310 Two new TLVs are therefore defined. 312 1) IS Neighbor Attribute TLV (23). It is identical in format to the 313 Extended IS Reachability TLV (22). 315 2) MT IS Neighbor Attribute TLV (223). It is identical in format to 316 the MT IS Neighbor TLV (222). 318 These new TLVs MAY be included in Original LSPs or Extended LSPs. 319 Regardless of the type of LSP in which the TLVs appear, the 320 information pertains to the neighbor relationship between the 321 Originating System and the IS identified in the TLV. 323 These TLVs MUST NOT be used to infer that a neighbor relationship 324 exists in the absence of TLV 22 or TLV 222 (whichever applies) in the 325 Originating LSP set for the specified neighbor. This restriction is 326 necessary in order to maintain compatibility with systems which do 327 not support these extensions. 329 5. Comparison with the RFC 3786 Solution 331 This document utilizes the same basic mechanism (additional system- 332 ids) as RFC 3786 to allow an originating system to generate more than 333 256 LSP fragments. It differs from RFC 3786 in that it restricts the 334 content of Extended LSPs to information which does NOT impact the 335 building of a Shortest Path Tree (SPT). 337 Legacy IS-IS implementations which do not support the extensions 338 defined in this document see the extended LSPs as information 339 associated with a system which is reachable only via the Originating 340 System. As no other systems are reachable via the Virtual ISs, the 341 SPF calculation in legacy ISs is therefore consistent with that 342 performed by extension capable ISs. There is therefore no need for 343 the two different operating modes defined in RFC 3786. 345 There is also no need for the special handling of the original LSP 346 set and the extended LSP set(s) as a single Logical LSP during the 347 SPF as specified in Section 5 of RFC 3786. 349 6. Deployment Considerations 351 There are a number of deployment considerations which limit the 352 usefulness of extended LSPs unless all systems are extension-capable 353 ISs. 355 6.1. Advertising New TLVs in Extended LSPs 357 As extended LSPs MAY be utilized to advertise TLVs associated with 358 other protocol extensions (definition of which is outside the scope 359 of this document) and/or the extensions defined in Section 4.4 of 360 this document, it is obvious that the utilization of the information 361 in extended LSPs by legacy IS-IS implementations will be limited. 362 The implication of this is that as implementations are revised to 363 support the protocol extensions which define new TLVs/subTLVs that 364 MAY be advertised in extended LSPs, the implementation SHOULD also be 365 revised to support the extensions defined in this document so that it 366 is capable of processing the new information whether it appears in 367 normal or extended LSPs. 369 6.2. Reachability and non-SPF TLV Staleness 371 In cases where non-SPF information is advertised in LSPs, it is 372 necessary to determine whether the system which originated the 373 advertisement is reachable in order to guarantee that a receiving IS 374 does not use or leak stale information. As long as the OL bit is NOT 375 set by the Originating System in normal LSPs, reachability to the 376 Virtual IS will be consistent with reachability to the Originating 377 System. Therefore, no special rules are required in this case. 379 6.3. Normal LSP OL State and Use of Extended LSPs 381 If the Originating System sets the OL bit in a normal LSP, legacy 382 systems will see the Virtual ISs associated with that Originating 383 System as unreachable and therefore will not use the information in 384 the corresponding Extended LSPs. Under these circumstances, Extension 385 capable ISs MUST also see the Virtual ISs as unreachable. This 386 avoids potential routing loops in cases where leaf information is 387 advertised in Extended LSPs. 389 6.4. Moving Neighbor Attribute Information to Extended LSPs 391 Section 4.4 defines new TLVs which MAY be used to advertise neighbor 392 attribute information in extended LSPs. In cases where neighbor 393 attribute information associated with the same context (e.g. the same 394 link) appears in both an Original LSP and in one or more Extended LSP 395 Sets, the following rules apply for each attribute: 397 o If the attribute information does not conflict, it MUST be 398 considered additive 400 o If the attribute information conflicts, then the information in 401 the Original LSP, if present, MUST be used. If no information is 402 in the Original LSP, then the information from the Extended LSP 403 with the lowest system-id SHALL be preferred. 405 o In cases where information about the same neighbor/link/attribute 406 appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the 407 same MTID) then the information in TLV 22 (or TLV 222) MUST be 408 used and the information in TLV 23 (or TLV 223) MUST be ignored. 410 Utilization of the new TLVs for neighbor attribute information would 411 provide additional benefits which include: 413 o Elimination of the need for redundant IS neighbor TLVs to be 414 processed as part of the SPF. 416 o Easier support for a set of TE information associated with a 417 single link which exceeds the 255 byte TLV limit by allowing the 418 interpretation of multiple TLVs to be considered additive rather 419 than mutually exclusive. 421 6.5. Advertising Leaf Information in Extended LSPs 423 The need to advertise leaf information in Extended LSPs may arise 424 because of extensive leaking of inter-level information or because of 425 the support of multiple topologies as described in [M-IS-IS]. When 426 leaf information is advertised in Extended LSPs, these LSPs now 427 contain information which MUST be processed in order to correctly 428 update the forwarding plane of an IS. This may increase the frequency 429 of events which trigger forwarding plane updates by ISs in the 430 network. It is therefore recommended that, when possible, leaf 431 information be restricted to the normal LSP set. 433 7. Security Considerations 435 This document raises no new security issues for IS-IS. 437 8. IANA Considerations 439 This document defines the following new ISIS TLVs that need to be 440 reflected in the ISIS TLV code-point registry: 442 Type Description IIH LSP SNP 443 ---- ----------------------------------- --- --- --- 444 23 IS Neighbor Attribute n y n 445 24 IS Alias ID n y n 446 223 MT IS Neighbor Attribute n y n 448 9. References 450 9.1. Normative References 452 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 453 information exchange protocol for use in conjunction with the 454 Protocol for providing the Connectionless-mode Network Service (ISO 455 8473)," ISO/IEC 10589:2002, Second Edition. 457 [RFC 3784] Smit, H. and T. Li, "Intermediate System to Intermediate 458 System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, 459 June 2004. 461 [RFC 3786] Hermelin, A., Previdi, S. and Shand, M., "Extending the 462 Number of Intermediate to Intermediate (IS-IS) Link State PDU (LSP) 463 Fragments Beyond the 256 Limit," RFC 3786, May 2004. 465 [RFC 4205] Kompella, K. and Rehkter, Y., "Intermediate System to 466 Intermediate System (IS-IS) Extensions in Support of Generalized 467 Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. 469 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", 470 BCP 9, RFC 2026, October 1996. 472 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997 475 [BCP26] Narten, T. and Alvestrand, H., "Guidelines for Writing an 476 IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October 1998 478 [BCP79] Bradner, S. Ed., "Intellectual Property Rights in IETF 479 Technology ", BCP 79 , RFC 3979, March 2005 481 9.2. Informative References 483 [M-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi Topology 484 (MT) Routing in IS-IS", draft-ietf-isis-wg-multi-topology-11.txt 485 (work in progress), October 2005. 487 10. Authors' Addresses 489 Les Ginsberg 490 Cisco Systems 491 Email: ginsberg@cisco.com 493 Stefano Previdi 494 Cisco Systems 495 Email: sprevidi@cisco.com 497 Mike Shand 498 Cisco Systems 499 Email: mshand@cisco.com 501 Danny McPherson 502 Arbor Networks, Inc. 503 Email: danny@arbor.net 505 Intellectual Property Statement 507 The IETF takes no position regarding the validity or scope of any 508 Intellectual Property Rights or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; nor does it represent that it has 512 made any independent effort to identify any such rights. Information 513 on the procedures with respect to rights in RFC documents can be 514 found in BCP 78 and BCP 79. 516 Copies of IPR disclosures made to the IETF Secretariat and any 517 assurances of licenses to be made available, or the result of an 518 attempt made to obtain a general license or permission for the use of 519 such proprietary rights by implementers or users of this 520 specification can be obtained from the IETF on-line IPR repository at 521 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 this standard. Please address the information to the IETF at 527 ietf-ipr@ietf.org. 529 Copyright Statement 531 Copyright (C) The IETF Trust (2007). 533 This document is subject to the rights, licenses and restrictions 534 contained in BCP 78, and except as set forth therein, the authors 535 retain all their rights. 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 540 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 541 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 542 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 543 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 544 PURPOSE. 546 Acknowledgment 548 Funding for the RFC Editor function is provided by the IETF 549 Administrative Support Activity (IASA).