idnits 2.17.1 draft-ietf-ippm-bw-capacity-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 592. 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 (May 30, 2007) is 6147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3184 (Obsoleted by RFC 7154) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Informational NASA Glenn Research Center 6 Expires: December 1, 2007 May 30, 2007 8 Defining Network Capacity 9 draft-ietf-ippm-bw-capacity-05 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 December 1, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.1. Links and Paths . . . . . . . . . . . . . . . . . . . . . 6 58 2.2. Definition: Nominal Physical Link Capacity . . . . . . . . 6 59 2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 6 60 2.3.1. Definition: IP Layer Bits . . . . . . . . . . . . . . 7 61 2.3.1.1. Standard or Correctly Formed Packets . . . . . . . 7 62 2.3.1.2. Type P Packets . . . . . . . . . . . . . . . . . . 8 63 2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 8 64 2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 9 65 2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 9 66 2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 9 67 2.3.6. Definition: IP-type-P Available Link Capacity . . . . 9 68 2.3.7. Definition: IP-type-P Available Path Capacity . . . . 10 70 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 11 72 3.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 11 73 3.3. Other Potential Factors . . . . . . . . . . . . . . . . . 11 74 3.4. Common Literature Terminology . . . . . . . . . . . . . . 12 75 3.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 12 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Intellectual Property and Copyright Statements . . . . . . . . . . 20 92 1. Introduction 94 Measuring the capacity of a link or network path is a task that 95 sounds simple, but in reality can be quite complex. Any physical 96 medium requires that information be encoded and, depending on the 97 medium, there are various schemes to convert information into a 98 sequence of signals that are transmitted physically from one location 99 to another. 101 While on some media, the maximum frequency of these signals can be 102 thought of as "capacity", on other media, the signal transmission 103 frequency and the information capacity of the medium (channel) may be 104 quite different. For example, a satellite channel may have a carrier 105 frequency of a few gigahertz, but an information-carrying capacity of 106 only a few hundred kilobits per second. Often similar or identical 107 terms are used to refer to these different applications of capacity, 108 adding to the ambiguity and confusion, and the lack of a unified 109 nomenclature makes it difficult to properly build, test, and use 110 various techniques and tools. 112 We are interested in information-carrying capacity, but even this is 113 not straightforward. Each of the layers, depending on the medium, 114 adds overhead to the task of carrying information. The wired 115 Ethernet uses Manchester coding or 4/5 coding which cuts down 116 considerably on the "theoretical" capacity. Similarly RF (radio 117 frequency) communications will often add redundancy to the coding 118 scheme to implement forward error correction because the physical 119 medium (air) is lossy. This can further decrease the information 120 capacity. 122 In addition to coding schemes, usually the physical layer and the 123 link layer add framing bits for multiplexing and control purposes. 124 For example, on SONET there is physical layer framing and typically 125 also some layer 2 framing such as HDLC, PPP or ATM. 127 Aside from questions of coding efficiency, there are issues of how 128 access to the channel is controlled which also may affect the 129 capacity. For example, a multiple-access medium with collision 130 detection, avoidance and recovery mechanisms has a varying capacity 131 from the point of view of the users. This varying capacity depends 132 upon the total number of users contending for the medium, how busy 133 the users are, and bounds resulting from the mechanisms themselves. 134 RF channels are also varying capacity, depending on range, 135 environmental conditions, mobility and shadowing, etc. 137 The important points to derive from this discussion are these: First, 138 capacity is only meaningful when defined relative to a given protocol 139 layer in the network. It is meaningless to speak of "link" capacity 140 without qualifying exactly what is meant. Second, capacity is not 141 necessarily fixed, and consequently, a single measure of capacity at 142 whatever layer may in fact provide a skewed picture (either 143 optimistic or pessimistic) of what is actually available. 145 2. Definitions 147 In this section, we specify definitions for capacity. We begin by 148 first defining "link" and "path" clearly and then we define a 149 baseline capacity that is simply tied to the physical properties of 150 the link. 152 2.1. Links and Paths 154 To define capacity, we need to broaden the notions of link and path 155 found in the IPPM framework document [RFC2330] to include network 156 devices that can impact IP capacity without being IP aware. For 157 example, consider an Ethernet switch that can operate ports at 158 different speeds. 160 We define nodes as hosts, routers, Ethernet switches, or any other 161 device where the input and output links can have different 162 characteristics. A link is a connection between two of these network 163 devices or nodes. We then define a path P of length n as a series of 164 links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., 165 Nn+1). A source, S, and destination, D, reside at N1 and Nn+1 166 respectively. Furthermore, we define a link L as a special case 167 where the path length is one. 169 2.2. Definition: Nominal Physical Link Capacity 171 Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum 172 amount of data that the link L can support. For example, an OC-3 173 link would be capable of 155.520 Mbps. We stress that this is a 174 measurement at the physical layer and not the network IP layer, which 175 we will define separately. While NomCap(L) is typically constant 176 over time, there are links whose characteristics may allow otherwise, 177 such as the dynamic activation of additional transponders for a 178 satellite link. 180 The nominal physical link capacity is provided as a means to help 181 distinguish between the commonly used link layer capacities and the 182 remaining definitions for IP layer capacity. As a result, the value 183 of NomCap(L) does not influence the other definitions presented in 184 this document. Instead, it provides an upper bound on those values. 186 2.3. Capacity at the IP Layer 188 There are many factors that can reduce the IP information carrying 189 capacity of the link, some of which have already been discussed in 190 the introduction. However, the goal of this document is not to 191 become an exhaustive list of such factors. Rather, we outline some 192 of the major examples in the following section, thus providing food 193 for thought to those implementing the algorithms or tools that 194 attempt to measure capacity accurately. 196 The remaining definitions are all given in terms of "IP layer bits" 197 in order to distinguish these definitions from the nominal physical 198 capacity of the link. 200 2.3.1. Definition: IP Layer Bits 202 IP layer bits are defined as eight (8) times the number of octets in 203 all IP packets received, from the first octet of the IP header to the 204 last octet of the IP packet payload, inclusive. 206 IP layer bits are recorded at the destination, D, beginning at time T 207 and ending at a time T+I. Since the definitions are based on 208 averages, the two time parameters, T and I, must accompany any report 209 or estimate of the following values in order for them to remain 210 meaningful. It is not required that the interval boundary points 211 fall between packet arrivals at D. However, boundaries that fall 212 within a packet will invalidate the packets on which they fall. 213 Specifically, the data from the partial packet that is contained 214 within the interval will not be counted. This may artificially bias 215 some of the values, depending on the length of the interval and the 216 amount of data received during that interval. We elaborate on what 217 constitutes correctly received data in the next section. 219 2.3.1.1. Standard or Correctly Formed Packets 221 The definitions in this document specify that IP packets must be 222 received correctly. The IPPM framework recommends a set of criteria 223 for such standard-formed packet in section 15 of [RFC2330]. However, 224 it is inadequate for use with this document. Thus, we outline our 225 own criteria below while pointing out any variations or similarities 226 to [RFC2330]. 228 First, data that is in error at layers below IP and cannot be 229 properly passed to the IP layer must not be counted. For example, 230 wireless media often has a considerably larger error rate than wired 231 media, resulting in a reduction in IP Link Capacity. In accordance 232 with the IPPM framework, packets that fail validation of the IP 233 header must be discarded. Specifically, the requirements in 234 [RFC1812] section 5.2.2 on IP header validation must be checked, 235 which includes a valid length, checksum, and version field. 237 The IPPM framework specifies further restrictions, requiring that any 238 transport header be checked for correctness and that any packets with 239 IP options be ignored. However, the definitions in this document are 240 concerned with the traversal of IP layer bits. As a result, data 241 from the higher layers is not required to be valid or understood as 242 they are simply regarded as part of the IP packet. The same holds 243 true for IP options. Valid IP fragments must also be counted as they 244 expend the resources of a link even though assembly of the full 245 packet may not be possible. The IPPM framework differs in this area, 246 discarding IP fragments. 248 For a discussion of duplicates, please see Section 3.2. 250 In summary, any IP packet that can be properly processed must be 251 included in these calculations. 253 2.3.1.2. Type P Packets 255 The definitions in this document refer to "Type P" packets to 256 designate a particular type of flow or sets of flows. As defined in 257 RFC 2330, Section 13, "Type P" is a placeholder for what may be an 258 explicit specification of the packet flows referenced by the metric, 259 or it may be a very loose specification encompassing aggregates. We 260 use the "Type P" designation in these definitions in order to 261 emphasize two things: First, that the value of the capacity 262 measurement depends on the types of flows referenced in the 263 definition. This is because networks may treat packets differently 264 (in terms of queuing and scheduling) based on their markings and 265 classification. Networks may also arbitrarily decide to flow balance 266 based on the packet type or flow type and thereby affect capacity 267 measurements. Second, the measurement of capacity depends not only 268 on the type of the reference packets, but also on the types of the 269 packets in the "population" with which the flows of interest share 270 the links in the path. 272 All of this indicates two different approaches to measuring: One is 273 to measure capacity using a broad spectrum of packet types, 274 suggesting that "Type P" should be set as generic as possible. The 275 second is to focus narrowly on the types of flows of particular 276 interest, which suggests that "Type P" should be very specific and 277 narrowly defined. The first approach is likely to be of interest to 278 providers, the second to application users. 280 2.3.2. Definition: IP-type-P Link Capacity 282 We define the IP layer link capacity, C(L,T,I), to be the maximum 283 number of IP layer bits that can be transmitted from the source S and 284 correctly received by the destination D over the link L during the 285 interval [T, T+I], divided by I. 287 2.3.3. Definition: IP-type-P Path Capacity 289 Using our definition for link capacity, we can then extend this 290 notion to an entire path, such that the IP layer path capacity simply 291 becomes that of the link with the smallest capacity along that path. 293 C(P,T,I) = min {1..n} {C(Ln,T,I)} 295 The previous definitions specify the number of IP layer bits that can 296 be transmitted across a link or path should the resource be free of 297 any congestion. It represents the full capacity available for 298 traffic between the source and destination. Determining how much 299 capacity is available for use on a congested link is potentially much 300 more useful. However, in order to define the available capacity we 301 must first specify how much is being used. 303 2.3.4. Definition: IP-type-P Link Usage 305 The average usage of a link L, Used(L,T,I), is the actual number of 306 IP layer bits from any source, correctly received over link L during 307 the interval [T, T+I], divided by I. 309 An important distinction between usage and capacity is that 310 Used(L,T,I) is not the maximum number, but rather, the actual number 311 of IP bits sent that are correctly received. The information 312 transmitted across the link can be generated by any source, including 313 those who may not be directly attached to either side of the link. 314 In addition, each information flow from these sources may share any 315 number (from one to n) of links in the overall path between S and D. 317 2.3.5. Definition: IP-type-P Link Utilization 319 We express usage as a fraction of the overall IP layer link capacity. 321 Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ) 323 Thus, the utilization now represents the fraction of the capacity 324 that is being used and is a value between zero, meaning nothing is 325 used, and one, meaning the link is fully saturated. Multiplying the 326 utilization by 100 yields the percent utilization of the link. By 327 using the above, we can now define the capacity available over the 328 link as well as the path between S and D. Note that this is 329 essentially the definition in [PDM]. 331 2.3.6. Definition: IP-type-P Available Link Capacity 333 We can now determine the amount of available capacity on a congested 334 link by multiplying the IP layer link capacity with the complement of 335 the IP layer link utilization. Thus, the IP layer available link 336 capacity becomes: 338 AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) 340 2.3.7. Definition: IP-type-P Available Path Capacity 342 Using our definition for IP layer available link capacity, we can 343 then extend this notion to an entire path, such that the IP layer 344 available path capacity simply becomes that of the link with the 345 smallest available capacity along that path. 347 AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)} 349 Since measurements of available capacity are more volatile than that 350 of capacity, we stress the importance that both the time and interval 351 be specified as their values have a great deal of influence on the 352 results. In addition, a sequence of measurements may be beneficial 353 in offsetting the volatility when attempting to characterize 354 available capacity. 356 3. Discussion 358 3.1. Time and Sampling 360 We must emphasize the importance of time in the basic definitions of 361 these quantities. We know that traffic on the Internet is highly 362 variable across all time scales. This argues that the time and 363 length of measurements are critical variables in reporting available 364 capacity measurements and must be reported when using these 365 definitions. 367 The closer to "instantaneous" a metric is, the more important it is 368 to have a plan for sampling the metric over a time period that is 369 sufficiently large. By doing so, we allow valid statistical 370 inferences to be made from the measurements. An obvious pitfall here 371 is sampling in a way that causes bias. For example, a situation 372 where the sampling frequency is a multiple of the frequency of an 373 underlying condition. 375 3.2. Hardware Duplicates 377 We briefly consider the impacts of paths where hardware duplication 378 of packets may occur. In such an environment, a node in the network 379 path may duplicate packets and the destination may receive multiple, 380 identical copies of these packets. Both the original packet and the 381 duplicates can be properly received and appear to be originating from 382 the sender. Thus, in the most generic form, duplicate IP packets are 383 counted in these definitions. However, hardware duplication can 384 impact these definitions depending on the use of "Type P" to add 385 additional restrictions on packet reception. For instance, a 386 restriction to only count uniquely sent packets may be more useful to 387 users concerned with capacity for meaningful data. In contrast, the 388 more general, unrestricted metric may be suitable for a user who is 389 concerned with raw capacity. Thus, it is up to the user to properly 390 scope and interpret results in situations where hardware duplicates 391 may be prevalent. 393 3.3. Other Potential Factors 395 IP encapsulation does not impact the definitions as all IP header and 396 payload bits must be counted regardless of content. However, 397 different sized IP packets can lead to a variation in the amount of 398 overhead needed at the lower layers to transmit the data, thus 399 altering the overall IP link layer capacity. 401 Should the link happen to employ a compression scheme such as ROHC 402 [RFC3095] or V.44 [V44], some of the original bits are not 403 transmitted across the link. However, the inflated (not compressed) 404 number of IP-layer bits should be counted. 406 3.4. Common Literature Terminology 408 Certain terms are often used to characterize specific aspects of the 409 presented definitions. The link with the smallest capacity is 410 commonly referred to as the "narrow link" of a path. Also, the link 411 with the smallest available capacity is often referred to as the 412 "tight link" within a path. So, while Ln may have a very large 413 capacity, the overall congestion level on the link makes it the 414 likely bottleneck of a connection. Conversely, a link that has the 415 smallest capacity may not be a bottleneck should it be lightly loaded 416 in relation to the rest of the path. 418 Also, common literature often overloads the term "bandwidth" to refer 419 to what we have described as capacity in this document. For example, 420 when inquiring about the bandwidth of a 802.11b link, a network 421 engineer will likely answer with 11 Mbps. However, an electrical 422 engineer may answer with 25 MHz, and an end user may tell you that 423 his observed bandwidth is 8 Mbps. In contrast, the term capacity is 424 not quite as overloaded and is an appropriate term that better 425 reflects what is actually being measured. 427 3.5. Comparison to Bulk Transfer Capacity (BTC) 429 Bulk Transfer Capacity (BTC) [RFC3184] provides a distinct 430 perspective on path capacity that differs from the definitions in 431 this document in several fundamental ways. First, BTC operates at 432 the transport layer, gauging the amount of capacity available to an 433 application that wishes to send data. Only unique data is measured, 434 meaning header and retransmitted data are not included in the 435 calculation. In contrast, IP layer link capacity includes the IP 436 header and is indifferent to the uniqueness of the data contained 437 within the packet payload (Hardware duplication of packets is an 438 anomaly addressed in the previous section). Second, BTC utilizes a 439 single congestion aware transport connection, such as TCP, to obtain 440 measurements. As a result, BTC implementations react strongly to 441 different path characteristics, topologies, and distances. Since 442 these differences can affect the control loop (propagation delays, 443 segment reordering, etc), the reaction is further dependent on the 444 algorithms being employed for the measurements. For example, 445 consider a single event where a link suffers a large duration of bit 446 errors. The event could cause IP layer packets to be discarded, and 447 the lost packets would reduce the IP layer link capacity. However, 448 the same event and subsequent losses would trigger loss recovery for 449 a BTC measurement resulting in the retransmission of data and a 450 potentially reduced sending rate. Thus, a measurement of BTC does 451 not correspond to any of the definitions in this document. Both 452 techniques are useful in exploring the characteristics of a network 453 path, but from different perspectives. 455 4. IANA Considerations 457 This document makes no request of IANA. 459 Note to RFC Editor: this section may be removed on publication as an 460 RFC. 462 5. Security Considerations 464 This document specifies definitions regarding IP traffic traveling 465 between a source and destination in an IP network. These definitions 466 do not raise any security issues and do not have a direct impact on 467 the networking protocol suite. 469 Tools that attempt to implement these definitions may introduce 470 security issues specific to each implementation. Both active and 471 passive measurement techniques can be abused, impacting the security, 472 privacy, and performance of the network. Any measurement techniques 473 based upon these definitions must include a discussion of the 474 techniques needed to protect the network on which the measurements 475 are being performed. 477 6. Conclusion 479 In this document, we have defined a set of quantities related to the 480 capacity of links and paths in an IP network. In these definitions, 481 we have tried to be as clear as possible and take into account 482 various characteristics that links and paths can have. The goal of 483 these definitions is to enable researchers who propose capacity 484 metrics to relate those metrics to these definitions and to evaluate 485 those metrics with respect to how well they approximate these 486 quantities. 488 In addition, we have pointed out some key auxiliary parameters and 489 opened a discussion of issues related to valid inferences from 490 available capacity metrics. 492 7. Acknowledgments 494 The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt 495 Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their 496 suggestions, comments, and reviews. We also thank members of the 497 IETF IPPM Mailing List for their discussions and feedback on this 498 document. 500 8. References 502 8.1. Normative References 504 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 505 RFC 1812, June 1995. 507 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 508 "Framework for IP Performance Metrics", RFC 2330, 509 May 1998. 511 8.2. Informative References 513 [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet 514 Dispersion Techniques and a Capacity Estimation 515 Methodology", IEEE/ACM Transactions on Networking 12(6): 516 963-977, December 2004. 518 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 519 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 520 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 521 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 522 Compression (ROHC): Framework and four profiles: RTP, UDP, 523 ESP, and uncompressed", RFC 3095, July 2001. 525 [RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, 526 RFC 3184, October 2001. 528 [V44] ITU Telecommunication Standardization Sector (ITU-T) 529 Recommendation V.44, "Data Compression Procedures", 530 November 2000. 532 Authors' Addresses 534 Phil Chimento 535 JHU Applied Physics Lab 536 11100 Johns Hopkins Road 537 Laurel, Maryland 20723-6099 538 USA 540 Phone: +1-240-228-1743 541 Fax: +1-240-228-0789 542 Email: Philip.Chimento@jhuapl.edu 544 Joseph Ishac 545 NASA Glenn Research Center 546 21000 Brookpark Road 547 Cleveland, Ohio 44135 548 USA 550 Phone: +1-216-433-6587 551 Fax: +1-216-433-8705 552 Email: jishac@grc.nasa.gov 554 Full Copyright Statement 556 Copyright (C) The IETF Trust (2007). 558 This document is subject to the rights, licenses and restrictions 559 contained in BCP 78, and except as set forth therein, the authors 560 retain all their rights. 562 This document and the information contained herein are provided on an 563 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 564 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 565 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 566 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 567 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 Intellectual Property 572 The IETF takes no position regarding the validity or scope of any 573 Intellectual Property Rights or other rights that might be claimed to 574 pertain to the implementation or use of the technology described in 575 this document or the extent to which any license under such rights 576 might or might not be available; nor does it represent that it has 577 made any independent effort to identify any such rights. Information 578 on the procedures with respect to rights in RFC documents can be 579 found in BCP 78 and BCP 79. 581 Copies of IPR disclosures made to the IETF Secretariat and any 582 assurances of licenses to be made available, or the result of an 583 attempt made to obtain a general license or permission for the use of 584 such proprietary rights by implementers or users of this 585 specification can be obtained from the IETF on-line IPR repository at 586 http://www.ietf.org/ipr. 588 The IETF invites any interested party to bring to its attention any 589 copyrights, patents or patent applications, or other proprietary 590 rights that may cover technology that may be required to implement 591 this standard. Please address the information to the IETF at 592 ietf-ipr@ietf.org. 594 Acknowledgment 596 Funding for the RFC Editor function is provided by the IETF 597 Administrative Support Activity (IASA).