GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5136

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5136.txt · Last modified: 2008/02/08 03:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki