draft-ietf-ippm-bw-capacity-01.txt   draft-ietf-ippm-bw-capacity-02.txt 
IP Performance Metrics Working P. Chimento IP Performance Metrics Working P. Chimento
Group JHU Applied Physics Lab Group JHU Applied Physics Lab
Internet-Draft J. Ishac Internet-Draft J. Ishac
Expires: May 13, 2006 NASA Glenn Research Center Expires: November 18, 2006 NASA Glenn Research Center
November 9, 2005 May 17, 2006
Defining Network Capacity Defining Network Capacity
draft-ietf-ippm-bw-capacity-01 draft-ietf-ippm-bw-capacity-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2006. This Internet-Draft will expire on November 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Measuring capacity is a task that sounds simple, but in reality can Measuring capacity is a task that sounds simple, but in reality can
be quite complex. In addition, the lack of a unified nomenclature on be quite complex. In addition, the lack of a unified nomenclature on
this subject makes it increasingly difficult to properly build, test, this subject makes it increasingly difficult to properly build, test,
and use techniques and tools built around these constructs. This and use techniques and tools built around these constructs. This
document provides definitions for the terms 'Capacity' and 'Available document provides definitions for the terms 'Capacity' and 'Available
Capacity' related to IP traffic traveling between a source and Capacity' related to IP traffic traveling between a source and
destination in an IP network. By doing so, we hope to build a common destination in an IP network. By doing so, we hope to provide a
language that can be used when discussing and analyzing a diverse set common framework for the discussion and analysis of a diverse set of
of current and future estimation techniques. current and future estimation techniques.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Standard or Correctly Formed Packets . . . . . . . . . . . 8 3.1 Standard or Correctly Formed Packets . . . . . . . . . . . 8
3.2 Other Potential Factors . . . . . . . . . . . . . . . . . 8 3.2 Other Potential Factors . . . . . . . . . . . . . . . . . 8
3.3 Common Literature Terminology . . . . . . . . . . . . . . 9 3.3 Common Literature Terminology . . . . . . . . . . . . . . 9
3.4 Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 9 3.4 Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 9
3.5 Type P Packets . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Type P Packets . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Time and Sampling . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 Normative References . . . . . . . . . . . . . . . . . . . 14
7.2 Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17
1. Introduction 1. Introduction
Measuring the capacity of a link or network path is a task that Measuring the capacity of a link or network path is a task that
sounds simple, but in reality can be quite complex. Any physical sounds simple, but in reality can be quite complex. Any physical
medium requires that information be encoded and, depending on the medium requires that information be encoded and, depending on the
medium, there are various schemes to convert information into a medium, there are various schemes to convert information into a
sequence of signals that are transmitted physically from one location sequence of signals that are transmitted physically from one location
to another. to another.
While on some media, the maximum frequency of these signals can be While on some media, the maximum frequency of these signals can be
thought of as "capacity", on other media, the signal transmission thought of as "capacity", on other media, the signal transmission
frequency and the information capacity of the medium (channel) may be frequency and the information capacity of the medium (channel) may be
quite different. For example, a satellite channel may have a carrier quite different. For example, a satellite channel may have a carrier
frequency of a few gigahertz, but an information-carrying capacity of frequency of a few gigahertz, but an information-carrying capacity of
only a few hundred kilobits per second. Often similar or identical only a few hundred kilobits per second. Often similar or identical
terms are used to refer to these different applications adding to the terms are used to refer to these different applications of capacity,
ambiguity and confusion, and the lack of a unified nomenclature makes adding to the ambiguity and confusion, and the lack of a unified
it difficult to properly build, test, and use various techniques and nomenclature makes it difficult to properly build, test, and use
tools. various techniques and tools.
We are interested in information-carrying capacity, but even this is We are interested in information-carrying capacity, but even this is
not straightforward. Each of the layers, depending on the medium, not straightforward. Each of the layers, depending on the medium,
adds overhead to the task of carrying information. The wired adds overhead to the task of carrying information. The wired
Ethernet uses Manchester coding or 4/5 coding which cuts down Ethernet uses Manchester coding or 4/5 coding which cuts down
considerably on the "theoretical" capacity. Similarly RF (radio considerably on the "theoretical" capacity. Similarly RF (radio
frequency) communications will often add redundancy to the coding frequency) communications will often add redundancy to the coding
scheme to implement forward error correction because the physical scheme to implement forward error correction because the physical
medium (air) is lossy. This can further decrease the information medium (air) is lossy. This can further decrease the information
efficiency. efficiency.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
2. Definitions 2. Definitions
In this section, we specify definitions for capacity. We begin by In this section, we specify definitions for capacity. We begin by
first defining a baseline capacity that is simply tied to the first defining a baseline capacity that is simply tied to the
physical properties of the link. physical properties of the link.
Nominal Physical Link Capacity: Nominal Physical Link Capacity:
Or NomCap(L) is the theoretical maximum amount of data that the Or NomCap(L) is the theoretical maximum amount of data that the
link can support. For example, an OC-3 link would be capable of link can support. For example, an OC-3 link would be capable of
roughly 155 Mbps and does not vary with time. We stress that this roughly 155 Mbps. We stress that this is a measurement at the
is a measurement at the physical layer and not the network IP physical layer and not the network IP layer, which we will define
layer, which we will define separately. separately. While NomCap(L) is typically constant over time,
there are links whose characteristics may allow otherwise, such as
the dynamic activation of additional transponders for a satellite
link.
There are many factors that can reduce the information carrying The nominal physical link capacity is provided as a means to help
capacity of the link, some of which have already been discussed distinguish between the commonly used link layer capacities and the
earlier in the introduction. However, the goal of this document is remaining definitions for IP layer capacity. As a result, the value
not to become an exhaustive list of of such factors. Rather, we of NomCap(L) does not influence the other definitions presented in
outline some of the major examples in the following section, thus this document.
providing food for thought to those implementing the algorithms or
tools that attempt to accurately quantify these values. There are many factors that can reduce the IP information carrying
capacity of the link, some of which have already been discussed in
the introduction. However, the goal of this document is not to
become an exhaustive list of of such factors. Rather, we outline
some of the major examples in the following section, thus providing
food for thought to those implementing the algorithms or tools that
attempt to measure capacity accurately.
The remaining definitions are all given in terms of "IP layer bits" The remaining definitions are all given in terms of "IP layer bits"
in order to distinguish these definitions from the nominal physical in order to distinguish these definitions from the nominal physical
capacity of the link. capacity of the link.
IP layer bits: IP layer bits:
Eight (8) times the number of octets in all IP packets received, Eight (8) times the number of octets in all IP packets received,
from the first octet of the IP header to the last octet of the IP from the first octet of the IP header to the last octet of the IP
packet payload, inclusive. packet payload, inclusive.
We then define a path P of length n as a series of links (L1, L2, We then define a path P of length n as a series of links (L1, L2,
..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A
source, S, and destination, D, reside at N1 and Nn+1 respectively. source, S, and destination, D, reside at N1 and Nn+1 respectively.
Furthermore, we define a link L as a special case where the path size Furthermore, we define a link L as a special case where the path size
is one. IP layer bits are recorded at the destination, D, beginning is one. The concept of links are consistent with [RFC2330] in that
at time T and ending at a time T+I. Since the definitions are based they represent a link-level connection between two nodes, and each
on averages, the two time parameters, T and I, must accompany any node is not necessarily a router. However, the concept of a path
report or estimate of the following values in order for them to differs slightly as intermediate nodes N2...Nn do not need to be
remain meaningful. It is not required that the interval boundary routers. They may, for example, be Ethernet switches or other kinds
points fall between packet arrivals at D. However, boundaries that of layer 2 or layer 1 devices.
fall within a packet will invalidate the packets on which they fall.
IP layer bits are recorded at the destination, D, beginning at time T
and ending at a time T+I. Since the definitions are based on
averages, the two time parameters, T and I, must accompany any report
or estimate of the following values in order for them to remain
meaningful. It is not required that the interval boundary points
fall between packet arrivals at D. However, boundaries that fall
within a packet will invalidate the packets on which they fall.
Specifically, the data from the partial packet that is contained Specifically, the data from the partial packet that is contained
within the interval will not be counted. This may artificially bias within the interval will not be counted. This may artificially bias
some of the values, depending on the length of the interval and the some of the values, depending on the length of the interval and the
amount of data received during that interval. We elaborate on what amount of data received during that interval. We elaborate on what
constitutes correctly received data in the next section. constitutes correctly received data in the next section.
IP Layer Link Capacity: IP Layer Link Capacity:
We define the IP Layer link capacity, C(L,T,I), to be the maximum We define the IP Layer link capacity, C(L,T,I), to be the maximum
number of IP layer bits that can be transmitted from S and number of IP layer bits that can be transmitted from the source S
correctly received by D over the link L during the interval [T, and correctly received by the destination D over the link L during
T+I], divided by I. the interval [T, T+I], divided by I.
Using this, we can then extend this notion to an entire path, such Using this, we can then extend this notion to an entire path, such
that the IP layer path capacity simply becomes that of the link with that the IP layer path capacity simply becomes that of the link with
the smallest capacity along that path. the smallest capacity along that path.
IP Layer Path Capacity: IP Layer Path Capacity:
C(P,T,I) = min {1..n} {C(Ln,T,I)} C(P,T,I) = min {1..n} {C(Ln,T,I)}
The previous definitions specify a link's capacity, namely the IP The previous definitions specify a link's capacity, namely the IP
information bits that can be transmitted across a link or path should information bits that can be transmitted across a link or path should
the resource be free of any contention. Determining how much the resource be free of any congestion. Determining how much
capacity is available for use on a congested link is potentially much capacity is available for use on a congested link is potentially much
more useful. However, in order to define the available capacity we more useful. However, in order to define the available capacity we
must first specify how much is being used. must first specify how much is being used.
IP Layer Link Usage: IP Layer Link Usage:
The average usage of a link L, Used(L,T,I), is the actual number The average usage of a link L, Used(L,T,I), is the actual number
of IP layer bits correctly transmitted from any source over link L of IP layer bits correctly transmitted from any source over link L
during the interval [T, T+I], divided by I. during the interval [T, T+I], divided by I.
An important distinction between usage and capacity is that An important distinction between usage and capacity is that
skipping to change at page 7, line 14 skipping to change at page 7, line 25
IP Layer Available Link Capacity IP Layer Available Link Capacity
AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )
IP Layer Available Path Capacity IP Layer Available Path Capacity
AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)} AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}
Since measurements of available capacity are more volatile that that Since measurements of available capacity are more volatile that that
of capacity, it is important that both the time and interval be of capacity, it is important that both the time and interval be
specified as their values have a great deal of influence on the specified as their values have a great deal of influence on the
results. In addition, a range of measurements may be beneficial in results. In addition, a sequence of measurements may be beneficial
offsetting the volatility when attempting to characterize available in offsetting the volatility when attempting to characterize
capacity. available capacity.
3. Discussion 3. Discussion
3.1 Standard or Correctly Formed Packets 3.1 Standard or Correctly Formed Packets
The definitions in this document specify that IP packets must be The definitions in this document specify that IP packets must be
received correctly. The IPPM framework recommends a set of criteria received correctly. The IPPM framework recommends a set of criteria
for such standard-formed packet in section 15 of [RFC2330]. However, for such standard-formed packet in section 15 of [RFC2330]. However,
it is inadequate for use with this document. Thus, we outline our it is inadequate for use with this document. Thus, we outline our
own criteria below while pointing out any variations or similarities own criteria below while pointing out any variations or similarities
to [RFC2330]. to [RFC2330].
First, data that is in error at layers below IP and cannot be First, data that is in error at layers below IP and cannot be
properly passed to the IP layer should not be counted. For example, properly passed to the IP layer should not be counted. For example,
wireless media often has a considerably large error rate, resulting wireless media often has a considerably larger error rate than wired
in a reduction in IP Link Capacity. In accordance with the media, resulting in a reduction in IP Link Capacity. In accordance
framework, packets that fail validation of the IP header should be with the framework, packets that fail validation of the IP header
discarded. Specifically, the requirements in [RFC1812] section 5.2.2 should be discarded. Specifically, the requirements in [RFC1812]
on IP header validation should be checked, which includes a valid section 5.2.2 on IP header validation should be checked, which
length, checksum, and version field. includes a valid length, checksum, and version field.
The framework makes further restrictions, requiring that any The framework specifies further restrictions, requiring that any
transport header be checked for correctness and that any packets with transport header be checked for correctness and that any packets with
IP options be ignored. However, the definitions in this document are IP options be ignored. However, the definitions in this document are
concerned with the traversal of IP layer bits. As a result, data concerned with the traversal of IP layer bits. As a result, data
from the higher layers is not required to be valid or understood as from the higher layers is not required to be valid or understood as
they are simply regarded as part of the IP packet. The same holds they are simply regarded as part of the IP packet. The same holds
true for IP options. Valid IP fragments should also be counted as true for IP options. Valid IP fragments should also be counted as
they expend the resources of a link even though assembly of the full they expend the resources of a link even though assembly of the full
packet may not be possible. The framework differs in this area, packet may not be possible. The framework differs in this area,
discarding IP fragments. discarding IP fragments.
skipping to change at page 9, line 23 skipping to change at page 9, line 23
3.3 Common Literature Terminology 3.3 Common Literature Terminology
Certain terms are often used to characterize specific aspects of the Certain terms are often used to characterize specific aspects of the
presented definitions. The link with the smallest capacity is presented definitions. The link with the smallest capacity is
commonly referred to as the "narrow link" of a path. Also, the value commonly referred to as the "narrow link" of a path. Also, the value
of n that satisfies AvailCap(P,T,I), is often referred to as the of n that satisfies AvailCap(P,T,I), is often referred to as the
"tight link" within a path. So, while Ln may have a very large "tight link" within a path. So, while Ln may have a very large
capacity, the overall congestion level on the link makes it the capacity, the overall congestion level on the link makes it the
likely bottleneck of a connection. Conversely, a link that has the likely bottleneck of a connection. Conversely, a link that has the
smallest capacity may not be a bottleneck should it be lightly smallest capacity may not be a bottleneck should it be lightly loaded
congested in relation to the rest of the path. in relation to the rest of the path.
Also, common literature often overloads the term "bandwidth" to refer Also, common literature often overloads the term "bandwidth" to refer
to what we have described as capacity in this document. For example, to what we have described as capacity in this document. For example,
when inquiring about the bandwidth of a 802.11b link, a network when inquiring about the bandwidth of a 802.11b link, a network
engineer will likely answer with 11 Mbps. However, an electrical engineer will likely answer with 11 Mbps. However, an electrical
engineer may answer with 25 MHz, and an end user may tell you that engineer may answer with 25 MHz, and an end user may tell you that
his observed bandwidth is 8 Mbps. In contrast, the term capacity is his observed bandwidth is 8 Mbps. In contrast, the term capacity is
not quite as overloaded and is an appropriate term that better not quite as overloaded and is an appropriate term that better
reflects what is actually being measured. reflects what is actually being measured.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
techniques are useful in exploring the characteristics of a network techniques are useful in exploring the characteristics of a network
path, but from different perspectives. path, but from different perspectives.
3.5 Type P Packets 3.5 Type P Packets
Note that these definitions do not make mention of "Type P" packets, Note that these definitions do not make mention of "Type P" packets,
while other IPPM definitions do. We could add the packet type as an while other IPPM definitions do. We could add the packet type as an
extra parameter. This would have the effect of defining a large extra parameter. This would have the effect of defining a large
number of quantities, relative to the QoS policies that a given number of quantities, relative to the QoS policies that a given
network or concatenation of networks may have in effect in the path. network or concatenation of networks may have in effect in the path.
It would produce metrics such as "estimated EF IP Link/Path It would produce metrics such as "estimated EF IP Link/Path Capacity"
Capacity". or "estimated EF IP Link Utilization".
Such metrics may indeed be useful. For example, this would yield Such metrics may indeed be useful. For example, this would yield
something like the sum of the capacities of all the QoS classes something like the sum of the capacities of all the QoS classes
defined along the path as the link or path capacity. The breakdown defined along the path as the link or path capacity. The breakdown
then gives the user an analysis of how the link or path capacity (or then gives the user an analysis of how the link or path capacity (or
at least the "tight link" capacity) is allocated among classes. at least the "tight link" capacity) is allocated among classes.
These QoS-based capacities become difficult to measure on a path if These QoS-based capacities become difficult to measure on a path if
there are different capacities defined per QoS class on different there are different capacities defined per QoS class on different
links in the path. Possibly the best way to approach this would be links in the path. Possibly the best way to approach this would be
to measure each link in a path individually, and then combine the to measure each link in a path individually, and then combine the
information from individual links. However, such an approach is information from individual links.
extremely difficult in practice.
4. IANA Considerations 3.6 Time and Sampling
We must emphasize the importance of time in the basic definitions of
these quantities. We know that traffic on the Internet is highly
variable across all time scales. This argues that the time and
length of measurements are critical variables in reporting available
capacity measurements.
The closer to "instantaneous" a metric is, the more important it is
to have a plan for sampling the metric over a time period that is
sufficiently large. By doing so, we allow valid statistical
inferences to be made from the measurements. An obvious pitfall here
is sampling in a way that causes bias. For example, a situation
where the sampling frequency is a multiple of the frequency of an
underlying condition.
4. Conclusion
In this document, we have defined a set of quantities related to the
capacity of links in an IP network. In these definitions, we have
tried to be as clear as possible and take into account various
characteristics that links can have. The goal of these definitions
is to enable researchers who propose capacity metrics to relate those
metrics to these definitions and to evaluate those metrics with
respect to how well they approximate these quantities.
In addition, we have pointed out some key auxiliary parameters and
opened a discussion of issues related to valid inferences from
available capacity metrics.
5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
5. Security Considerations 6. Security Considerations
This document specifies definitions regarding IP traffic traveling This document specifies definitions regarding IP traffic traveling
between a source and destination in an IP network. These definitions between a source and destination in an IP network. These definitions
do not raise any security issues and do not have a direct impact on do not raise any security issues and do not have a direct impact on
the networking protocol suite. the networking protocol suite.
6. Acknowledgments 7. Acknowledgments
The authors would like to acknowledge Mark Allman, Matt Mathis, Al The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt
Morton, and Stas Shalunov for their suggestions, comments, and Mathis, Al Morton, and Stanislav Shalunov for their suggestions,
reviews. We also thank members of the IETF IPPM Mailing List for comments, and reviews. We also thank members of the IETF IPPM
their discussions and feedback on this document. Mailing List for their discussions and feedback on this document.
7. References 8. References
7.1 Normative References 8.1 Normative References
7.2 Informative References 8.2 Informative References
[PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet
Dispersion Techniques and a Capacity Estimation Dispersion Techniques and a Capacity Estimation
Methodology", IEEE/ACM Transactions on Networking 12(6): Methodology", IEEE/ACM Transactions on Networking 12(6):
963-977, December 2004. 963-977, December 2004.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 16, line 41 skipping to change at page 17, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 32 change blocks. 
68 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/