idnits 2.17.1 draft-katz-yeung-ospf-traffic-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 583 has weird spacing: '...for the purpo...' -- 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 (September 2002) is 7866 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) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2370 (ref. '8') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '10') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Katz 3 Internet Draft Juniper Networks 4 Category: Standards Track D. Yeung 5 Expires: March 2003 Procket Networks 6 draft-katz-yeung-ospf-traffic-08.txt K. Kompella 7 Juniper Networks 8 September 2002 10 Traffic Engineering Extensions to OSPF Version 2 11 *** Draft *** 13 Status 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document describes extensions to the OSPF protocol version 2 to 41 support intra-area Traffic Engineering, using Opaque Link State 42 Advertisements. 44 Changes 46 (This section to be removed before publication). 48 Changes -06 version to -07 version 50 Comments from the ADs incorporated, as well as minor editing changes 51 to conform to draft-rfc-editor-rfc2223bis-02.txt. 53 Clean up front page headers. 54 (First page) 55 Clarify that this memo is for *intra-area* TE. 56 (Title, Abstract, section 1.2) 57 Add a "Conventions" section (rfc 2119). 58 (Section 1.3) 59 Clarify what should be done with Reserved field in section 2.2. 60 (Section 2.2) 61 Add an IANA Considerations section. 62 (Section 2.3.2, 2.4.2 and 8) 63 Clarify "IEEE Floating Point Format", and add reference. 64 (Section 2.4.2) 65 Clarify text for Resource Class/Color (match IS-IS TE text). 66 (Section 2.5.9) 67 Add text on originating TE LSAs. 68 (Section 3) 69 Broke up references into Normative and Informative (for now, 70 IS-IS TE is Informative, pending reply from Routing ADs). 71 Add IPR Notices and Full Copyright Notice, as per rfc 2026. 73 Changes from -07 to -08 75 Removed the Reserved field from the LSA ID: Instance is now 24 76 bits (section 2.2). 77 Added wording that if there is a BGP router ID, it should be used 78 as the Router Address (as in ISIS TE draft) (section 2.4.1). 79 Rewrote the Security Considerations; added reference 11. 81 1. Introduction 83 This document specifies a method of adding traffic engineering 84 capabilities to OSPF Version 2 [1]. The architecture of traffic 85 engineering is described in [2]. The semantic content of the 86 extensions is essentially identical to the corresponding extensions 87 to IS-IS [3]. It is expected that the traffic engineering extensions 88 to OSPF will continue to mirror those in IS-IS. 90 The extensions provide a way of describing the traffic engineering 91 topology (including bandwidth and administrative constraints) and 92 distributing this information within a given OSPF area. This 93 topology does not necessarily match the regular routed topology, 94 though this proposal depends on Network LSAs to describe multiaccess 95 links. 97 1.1. Applicability 99 Many of the extensions specified in this document are in response to 100 the requirements stated in [2], and thus are referred to as "traffic 101 engineering extensions", and are also commonly associated with MPLS 102 Traffic Engineering. A more accurate (albeit bland) designation is 103 "extended link attributes", as what is proposed is simply to add more 104 attributes to links in OSPF advertisements. 106 The information made available by these extensions can be used to 107 build an extended link state database just as router LSAs are used to 108 build a "regular" link state database; the difference is that the 109 extended link state database (referred to below as the traffic 110 engineering database) has additional link attributes. Uses of the 111 traffic engineering database include: 113 o monitoring the extended link attributes; 114 o local constraint-based source routing; and 115 o global traffic engineering. 117 For example, an OSPF-speaking device can participate in an OSPF area, 118 build a traffic engineering database, and thereby report on the 119 reservation state of links in that area. 121 In "local constraint-based source routing", a router R can compute a 122 path from a source node A to a destination node B; typically, A is R 123 itself, and B is specified by a "router address" (see below). This 124 path may be subject to various constraints on the attributes of the 125 links and nodes that the path traverses, e.g., use green links that 126 have unreserved bandwidth of at least 10Mbps. This path could then 127 be used to carry some subset of the traffic from A to B, forming a 128 simple but effective means of traffic engineering. How the subset of 129 traffic is determined, and how the path is instantiated is beyond the 130 scope of this document; suffice it to say that one means of defining 131 the subset of traffic is "those packets whose IP destinations were 132 learned from B", and one means of instantiating paths is using MPLS 133 tunnels. As an aside, note that constraint-based routing can be NP- 134 hard, or even unsolvable, depending on the nature of the attributes 135 and constraints and thus many implementations will use heuristics. 136 Consequently, we don't attempt to sketch an algorithm here. 138 Finally, for "global traffic engineering", a device can build a 139 traffic engineering database, input a traffic matrix and an 140 optimization function, crunch on the information, and thus compute 141 optimal or near-optimal routing for the entire network. The device 142 can subsequently monitor the traffic engineering topology and react 143 to changes by recomputing the optimal routes. 145 1.2. Limitations 147 As mentioned above, this document specifies extensions and procedures 148 for intra-area distribution of Traffic Engineering information. 149 Methods for inter-area and inter-AS (Autonomous System) are not 150 discussed here. 152 The extensions specified in this document capture the reservation 153 state of point-to-point links. The reservation state of multiaccess 154 links is not accurately reflected, except in the special case that 155 there are only two devices in the multiaccess subnetwork. 157 This document also does not support unnumbered links. This 158 deficiency is addressed in [4]; see also [5] and [6]. 160 1.3. Conventions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [7]. 166 2. LSA Format 168 2.1. LSA type 170 This extension makes use of the Opaque LSA [8]. 172 Three types of Opaque LSAs exist, each of which has different 173 flooding scope. This proposal uses only Type 10 LSAs, which have 174 area flooding scope. 176 One new LSA is defined, the Traffic Engineering LSA. This LSA 177 describes routers, point-to-point links, and connections to 178 multiaccess networks (similar to a Router LSA). For traffic 179 engineering purposes, the existing Network LSA suffices for 180 describing multiaccess links, so no additional LSA is defined for 181 this purpose. 183 2.2. LSA ID 185 The LSA ID of an Opaque LSA is defined as having eight bits of type 186 and 24 bits of type-specific data. The Traffic Engineering LSA uses 187 type 1. The remaining 24 bits are the Instance field, as follows: 189 0 1 2 3 190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | 1 | Instance | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 The Instance field is an arbitrary value used to maintain multiple 196 Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering 197 LSAs may be sourced by a single system. The LSA ID has no 198 topological significance. 200 2.3. LSA Format Overview 202 2.3.1. LSA Header 204 The Traffic Engineering LSA starts with the standard LSA header: 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | LS age | Options | 10 | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | 1 | Reserved | Instance | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Advertising Router | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | LS sequence number | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | LS checksum | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 2.3.2. TLV Header 222 The LSA payload consists of one or more nested Type/Length/Value 223 (TLV) triplets for extensibility. The format of each TLV is: 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Value... | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 The Length field defines the length of the value portion in octets 234 (thus a TLV with no value portion would have a length of zero). The 235 TLV is padded to four-octet alignment; padding is not included in 236 the length field (so a three octet value would have a length of 237 three, but the total size of the TLV would be eight octets). Nested 238 TLVs are also 32-bit aligned. Unrecognized types are ignored. 240 This memo defines Types 1 and 2. See the IANA Considerations section 241 for allocation of new Types. 243 2.4. LSA payload details 245 An LSA contains one top-level TLV. 247 There are two top-level TLVs defined: 249 1 - Router Address 250 2 - Link 252 2.4.1. Router Address TLV 254 The Router Address TLV specifies a stable IP address of the 255 advertising router that is always reachable if there is any 256 connectivity to it. This is typically implemented as a "loopback 257 address"; the key attribute is that the address does not become 258 unusable if an interface is down. In other protocols this is known 259 as the "router ID," but for obvious reasons this nomenclature is 260 avoided here. If a router advertises BGP routes with the BGP next 261 hop attribute set to the BGP router ID, then the Router Address 262 SHOULD be the same as the BGP router ID. 264 If IS-IS is also active in the domain, this address can also be used 265 to compute the mapping between the OSPF and IS-IS topologies. For 266 example, suppose a router R is advertising both IS-IS and OSPF 267 Traffic Engineering LSAs, and suppose further that some router S is 268 building a single Traffic Engineering Database (TED) based on both 269 IS-IS and OSPF TE information. R may then appear as two separate 270 nodes in S's TED; however, if both the IS-IS and OSPF LSAs generated 271 by R contain the same Router Address, then S can determine that the 272 IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single 273 router. 275 The router address TLV is type 1, and has a length of 4, and the 276 value is the four octet IP address. It must appear in exactly one 277 Traffic Engineering LSA originated by a router. 279 2.4.2. Link TLV 281 The Link TLV describes a single link. It is constructed of a set of 282 sub-TLVs. There are no ordering requirements for the sub-TLVs. 284 Only one Link TLV shall be carried in each LSA, allowing for fine 285 granularity changes in topology. 287 The Link TLV is type 2, and the length is variable. 289 The following sub-TLVs are defined: 291 1 - Link type (1 octet) 292 2 - Link ID (4 octets) 293 3 - Local interface IP address (4 octets) 294 4 - Remote interface IP address (4 octets) 295 5 - Traffic engineering metric (4 octets) 296 6 - Maximum bandwidth (4 octets) 297 7 - Maximum reservable bandwidth (4 octets) 298 8 - Unreserved bandwidth (32 octets) 299 9 - Administrative group (4 octets) 301 This memo defines sub-Types 1 through 9. See the IANA Considerations 302 section for allocation of new sub-Types. 304 The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear 305 exactly once. All other sub-TLVs defined here may occur at most 306 once. These restrictions need not apply to future sub-TLVs. 307 Unrecognized sub-TLVs are ignored. 309 Various values below use the (32 bit) IEEE Floating Point format. 310 For quick reference, this format is as follows: 312 0 1 2 3 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |S| Exponent | Fraction | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 where S is the sign; Exponent is the exponent base 2 in "excess 127" 319 notation; and Fraction is the mantissa - 1, with an implied binary 320 point in front of it. Thus the above represents the value 321 (-1)**(S) * 2**(Exponent-127) * (1 + Fraction) 323 For more details, refer to [9]. 325 2.5. Sub-TLV Details 327 2.5.1. Link Type 329 The Link Type sub-TLV defines the type of the link: 331 1 - Point-to-point 332 2 - Multiaccess 334 The Link Type sub-TLV is TLV type 1, and is one octet in length. 336 2.5.2. Link ID 338 The Link ID sub-TLV identifies the other end of the link. For point- 339 to-point links, this is the Router ID of the neighbor. For 340 multiaccess links, this is the interface address of the designated 341 router. The Link ID is identical to the contents of the Link ID 342 field in the Router LSA for these link types. 344 The Link ID sub-TLV is TLV type 2, and is four octets in length. 346 2.5.3. Local Interface IP Address 348 The Local Interface IP Address sub-TLV specifies the IP address(es) 349 of the interface corresponding to this link. If there are multiple 350 local addresses on the link, they are all listed in this sub-TLV. 352 The Local Interface IP Address sub-TLV is TLV type 3, and is 4N 353 octets in length, where N is the number of local addresses. 355 2.5.4. Remote Interface IP Address 357 The Remote Interface IP Address sub-TLV specifies the IP address(es) 358 of the neighbor's interface corresponding to this link. This and the 359 local address are used to discern multiple parallel links between 360 systems. If the Link Type of the link is Multiaccess, the Remote 361 Interface IP Addess is set to 0.0.0.0 . 363 The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N 364 octets in length, where N is the number of neighbor addresses. 366 2.5.5. Traffic Engineering Metric 368 The Traffic Engineering Metric sub-TLV specifies the link metric for 369 traffic engineering purposes. This metric may be different than the 370 standard OSPF link metric. Typically, this metric is assigned by a 371 network admistrator. 373 The Traffic Engineering Metric sub-TLV is TLV type 5, and is four 374 octets in length. 376 2.5.6. Maximum Bandwidth 378 The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that 379 can be used on this link in this direction (from the system 380 originating the LSA to its neighbor), in IEEE floating point format. 381 This is the true link capacity. The units are bytes per second. 383 The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 384 length. 386 2.5.7. Maximum Reservable Bandwidth 388 The Maximum Reservable Bandwidth sub-TLV specifies the maximum 389 bandwidth that may be reserved on this link in this direction, in 390 IEEE floating point format. Note that this may be greater than the 391 maximum bandwidth (in which case the link may be oversubscribed). 392 This SHOULD be user-configurable; the default value should be the 393 Maximum Bandwidth. The units are bytes per second. 395 The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four 396 octets in length. 398 2.5.8. Unreserved Bandwidth 400 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 401 not yet reserved at each of the eight priority levels, in IEEE 402 floating point format. The values correspond to the bandwidth that 403 can be reserved with a setup priority of 0 through 7, arranged in 404 increasing order with priority 0 occurring at the start of the sub- 405 TLV, and priority 7 at the end of the sub-TLV. The initial values 406 (before any bandwidth is reserved) are all set to the Maximum 407 Reservable Bandwidth. Each value will be less than or equal to the 408 Maximum Reservable Bandwidth. The units are bytes per second. 410 The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in 411 length. 413 2.5.9. Administrative Group 415 The Administrative Group sub-TLV contains a 4-octet bit mask assigned 416 by the network administrator. Each set bit corresponds to one 417 administrative group assigned to the interface. A link may belong to 418 multiple groups. 420 By convention the least significant bit is referred to as 'group 0', 421 and the most significant bit is referred to as 'group 31'. 423 The Administrative Group is also called Resource Class/Color [2]. 425 The Administrative Group sub-TLV is TLV type 9, and is four octets in 426 length. 428 3. Elements of Procedure 430 Routers shall originate Traffic Engineering LSAs whenever the LSA 431 contents change, and whenever otherwise required by OSPF (an LSA 432 refresh, for example). Note that this does not mean that every 433 change must be flooded immediately; an implementation MAY set 434 thresholds (for example, a bandwidth change threshold) that trigger 435 immediate flooding, and initiate flooding of other changes after a 436 short time interval. In any case, the origination of Traffic 437 Engineering LSAs SHOULD be rate-limited to at most one every 438 MinLSInterval [1]. 440 Upon receipt of a changed Traffic Engineering LSA or Network LSA 441 (since these are used in traffic engineering calculations), the 442 router should update its traffic engineering database. No SPF or 443 other route calculations are necessary. 445 4. Compatibility Issues 447 There should be no interoperability issues with routers that do not 448 implement these extensions, as the Opaque LSAs will be silently 449 ignored. 451 The result of having routers that do not implement these extensions 452 is that the traffic engineering topology will be missing pieces; 453 however, if the topology is connected, TE paths can still be 454 calculated and ought to work. 456 5. Normative References 458 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 460 [4] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of 461 Generalized MPLS," work in progress. 463 [6] Kompella, K., and Y. Rekhter, "Signalling Unnumbered Links in 464 RSVP-TE," work in progress. 466 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 467 Levels", BCP 14, RFC 2119, March 1997. 469 [8] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. 471 [9] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", 472 Standard 754-1985, 1985 (ISBN 1-5593-7653-8). 474 6. Informative References 476 [2] Awduche, D., et al, "Requirements for Traffic Engineering Over 477 MPLS," RFC 2702, September 1999. 479 [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," 480 work in progress. 482 [5] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling 483 Unnumbered Links in CR-LDP," work in progress. 485 [10] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA 486 Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. 488 [11] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital 489 Signatures", RFC 2154, June 1997. 491 7. Security Considerations 493 This document specifies the contents of Opaque LSAs in OSPFv2. As 494 Opaque LSAs are not used for SPF computation or normal routing, the 495 extensions specified here have no affect on IP routing. Tampering 496 with TE LSAs may have an effect on traffic engineering computations, 497 however, and it is suggested that whatever mechanisms are used for 498 securing the transmission of normal OSPF LSAs be applied equally to 499 all Opaque LSAs, including the TE LSAs specified here. 501 Note that the mechanisms in [1] and [11] apply to Opaque LSAs. It is 502 suggested that future mechanisms proposed to secure/authenticate 503 OSPFv2 LSA exchanges be made general enough to be used with Opaque 504 LSAs. 506 8. IANA Considerations 508 The top level Types in a TE LSA as well as Types for sub-TLVs in a TE 509 Link TLV are to be registered with IANA. 511 Following the guidelines set in [10], top level Types in TE LSAs from 512 3 through 32767 are to be assigned by Expert Review (the said Expert 513 to be decided by the IESG). Types from 32768 through 65535 are 514 reserved for Private Use. In all cases, assigned values Types MUST 515 be registered with IANA. 517 Also, sub-Types of a TE Link TLV from 10 to 32767 are to be assigned 518 by Expert Review; values from 32768 through 32772 are reserved for 519 Private Use; and values from 32773 through 65535 are to be assigned 520 First Come First Served. In all cases, assigned values are to be 521 registered with IANA. 523 9. Authors' Addresses 525 Dave Katz 526 Juniper Networks 527 1194 N. Mathilda Ave. 528 Sunnyvale, CA 94089 USA 530 Phone: +1 408 745 2000 531 Email: dkatz@juniper.net 533 Derek M. Yeung 534 Procket Networks, Inc. 535 1100 Cadillac Court 536 Milpitas, CA 95035 USA 538 Phone: +1 408 635-7900 539 Email: myeung@procket.com 541 Kireeti Kompella 542 Juniper Networks 543 1194 N. Mathilda Ave. 544 Sunnyvale, CA 94089 USA 546 Phone: +1 408 745 2000 547 Email: kireeti@juniper.net 549 10. IPR Notices 551 The IETF takes no position regarding the validity or scope of any 552 intellectual property or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; neither does it represent that it 556 has made any effort to identify any such rights. Information on the 557 IETF's procedures with respect to rights in standards-track and 558 standards-related documentation can be found in BCP-11. Copies of 559 claims of rights made available for publication and any assurances of 560 licenses to be made available, or the result of an attempt made to 561 obtain a general license or permission for the use of such 562 proprietary rights by implementors or users of this specification can 563 be obtained from the IETF Secretariat. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights which may cover technology that may be required to practice 568 this standard. Please address the information to the IETF Executive 569 Director. 571 11. Full Copyright Notice 573 Copyright (C) The Internet Society (2002). All Rights Reserved. 575 This document and translations of it may be copied and furnished to 576 others, and derivative works that comment on or otherwise explain it 577 or assist in its implmentation may be prepared, copied, published and 578 distributed, in whole or in part, without restriction of any kind, 579 provided that the above copyright notice and this paragraph are 580 included on all such copies and derivative works. However, this 581 document itself may not be modified in any way, such as by removing 582 the copyright notice or references to the Internet Society or other 583 Internet organizations, except as needed for the purpose of 584 developing Internet standards in which case the procedures for 585 copyrights defined in the Internet Standards process must be 586 followed, or as required to translate it into languages other than 587 English. 589 The limited permissions granted above are perpetual and will not be 590 revoked by the Internet Society or its successors or assigns. 592 This document and the information contained herein is provided on an 593 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 594 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 595 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 596 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 597 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.