doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5136.txt b/doc/rfc/rfc5136.txt
new file mode 100644
index 0000000..b6134d7
--- /dev/null
+++ b/doc/rfc/rfc5136.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                        P. Chimento
+Request for Comments: 5136                       JHU Applied Physics Lab
+Category: Informational                                         J. Ishac
+                                              NASA Glenn Research Center
+                                                           February 2008
+
+
+                       Defining Network Capacity
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   Measuring capacity is a task that sounds simple, but in reality can
+   be quite complex.  In addition, the lack of a unified nomenclature on
+   this subject makes it increasingly difficult to properly build, test,
+   and use techniques and tools built around these constructs.  This
+   document provides definitions for the terms 'Capacity' and 'Available
+   Capacity' related to IP traffic traveling between a source and
+   destination in an IP network.  By doing so, we hope to provide a
+   common framework for the discussion and analysis of a diverse set of
+   current and future estimation techniques.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                      [Page 1]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Links and Paths  . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Definition: Nominal Physical Link Capacity . . . . . . . .  4
+     2.3.  Capacity at the IP Layer . . . . . . . . . . . . . . . . .  5
+       2.3.1.  Definition: IP-layer Bits  . . . . . . . . . . . . . .  5
+         2.3.1.1.  Standard or Correctly Formed Packets . . . . . . .  5
+         2.3.1.2.  Type P Packets . . . . . . . . . . . . . . . . . .  6
+       2.3.2.  Definition: IP-type-P Link Capacity  . . . . . . . . .  7
+       2.3.3.  Definition: IP-type-P Path Capacity  . . . . . . . . .  7
+       2.3.4.  Definition: IP-type-P Link Usage . . . . . . . . . . .  7
+       2.3.5.  Definition: IP-type-P Link Utilization . . . . . . . .  8
+       2.3.6.  Definition: IP-type-P Available Link Capacity  . . . .  8
+       2.3.7.  Definition: IP-type-P Available Path Capacity  . . . .  8
+   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     3.1.  Time and Sampling  . . . . . . . . . . . . . . . . . . . .  9
+     3.2.  Hardware Duplicates  . . . . . . . . . . . . . . . . . . .  9
+     3.3.  Other Potential Factors  . . . . . . . . . . . . . . . . .  9
+     3.4.  Common Terminology in Literature . . . . . . . . . . . . . 10
+     3.5.  Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                      [Page 2]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+1.  Introduction
+
+   Measuring the capacity of a link or network path is a task that
+   sounds simple, but in reality can be quite complex.  Any physical
+   medium requires that information be encoded and, depending on the
+   medium, there are various schemes to convert information into a
+   sequence of signals that are transmitted physically from one location
+   to another.
+
+   While on some media, the maximum frequency of these signals can be
+   thought of as "capacity", on other media, the signal transmission
+   frequency and the information capacity of the medium (channel) may be
+   quite different.  For example, a satellite channel may have a carrier
+   frequency of a few gigahertz, but an information-carrying capacity of
+   only a few hundred kilobits per second.  Often similar or identical
+   terms are used to refer to these different applications of capacity,
+   adding to the ambiguity and confusion, and the lack of a unified
+   nomenclature makes it difficult to properly build, test, and use
+   various techniques and tools.
+
+   We are interested in information-carrying capacity, but even this is
+   not straightforward.  Each of the layers, depending on the medium,
+   adds overhead to the task of carrying information.  The wired
+   Ethernet uses Manchester coding or 4/5 coding, which cuts down
+   considerably on the "theoretical" capacity.  Similarly, RF (radio
+   frequency) communications will often add redundancy to the coding
+   scheme to implement forward error correction because the physical
+   medium (air) is lossy.  This can further decrease the information
+   capacity.
+
+   In addition to coding schemes, usually the physical layer and the
+   link layer add framing bits for multiplexing and control purposes.
+   For example, on SONET there is physical-layer framing and typically
+   also some layer-2 framing such as High-Level Data Link Control
+   (HDLC), PPP, or ATM.
+
+   Aside from questions of coding efficiency, there are issues of how
+   access to the channel is controlled, which also may affect the
+   capacity.  For example, a multiple-access medium with collision
+   detection, avoidance, and recovery mechanisms has a varying capacity
+   from the point of view of the users.  This varying capacity depends
+   upon the total number of users contending for the medium, how busy
+   the users are, and bounds resulting from the mechanisms themselves.
+   RF channels may also vary in capacity, depending on range,
+   environmental conditions, mobility, shadowing, etc.
+
+
+
+
+
+
+Chimento & Ishac             Informational                      [Page 3]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+   The important points to derive from this discussion are these: First,
+   capacity is only meaningful when defined relative to a given protocol
+   layer in the network.  It is meaningless to speak of "link" capacity
+   without qualifying exactly what is meant.  Second, capacity is not
+   necessarily fixed, and consequently, a single measure of capacity at
+   any layer may in fact provide a skewed picture (either optimistic or
+   pessimistic) of what is actually available.
+
+2.  Definitions
+
+   In this section, we specify definitions for capacity.  We begin by
+   first defining "link" and "path" clearly, and then we define a
+   baseline capacity that is simply tied to the physical properties of
+   the link.
+
+2.1.  Links and Paths
+
+   To define capacity, we need to broaden the notions of link and path
+   found in the IP Performance Metrics (IPPM) framework document
+   [RFC2330] to include network devices that can impact IP capacity
+   without being IP aware.  For example, consider an Ethernet switch
+   that can operate ports at different speeds.
+
+   We define nodes as hosts, routers, Ethernet switches, or any other
+   device where the input and output links can have different
+   characteristics.  A link is a connection between two of these network
+   devices or nodes.  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 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 length is one.
+
+2.2.  Definition: Nominal Physical Link Capacity
+
+   Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum
+   amount of data that the link L can support.  For example, an OC-3
+   link would be capable of 155.520 Mbit/s.  We stress that this is a
+   measurement at the physical layer and not the network IP layer, which
+   we will define 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.
+
+   The nominal physical link capacity is provided as a means to help
+   distinguish between the commonly used link-layer capacities and the
+   remaining definitions for IP-layer capacity.  As a result, the value
+   of NomCap(L) does not influence the other definitions presented in
+   this document.  Instead, it provides an upper bound on those values.
+
+
+
+Chimento & Ishac             Informational                      [Page 4]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+2.3.  Capacity at the IP Layer
+
+   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 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"
+   in order to distinguish these definitions from the nominal physical
+   capacity of the link.
+
+2.3.1.  Definition: IP-layer Bits
+
+   IP-layer bits are defined as 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 packet payload, inclusive.
+
+   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
+   within the interval will not be counted.  This may artificially bias
+   some of the values, depending on the length of the interval and the
+   amount of data received during that interval.  We elaborate on what
+   constitutes correctly received data in the next section.
+
+2.3.1.1.  Standard or Correctly Formed Packets
+
+   The definitions in this document specify that IP packets must be
+   received correctly.  The IPPM framework recommends a set of criteria
+   for such standard-formed packets in Section 15 of [RFC2330].
+   However, it is inadequate for use with this document.  Thus, we
+   outline our own criteria below while pointing out any variations or
+   similarities to [RFC2330].
+
+   First, data that is in error at layers below IP and cannot be
+   properly passed to the IP layer must not be counted.  For example,
+   wireless media often have a considerably larger error rate than wired
+   media, resulting in a reduction in IP link capacity.  In accordance
+   with the IPPM framework, packets that fail validation of the IP
+
+
+
+
+Chimento & Ishac             Informational                      [Page 5]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+   header must be discarded.  Specifically, the requirements in
+   [RFC1812], Section 5.2.2, on IP header validation must be checked,
+   which includes a valid length, checksum, and version field.
+
+   The IPPM framework specifies further restrictions, requiring that any
+   transport header be checked for correctness and that any packets with
+   IP options be ignored.  However, the definitions in this document are
+   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
+   that data is simply regarded as part of the IP packet.  The same
+   holds true for IP options.  Valid IP fragments must also be counted
+   as they expend the resources of a link even though assembly of the
+   full packet may not be possible.  The IPPM framework differs in this
+   area, discarding IP fragments.
+
+   For a discussion of duplicates, please see Section 3.2.
+
+   In summary, any IP packet that can be properly processed must be
+   included in these calculations.
+
+2.3.1.2.  Type P Packets
+
+   The definitions in this document refer to "Type P" packets to
+   designate a particular type of flow or sets of flows.  As defined in
+   RFC 2330, Section 13, "Type P" is a placeholder for what may be an
+   explicit specification of the packet flows referenced by the metric,
+   or it may be a very loose specification encompassing aggregates.  We
+   use the "Type P" designation in these definitions in order to
+   emphasize two things: First, that the value of the capacity
+   measurement depends on the types of flows referenced in the
+   definition.  This is because networks may treat packets differently
+   (in terms of queuing and scheduling) based on their markings and
+   classification.  Networks may also arbitrarily decide to flow-balance
+   based on the packet type or flow type and thereby affect capacity
+   measurements.  Second, the measurement of capacity depends not only
+   on the type of the reference packets, but also on the types of the
+   packets in the "population" with which the flows of interest share
+   the links in the path.
+
+   All of this indicates two different approaches to measuring: One is
+   to measure capacity using a broad spectrum of packet types,
+   suggesting that "Type P" should be set as generic as possible.  The
+   second is to focus narrowly on the types of flows of particular
+   interest, which suggests that "Type P" should be very specific and
+   narrowly defined.  The first approach is likely to be of interest to
+   providers, the second to application users.
+
+
+
+
+
+Chimento & Ishac             Informational                      [Page 6]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+   As a practical matter, it should be noted that some providers may
+   treat packets with certain characteristics differently than other
+   packets.  For example, access control lists, routing policies, and
+   other mechanisms may be used to filter ICMP packets or forward
+   packets with certain IP options through different routes.  If a
+   capacity-measurement tool uses these special packets and they are
+   included in the "Type P" designation, the tool may not be measuring
+   the path that it was intended to measure.  Tool authors, as well as
+   users, may wish to check this point with their service providers.
+
+2.3.2.  Definition: IP-type-P Link Capacity
+
+   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 the source S and
+   correctly received by the destination D over the link L during the
+   interval [T, T+I], divided by I.
+
+   As mentioned earlier, this definition is affected by many factors
+   that may change over time.  For example, a device's ability to
+   process and forward IP packets for a particular link may have varying
+   effect on capacity, depending on the amount or type of traffic being
+   processed.
+
+2.3.3.  Definition: IP-type-P Path Capacity
+
+   Using our definition for IP-layer link capacity, we can then extend
+   this notion to an entire path, such that the IP-layer path capacity
+   simply becomes that of the link with the smallest capacity along that
+   path.
+
+   C(P,T,I) = min {1..n} {C(Ln,T,I)}
+
+   The previous definitions specify the number of IP-layer bits that can
+   be transmitted across a link or path should the resource be free of
+   any congestion.  It represents the full capacity available for
+   traffic between the source and destination.  Determining how much
+   capacity is available for use on a congested link is potentially much
+   more useful.  However, in order to define the available capacity, we
+   must first specify how much is being used.
+
+2.3.4.  Definition: IP-type-P Link Usage
+
+   The average usage of a link L, Used(L,T,I), is the actual number of
+   IP-layer bits from any source, correctly received over link L during
+   the interval [T, T+I], divided by I.
+
+
+
+
+
+
+Chimento & Ishac             Informational                      [Page 7]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+   An important distinction between usage and capacity is that
+   Used(L,T,I) is not the maximum number, but rather, the actual number
+   of IP bits sent that are correctly received.  The information
+   transmitted across the link can be generated by any source, including
+   those sources that may not be directly attached to either side of the
+   link.  In addition, each information flow from these sources may
+   share any number (from one to n) of links in the overall path between
+   S and D.
+
+2.3.5.  Definition: IP-type-P Link Utilization
+
+   We express usage as a fraction of the overall IP-layer link capacity.
+
+   Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )
+
+   Thus, the utilization now represents the fraction of the capacity
+   that is being used and is a value between zero (meaning nothing is
+   used) and one (meaning the link is fully saturated).  Multiplying the
+   utilization by 100 yields the percent utilization of the link.  By
+   using the above, we can now define the capacity available over the
+   link as well as the path between S and D.  Note that this is
+   essentially the definition in [PDM].
+
+2.3.6.  Definition: IP-type-P Available Link Capacity
+
+   We can now determine the amount of available capacity on a congested
+   link by multiplying the IP-layer link capacity with the complement of
+   the IP-layer link utilization.  Thus, the IP-layer available link
+   capacity becomes:
+
+   AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )
+
+2.3.7.  Definition: IP-type-P Available Path Capacity
+
+   Using our definition for IP-layer available link capacity, we can
+   then extend this notion to an entire path, such that the IP-layer
+   available path capacity simply becomes that of the link with the
+   smallest available capacity along that path.
+
+   AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}
+
+   Since measurements of available capacity are more volatile than that
+   of link capacity, we stress the importance that both the time and
+   interval be specified as their values have a great deal of influence
+   on the results.  In addition, a sequence of measurements may be
+   beneficial in offsetting the volatility when attempting to
+   characterize available capacity.
+
+
+
+
+Chimento & Ishac             Informational                      [Page 8]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+3.  Discussion
+
+3.1.  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 and must be reported when using these
+   definitions.
+
+   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.
+
+3.2.  Hardware Duplicates
+
+   We briefly consider the effects of paths where hardware duplication
+   of packets may occur.  In such an environment, a node in the network
+   path may duplicate packets, and the destination may receive multiple,
+   identical copies of these packets.  Both the original packet and the
+   duplicates can be properly received and appear to be originating from
+   the sender.  Thus, in the most generic form, duplicate IP packets are
+   counted in these definitions.  However, hardware duplication can
+   affect these definitions depending on the use of "Type P" to add
+   additional restrictions on packet reception.  For instance, a
+   restriction only to count uniquely-sent packets may be more useful to
+   users concerned with capacity for meaningful data.  In contrast, the
+   more general, unrestricted metric may be suitable for a user who is
+   concerned with raw capacity.  Thus, it is up to the user to properly
+   scope and interpret results in situations where hardware duplicates
+   may be prevalent.
+
+3.3.  Other Potential Factors
+
+   IP encapsulation does not affect the definitions as all IP header and
+   payload bits must be counted regardless of content.  However, IP
+   packets of different sizes can lead to a variation in the amount of
+   overhead needed at the lower layers to transmit the data, thus
+   altering the overall IP link-layer capacity.
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                      [Page 9]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+   Should the link happen to employ a compression scheme such as RObust
+   Header Compression (ROHC) [RFC3095] or V.44 [V44], some of the
+   original bits are not transmitted across the link.  However, the
+   inflated (not compressed) number of IP-layer bits should be counted.
+
+3.4.  Common Terminology in Literature
+
+   Certain terms are often used to characterize specific aspects of the
+   presented definitions.  The link with the smallest capacity is
+   commonly referred to as the "narrow link" of a path.  Also, the link
+   with the smallest available capacity is often referred to as the
+   "tight link" within a path.  So, while a given link may have a very
+   large capacity, the overall congestion level on the link makes it the
+   likely bottleneck of a connection.  Conversely, a link that has the
+   smallest capacity may not be the bottleneck should it be lightly
+   loaded in relation to the rest of the path.
+
+   Also, literature often overloads the term "bandwidth" to refer to
+   what we have described as capacity in this document.  For example,
+   when inquiring about the bandwidth of a 802.11b link, a network
+   engineer will likely answer with 11 Mbit/s.  However, an electrical
+   engineer may answer with 25 MHz, and an end user may tell you that
+   his observed bandwidth is 8 Mbit/s.  In contrast, the term "capacity"
+   is not quite as overloaded and is an appropriate term that better
+   reflects what is actually being measured.
+
+3.5.  Comparison to Bulk Transfer Capacity (BTC)
+
+   Bulk Transfer Capacity (BTC) [RFC3148] provides a distinct
+   perspective on path capacity that differs from the definitions in
+   this document in several fundamental ways.  First, BTC operates at
+   the transport layer, gauging the amount of capacity available to an
+   application that wishes to send data.  Only unique data is measured,
+   meaning header and retransmitted data are not included in the
+   calculation.  In contrast, IP-layer link capacity includes the IP
+   header and is indifferent to the uniqueness of the data contained
+   within the packet payload.  (Hardware duplication of packets is an
+   anomaly addressed in a previous section.)  Second, BTC utilizes a
+   single congestion-aware transport connection, such as TCP, to obtain
+   measurements.  As a result, BTC implementations react strongly to
+   different path characteristics, topologies, and distances.  Since
+   these differences can affect the control loop (propagation delays,
+   segment reordering, etc.), the reaction is further dependent on the
+   algorithms being employed for the measurements.  For example,
+   consider a single event where a link suffers a large duration of bit
+   errors.  The event could cause IP-layer packets to be discarded, and
+   the lost packets would reduce the IP-layer link capacity.  However,
+   the same event and subsequent losses would trigger loss recovery for
+
+
+
+Chimento & Ishac             Informational                     [Page 10]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+   a BTC measurement resulting in the retransmission of data and a
+   potentially reduced sending rate.  Thus, a measurement of BTC does
+   not correspond to any of the definitions in this document.  Both
+   techniques are useful in exploring the characteristics of a network
+   path, but from different perspectives.
+
+4.  Security Considerations
+
+   This document specifies definitions regarding IP traffic traveling
+   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
+   the networking protocol suite.
+
+   Tools that attempt to implement these definitions may introduce
+   security issues specific to each implementation.  Both active and
+   passive measurement techniques can be abused, impacting the security,
+   privacy, and performance of the network.  Any measurement techniques
+   based upon these definitions must include a discussion of the
+   techniques needed to protect the network on which the measurements
+   are being performed.
+
+5.  Conclusion
+
+   In this document, we have defined a set of quantities related to the
+   capacity of links and paths in an IP network.  In these definitions,
+   we have tried to be as clear as possible and take into account
+   various characteristics that links and paths 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.
+
+6.  Acknowledgments
+
+   The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt
+   Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their
+   suggestions, comments, and reviews.  We also thank members of the
+   IETF IPPM Mailing List for their discussions and feedback on this
+   document.
+
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                     [Page 11]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
+              RFC 1812, June 1995.
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330,
+              May 1998.
+
+7.2.  Informative References
+
+   [PDM]      Dovrolis, C., Ramanathan, P., and D. Moore, "Packet
+              Dispersion Techniques and a Capacity Estimation
+              Methodology", IEEE/ACM Transactions on Networking 12(6):
+              963-977, December 2004.
+
+   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
+              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
+              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
+              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
+              Compression (ROHC): Framework and four profiles: RTP, UDP,
+              ESP, and uncompressed", RFC 3095, July 2001.
+
+   [RFC3148]  Mathis, M. and M. Allman, "A Framework for Defining
+              Empirical Bulk Transfer Capacity Metrics", RFC 3148,
+              July 2001.
+
+   [V44]      ITU Telecommunication Standardization Sector (ITU-T)
+              Recommendation V.44, "Data Compression Procedures",
+              November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                     [Page 12]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+Authors' Addresses
+
+   Phil Chimento
+   JHU Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, Maryland  20723-6099
+   USA
+
+   Phone: +1-240-228-1743
+   Fax:   +1-240-228-0789
+   EMail: Philip.Chimento@jhuapl.edu
+
+
+   Joseph Ishac
+   NASA Glenn Research Center
+   21000 Brookpark Road, MS 54-5
+   Cleveland, Ohio  44135
+   USA
+
+   Phone: +1-216-433-6587
+   Fax:   +1-216-433-8705
+   EMail: jishac@nasa.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                     [Page 13]
+
+RFC 5136                    Network Capacity               February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Chimento & Ishac             Informational                     [Page 14]
+