idnits 2.17.1 draft-ietf-ippm-bw-capacity-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 554. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 RFC 3978 Section 5.4 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 29, 2006) is 6351 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 informational reference (is this intentional?): RFC 3184 (Obsoleted by RFC 7154) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Metrics Working P. Chimento 3 Group JHU Applied Physics Lab 4 Internet-Draft J. Ishac 5 Expires: June 2, 2007 NASA Glenn Research Center 6 November 29, 2006 8 Defining Network Capacity 9 draft-ietf-ippm-bw-capacity-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on June 2, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Measuring capacity is a task that sounds simple, but in reality can 43 be quite complex. In addition, the lack of a unified nomenclature on 44 this subject makes it increasingly difficult to properly build, test, 45 and use techniques and tools built around these constructs. This 46 document provides definitions for the terms 'Capacity' and 'Available 47 Capacity' related to IP traffic traveling between a source and 48 destination in an IP network. By doing so, we hope to provide a 49 common framework for the discussion and analysis of a diverse set of 50 current and future estimation techniques. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1 Links and Paths . . . . . . . . . . . . . . . . . . . . . 5 58 2.2 Definition: Nominal Physical Link Capacity . . . . . . . . 5 59 2.3 Capacity at the IP Layer . . . . . . . . . . . . . . . . . 5 60 2.3.1 Definition: IP Layer Bits . . . . . . . . . . . . . . 6 61 2.3.1.1 Standard or Correctly Formed Packets . . . . . . . 6 62 2.3.2 Definition: IP Layer Link Capacity . . . . . . . . . . 7 63 2.3.3 Definition: IP Layer Path Capacity . . . . . . . . . . 7 64 2.3.4 Definition: IP Layer Link Usage . . . . . . . . . . . 7 65 2.3.5 Definition: Average IP Layer Link Utilization . . . . 8 66 2.3.6 Definition: IP Layer Available Link Capacity . . . . . 8 67 2.3.7 Definition: IP Layer Available Path Capacity . . . . . 8 69 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1 Time and Sampling . . . . . . . . . . . . . . . . . . . . 9 71 3.2 Hardware Duplicates . . . . . . . . . . . . . . . . . . . 9 72 3.3 Other Potential Factors . . . . . . . . . . . . . . . . . 9 73 3.4 Common Literature Terminology . . . . . . . . . . . . . . 10 74 3.5 Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10 75 3.6 Type P Packets . . . . . . . . . . . . . . . . . . . . . . 11 77 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 87 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 91 Intellectual Property and Copyright Statements . . . . . . . . 18 93 1. Introduction 95 Measuring the capacity of a link or network path is a task that 96 sounds simple, but in reality can be quite complex. Any physical 97 medium requires that information be encoded and, depending on the 98 medium, there are various schemes to convert information into a 99 sequence of signals that are transmitted physically from one location 100 to another. 102 While on some media, the maximum frequency of these signals can be 103 thought of as "capacity", on other media, the signal transmission 104 frequency and the information capacity of the medium (channel) may be 105 quite different. For example, a satellite channel may have a carrier 106 frequency of a few gigahertz, but an information-carrying capacity of 107 only a few hundred kilobits per second. Often similar or identical 108 terms are used to refer to these different applications of capacity, 109 adding to the ambiguity and confusion, and the lack of a unified 110 nomenclature makes it difficult to properly build, test, and use 111 various techniques and tools. 113 We are interested in information-carrying capacity, but even this is 114 not straightforward. Each of the layers, depending on the medium, 115 adds overhead to the task of carrying information. The wired 116 Ethernet uses Manchester coding or 4/5 coding which cuts down 117 considerably on the "theoretical" capacity. Similarly RF (radio 118 frequency) communications will often add redundancy to the coding 119 scheme to implement forward error correction because the physical 120 medium (air) is lossy. This can further decrease the information 121 efficiency. 123 In addition to coding schemes, usually the physical layer and the 124 link layer add framing bits for multiplexing and control purposes. 125 For example, on SONET there is physical layer framing and typically 126 also some layer 2 framing such as HDLC, PPP or ATM. 128 Aside from questions of coding efficiency, there are issues of how 129 access to the channel is controlled which also may affect the 130 capacity. For example, a multiple-access medium with collision 131 detection, avoidance and recovery mechanisms has a varying capacity 132 from the point of view of the users. This varying capacity depends 133 upon the total number of users contending for the medium, how busy 134 the users are, and bounds resulting from the mechanisms themselves. 135 RF channels are also varying capacity, depending on range, 136 environmental conditions, mobility and shadowing, etc. 138 The important points to derive from this discussion are these: First, 139 capacity is only meaningful when defined relative to a given protocol 140 layer in the network. It is meaningless to speak of "link" capacity 141 without qualifying exactly what is meant. Second, capacity is not 142 necessarily fixed, and consequently, a single measure of capacity at 143 whatever layer may in fact provide a skewed picture (either 144 optimistic or pessimistic) of what is actually available. 146 2. Definitions 148 In this section, we specify definitions for capacity. We begin by 149 first defining "link" and "path" clearly and then we define a 150 baseline capacity that is simply tied to the physical properties of 151 the link. 153 2.1 Links and Paths 155 To define capacity, we need to broaden the notions of link and path 156 found in the IPPM framework document [RFC2330] to include network 157 devices that can impact IP capacity without being IP aware. In 158 example, consider an Ethernet switch that can operate ports at 159 different speeds. 161 We define nodes as hosts, routers, Ethernet switches, or any other 162 device where the input and output links have different 163 characteristics. A link is a connection between two of these network 164 devices or nodes. We then define a path P of length n as a series of 165 links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., 166 Nn+1). A source, S, and destination, D, reside at N1 and Nn+1 167 respectively. Furthermore, we define a link L as a special case 168 where the path size is one. 170 2.2 Definition: Nominal Physical Link Capacity 172 Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum 173 amount of data that the link L can support. For example, an OC-3 174 link would be capable of 155.520 Mbps. We stress that this is a 175 measurement at the physical layer and not the network IP layer, which 176 we will define separately. While NomCap(L) is typically constant 177 over time, there are links whose characteristics may allow otherwise, 178 such as the dynamic activation of additional transponders for a 179 satellite link. 181 The nominal physical link capacity is provided as a means to help 182 distinguish between the commonly used link layer capacities and the 183 remaining definitions for IP layer capacity. As a result, the value 184 of NomCap(L) does not influence the other definitions presented in 185 this document. 187 2.3 Capacity at the IP Layer 189 There are many factors that can reduce the IP information carrying 190 capacity of the link, some of which have already been discussed in 191 the introduction. However, the goal of this document is not to 192 become an exhaustive list of such factors. Rather, we outline some 193 of the major examples in the following section, thus providing food 194 for thought to those implementing the algorithms or tools that 195 attempt to measure capacity accurately. 197 The remaining definitions are all given in terms of "IP layer bits" 198 in order to distinguish these definitions from the nominal physical 199 capacity of the link. 201 2.3.1 Definition: IP Layer Bits 203 IP layer bits are defined as eight (8) times the number of octets in 204 all IP packets received, from the first octet of the IP header to the 205 last octet of the IP packet payload, inclusive. 207 IP layer bits are recorded at the destination, D, beginning at time T 208 and ending at a time T+I. Since the definitions are based on 209 averages, the two time parameters, T and I, must accompany any report 210 or estimate of the following values in order for them to remain 211 meaningful. It is not required that the interval boundary points 212 fall between packet arrivals at D. However, boundaries that fall 213 within a packet will invalidate the packets on which they fall. 214 Specifically, the data from the partial packet that is contained 215 within the interval will not be counted. This may artificially bias 216 some of the values, depending on the length of the interval and the 217 amount of data received during that interval. We elaborate on what 218 constitutes correctly received data in the next section. 220 2.3.1.1 Standard or Correctly Formed Packets 222 The definitions in this document specify that IP packets must be 223 received correctly. The IPPM framework recommends a set of criteria 224 for such standard-formed packet in section 15 of [RFC2330]. However, 225 it is inadequate for use with this document. Thus, we outline our 226 own criteria below while pointing out any variations or similarities 227 to [RFC2330]. 229 First, data that is in error at layers below IP and cannot be 230 properly passed to the IP layer should not be counted. For example, 231 wireless media often has a considerably larger error rate than wired 232 media, resulting in a reduction in IP Link Capacity. In accordance 233 with the framework, packets that fail validation of the IP header 234 should be discarded. Specifically, the requirements in [RFC1812] 235 section 5.2.2 on IP header validation should be checked, which 236 includes a valid length, checksum, and version field. 238 The framework specifies further restrictions, requiring that any 239 transport header be checked for correctness and that any packets with 240 IP options be ignored. However, the definitions in this document are 241 concerned with the traversal of IP layer bits. As a result, data 242 from the higher layers is not required to be valid or understood as 243 they are simply regarded as part of the IP packet. The same holds 244 true for IP options. Valid IP fragments should also be counted as 245 they expend the resources of a link even though assembly of the full 246 packet may not be possible. The framework differs in this area, 247 discarding IP fragments. 249 In summary, any IP packet that can be properly processed should be 250 included in these calculations. 252 2.3.2 Definition: IP Layer Link Capacity 254 We define the IP layer link capacity, C(L,T,I), to be the maximum 255 number of IP layer bits that can be transmitted from the source S and 256 correctly received by the destination D over the link L during the 257 interval [T, T+I], divided by I. 259 Using this, we can then extend this notion to an entire path, such 260 that the IP layer path capacity simply becomes that of the link with 261 the smallest capacity along that path. 263 2.3.3 Definition: IP Layer Path Capacity 265 C(P,T,I) = min {1..n} {C(Ln,T,I)} 267 The previous definitions specify a link's capacity, namely the IP 268 layer bits that can be transmitted across a link or path should the 269 resource be free of any congestion. Determining how much capacity is 270 available for use on a congested link is potentially much more 271 useful. However, in order to define the available capacity we must 272 first specify how much is being used. 274 2.3.4 Definition: IP Layer Link Usage 276 The average usage of a link L, Used(L,T,I), is the actual number of 277 IP layer bits from any source, correctly received over link L during 278 the interval [T, T+I], divided by I. 280 An important distinction between usage and capacity is that 281 Used(L,T,I) is not the maximum number, but rather, the actual number 282 of IP bits sent that are correctly received. The information 283 transmitted across the link can be generated by any source, including 284 those who may not be directly attached to either side of the link. 285 In addition, each information flow from these sources may share any 286 number (from one to n) of links in the overall path between S and D. 287 Next, we express usage as a fraction of the overall IP layer link 288 capacity. 290 2.3.5 Definition: Average IP Layer Link Utilization 292 Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ) 294 Thus, the utilization now represents the fraction of the capacity 295 that is being used and is a value between zero, meaning nothing is 296 used, and one, meaning the link is fully saturated. Multiplying the 297 utilization by 100 yields the percent utilization of the link. By 298 using the above, we can now define the capacity available over the 299 link as well as the path between S and D. Note that this is 300 essentially the definition in [PDM]. 302 2.3.6 Definition: IP Layer Available Link Capacity 304 AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) 306 2.3.7 Definition: IP Layer Available Path Capacity 308 AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)} 310 Since measurements of available capacity are more volatile than that 311 of capacity, it is important that both the time and interval be 312 specified as their values have a great deal of influence on the 313 results. In addition, a sequence of measurements may be beneficial 314 in offsetting the volatility when attempting to characterize 315 available capacity. 317 3. Discussion 319 3.1 Time and Sampling 321 We must emphasize the importance of time in the basic definitions of 322 these quantities. We know that traffic on the Internet is highly 323 variable across all time scales. This argues that the time and 324 length of measurements are critical variables in reporting available 325 capacity measurements and must be reported when using these 326 definitions. 328 The closer to "instantaneous" a metric is, the more important it is 329 to have a plan for sampling the metric over a time period that is 330 sufficiently large. By doing so, we allow valid statistical 331 inferences to be made from the measurements. An obvious pitfall here 332 is sampling in a way that causes bias. For example, a situation 333 where the sampling frequency is a multiple of the frequency of an 334 underlying condition. 336 3.2 Hardware Duplicates 338 The base definitions make no mention of hardware duplication of 339 packets. While hardware duplication has no impact on the nominal 340 capacity, it can impact the IP link layer capacity. For example, 341 consider a link which can normally carry a capacity of 2X on average. 342 However, the link has developed a syndrome where it duplicates every 343 incoming packet. The link would still technically carry a capacity 344 of 2X, however the link has a effective capacity of X or lower, 345 depending on framing overhead to send the duplicates, etc. Since the 346 definitions specify bits sent and correctly received, duplicates are 347 not counted in the usage and capacity definitions. Thus, a value for 348 C(L,T,I) and AvailCap(L,T,I) will reflect the duplication with the 349 lower value. 351 3.3 Other Potential Factors 353 IP encapsulation does not impact the definitions as all IP header and 354 payload bits should be counted regardless of content. However, 355 different sized IP packets can lead to a variation in the amount of 356 overhead needed at the lower layers to transmit the data, thus 357 altering the overall IP link layer capacity. 359 Should the link happen to employ a compression scheme such as ROHC 360 [RFC3095] or V.44 [V44], some of the original bits are not 361 transmitted across the link. However, the inflated (not compressed) 362 number of IP-layer bits should be counted. 364 3.4 Common Literature Terminology 366 Certain terms are often used to characterize specific aspects of the 367 presented definitions. The link with the smallest capacity is 368 commonly referred to as the "narrow link" of a path. Also, the value 369 of n that satisfies AvailCap(P,T,I), is often referred to as the 370 "tight link" within a path. So, while Ln may have a very large 371 capacity, the overall congestion level on the link makes it the 372 likely bottleneck of a connection. Conversely, a link that has the 373 smallest capacity may not be a bottleneck should it be lightly loaded 374 in relation to the rest of the path. 376 Also, common literature often overloads the term "bandwidth" to refer 377 to what we have described as capacity in this document. For example, 378 when inquiring about the bandwidth of a 802.11b link, a network 379 engineer will likely answer with 11 Mbps. However, an electrical 380 engineer may answer with 25 MHz, and an end user may tell you that 381 his observed bandwidth is 8 Mbps. In contrast, the term capacity is 382 not quite as overloaded and is an appropriate term that better 383 reflects what is actually being measured. 385 3.5 Comparison to Bulk Transfer Capacity (BTC) 387 Bulk Transfer Capacity (BTC) [RFC3184] provides a distinct 388 perspective on path capacity that differs from the definitions in 389 this document in several fundamental ways. First, BTC operates at 390 the transport layer, gauging the amount of capacity available to an 391 application that wishes to send data. Only unique data is measured, 392 meaning header and retransmitted data are not included in the 393 calculation. In contrast, IP layer link capacity includes the IP 394 header and is indifferent to the uniqueness of the data contained 395 within the packet payload (Hardware duplication of packets is an 396 anomaly addressed in the previous section). Second, BTC utilizes a 397 single congestion aware transport connection, such as TCP, to obtain 398 measurements. As a result, BTC implementations react strongly to 399 different path characteristics, topologies, and distances. Since 400 these differences can affect the control loop (propagation delays, 401 segment reordering, etc), the reaction is further dependent on the 402 algorithms being employed for the measurements. For example, 403 consider a single event where a link suffers a large duration of bit 404 errors. The event could cause IP layer packets to be discarded, and 405 the lost packets would reduce the IP layer link capacity. However, 406 the same event and subsequent losses would trigger loss recovery for 407 a BTC measurement resulting in the retransmission of data and a 408 potentially reduced sending rate. Thus, a measurement of BTC does 409 not correspond to any of the definitions in this document. Both 410 techniques are useful in exploring the characteristics of a network 411 path, but from different perspectives. 413 3.6 Type P Packets 415 Note that these definitions do not make mention of "Type P" packets, 416 while other IPPM definitions do. We could add the packet type as an 417 extra parameter. This would have the effect of defining a large 418 number of quantities, relative to the QoS policies that a given 419 network or concatenation of networks may have in effect in the path. 420 It would produce metrics such as "estimated EF IP Link/Path Capacity" 421 or "estimated EF IP Link Utilization". 423 Such metrics may indeed be useful. For example, this would yield 424 something like the sum of the capacities of all the QoS classes 425 defined along the path as the link or path capacity. The breakdown 426 then gives the user an analysis of how the link or path capacity (or 427 at least the "tight link" capacity) is allocated among classes. 429 These QoS-based capacities become difficult to measure on a path if 430 there are different capacities defined per QoS class on different 431 links in the path. Possibly the best way to approach this would be 432 to measure each link in a path individually, and then combine the 433 information from individual links. 435 4. Conclusion 437 In this document, we have defined a set of quantities related to the 438 capacity of links in an IP network. In these definitions, we have 439 tried to be as clear as possible and take into account various 440 characteristics that links can have. The goal of these definitions 441 is to enable researchers who propose capacity metrics to relate those 442 metrics to these definitions and to evaluate those metrics with 443 respect to how well they approximate these quantities. 445 In addition, we have pointed out some key auxiliary parameters and 446 opened a discussion of issues related to valid inferences from 447 available capacity metrics. 449 5. IANA Considerations 451 This document makes no request of IANA. 453 Note to RFC Editor: this section may be removed on publication as an 454 RFC. 456 6. Security Considerations 458 This document specifies definitions regarding IP traffic traveling 459 between a source and destination in an IP network. These definitions 460 do not raise any security issues and do not have a direct impact on 461 the networking protocol suite. 463 Tools that attempt to implement these definitions may introduce 464 security issues specific to each implementation. Both active and 465 passive measurement techniques can be abused, impacting the security, 466 privacy, and performance of the network. Any measurement techniques 467 based upon these definitions must include a discussion of the 468 techniques needed to protect the network on which the measurements 469 are being performed. 471 7. Acknowledgments 473 The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt 474 Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their 475 suggestions, comments, and reviews. We also thank members of the 476 IETF IPPM Mailing List for their discussions and feedback on this 477 document. 479 8. References 481 8.1 Normative References 483 8.2 Informative References 485 [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet 486 Dispersion Techniques and a Capacity Estimation 487 Methodology", IEEE/ACM Transactions on Networking 12(6): 488 963-977, December 2004. 490 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 491 RFC 1812, June 1995. 493 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 494 "Framework for IP Performance Metrics", RFC 2330, 495 May 1998. 497 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 498 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 499 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 500 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 501 Compression (ROHC): Framework and four profiles: RTP, UDP, 502 ESP, and uncompressed", RFC 3095, July 2001. 504 [RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, 505 RFC 3184, October 2001. 507 [V44] ITU Telecommunication Standardization Sector (ITU-T) 508 Recommendation V.44, "Data Compression Procedures", 509 November 2000. 511 Authors' Addresses 513 Phil Chimento 514 JHU Applied Physics Lab 515 11100 Johns Hopkins Road 516 Laurel, Maryland 20723-6099 517 USA 519 Phone: +1-240-228-1743 520 Fax: +1-240-228-0789 521 Email: Philip.Chimento@jhuapl.edu 522 Joseph Ishac 523 NASA Glenn Research Center 524 21000 Brookpark Road 525 Cleveland, Ohio 44135 526 USA 528 Phone: +1-216-433-6587 529 Fax: +1-216-433-8705 530 Email: jishac@grc.nasa.gov 532 Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementers or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights that may cover technology that may be required to implement 553 this standard. Please address the information to the IETF at 554 ietf-ipr@ietf.org. 556 Disclaimer of Validity 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 561 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 562 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 563 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 566 Copyright Statement 568 Copyright (C) The Internet Society (2006). This document is subject 569 to the rights, licenses and restrictions contained in BCP 78, and 570 except as set forth therein, the authors retain all their rights. 572 Acknowledgment 574 Funding for the RFC Editor function is currently provided by the 575 Internet Society.