Internet Engineering Task Force X. Cui Internet-Draft Huawei Obsoletes: 5136 (if approved) October 16, 2010 Intended status: Informational Expires: April 19, 2011 Defining Network Capacity draft-cui-ippm-rfc5136bis-00 Abstract This document defines the metric of network capacity, including link capacity aspect, router capacity aspect and path capacity aspect. RFC5136 has defined link capacity and path capacity, where the router impact is implicitly considered in link capacity. However, in this document, router capacity is considerred as a separate factor of path capacity, no longer a factor of link capacity. This document explicitly describes the router capacity and its impact to network capacity, e.g. how to evaluate path capacity. This document is derived from RFC5136 and obsoletes RFC5136. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 19, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Cui Expires April 19, 2011 [Page 1] Internet-Draft Network Capacity October 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview of Capacity . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Component Definitions . . . . . . . . . . . . . . . . . . 6 2.1.1. Node . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Non-IP-Node . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. Router . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. Link . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Definition: Nominal Physical Capacity . . . . . . . . . . 8 2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 8 2.3.1. Definition: IP-layer Bits . . . . . . . . . . . . . . 9 2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 10 2.3.3. Definition: IP-type-P Link Usage . . . . . . . . . . . 12 2.3.4. Definition: IP-type-P Link Utilization . . . . . . . . 12 2.3.5. Definition: IP-type-P Available Link Capacity . . . . 12 2.3.6. Definition: IP-type-P Router Capacity . . . . . . . . 12 2.3.7. Definition: IP-type-P Router Usage . . . . . . . . . . 13 2.3.8. Definition: IP-type-P Router Utilization . . . . . . . 14 2.3.9. Definition: IP-type-P Available Router Capacity . . . 14 2.3.10. Definition: IP-type-P Path Capacity . . . . . . . . . 14 2.3.11. Definition: IP-type-P Available Path Capacity . . . . 16 3. Changes from RFC5136 . . . . . . . . . . . . . . . . . . . . . 16 3.1. Node Definition . . . . . . . . . . . . . . . . . . . . . 16 3.2. Link Definition . . . . . . . . . . . . . . . . . . . . . 17 3.3. Path Definition . . . . . . . . . . . . . . . . . . . . . 17 3.4. Definition: Nominal Physical Capacity . . . . . . . . . . 18 3.5. IP-type-P Link Capacity . . . . . . . . . . . . . . . . . 18 3.6. IP-type-P Router Capacity . . . . . . . . . . . . . . . . 20 3.7. IP-type-P Router Usage . . . . . . . . . . . . . . . . . . 21 3.8. IP-type-P Router Utilization . . . . . . . . . . . . . . . 21 3.9. IP-type-P Available Router Capacity . . . . . . . . . . . 21 3.10. IP-type-P Path Capacity . . . . . . . . . . . . . . . . . 22 3.11. IP-type-P Available Path Capacity . . . . . . . . . . . . 23 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 23 Cui Expires April 19, 2011 [Page 2] Internet-Draft Network Capacity October 2010 4.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 24 4.3. Other Potential Factors . . . . . . . . . . . . . . . . . 24 4.4. Common Terminology in Literature . . . . . . . . . . . . . 24 4.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 25 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Cui Expires April 19, 2011 [Page 3] Internet-Draft Network Capacity October 2010 1. Introduction The IPPM working group has defined a framework for IP Performance Metrics [RFC2330] and a set of IP Performance Metrics, such as One- way Delay Metric [RFC2679], Packet Delay Variation Metric [RFC3393] and Network Capacity Metric [RFC5136]. Network capacity, which is defined in [RFC5136], is one of the most important IP Performance Metrics in internet. In [RFC5136], network capacity consists of link capacity, path capacity, link usage, link utilization, available link capacity and available path capacity. [RFC5136] also introduces the definitions, measurement and calculation methods and some important formulas. As stated in [RFC5136], "measuring the capacity of a link or network path is a task that sounds simple, but in reality can be quite complex". There are so many factors and so complicated coupling (between these factors) that the factor of router capacity is not explicitly stated in [RFC5136]. Router is an important element of internet and it is also an essential component of path. In [RFC5136] router impact is implicitly considered in link capacity, but it should be considered in path and path capacity instead, because router is a part of path while not a part of link. This memo explicitly presents that the router factor should be considered in path, path capacity and related metrics (e.g. available path capacity). For the integrity of network capacity metrics, this memo additionally defines router capacity, router usage, router utilization and available router capacity. This memo is the latest development based on [RFC5136] and draws heavily from it. The remainder of this memo is structured as follows. Section 2.1 contains component definitions and explanations (node, host, router, link, path, etc.) Section 2.2 contains nominal physical capacity and explanations of link and router. Section 2.3 give IP-layer capacity definitions and explanstions. It is structured in 11 subsections: - IP-layer Bits (section 2.3.1) - IP-type-P Link Capacity (section 2.3.2) - IP-type-P Link Usage (section 2.3.3) - IP-type-P Link Utilization (section 2.3.4) Cui Expires April 19, 2011 [Page 4] Internet-Draft Network Capacity October 2010 - IP-type-P Available Link Capacity (section 2.3.5) - IP-type-P Router Capacity (section 2.3.6) - IP-type-P Router Usage (section 2.3.7) - IP-type-P Router Utilization (section 2.3.8) - IP-type-P Available Router Capacity (section 2.3.9) - IP-type-P Path Capacity (section 2.3.10) - IP-type-P Available Path Capacity (section 2.3.11) Section 3 describes changes from [RFC5136]. Section 4 gives some complementary discussion. Section 5 gives discussion conclusion. 1.1. Overview of Capacity 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 Cui Expires April 19, 2011 [Page 5] Internet-Draft Network Capacity October 2010 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. 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. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Definitions In this section, we specify component definitions and capacity definitions. 2.1. Component Definitions In this section, we specify component definitions for network. We define "node", "Non-IP-Node", "host", "router", "link" and "path" clearly in this section, then we define capacity of network in next section. 2.1.1. Node IPv6 Specification [RFC2460] defines node is a device that implements IPv6. Framework for IP Performance Metrics [RFC2330] defines host is a computer capable of communicating using the Internet protocols; includes "routers". The notion of host from [RFC2330] is equal to the notion of node from RFC2460. In this document, a node is a computer that implements IP protocol. Note in this document any node without specicial statement is an IP node. Cui Expires April 19, 2011 [Page 6] Internet-Draft Network Capacity October 2010 2.1.2. Non-IP-Node In this document, a Non-IP-Node is a device that can transmit, receive or forward bit flow, but doesn't implement IP protocol. The examples of Non-IP-Node are ethernet switch and hub. Note the Non-IP-Node may be part of link and impact the link capacity, for example, consider an ethernet switch that can operate ports at different speeds. 2.1.3. Host IPv6 Specification [RFC2460] defines a host as any node that is not a router. This document adopts this definition, and the notion of host in this document dosn't includes "routers". 2.1.4. Router [RFC2460] defines a router is a node that forwards IP packets not explicitly addressed to itself. This document adopts this definition. 2.1.5. Link [RFC2460] defines link is a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. [RFC2330] defines link is a single link-level connection between two (or more) hosts; includes leased lines, ethernets, frame relay clouds, etc. This document adopts the definition from [RFC2460]. Note that link is a bidirectional concept, link terminal and link- layer middle-box are included in link. 2.1.6. Path As defined in [RFC2330], a path of length n is a sequence of the form (N0, L1, N1, ..., Ln, Nn), where n >= 0, each Ni is a node, each Li is a link between Ni-1 and Ni, each N1...Nn-1 is a router. A pair (Li, Ni) is termed a 'hop'. In an appropriate operational configuration, the links and routers in the path facilitate network- layer communication of packets from N0 to Nn. Note that path is a unidirectional concept and a path of length one is not equal to the corresponding link. In this case, the Link (i.e., L1) is a part of the path, i.e., the sequence of (N0, L1, N1). Cui Expires April 19, 2011 [Page 7] Internet-Draft Network Capacity October 2010 2.2. Definition: Nominal Physical 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. Note when we define nominal physical capacity of link, link terminals are considered while the nodes (host or router) which are connected by the link are not gathered. This is because the link terminal (e.g., network interface card) is not integrant of computer, it is only an accessory of the computer. However, there may be some Non- IP-Node in the link, such as an ethereal switch. The physical link capacity is affected by the switch's ability to process and forward information bits for the given 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. The nominal physical capacity provides an upper bound on link capaciy of both IP-layer and link-layer. However, it is difficult to define the nominal physical capacity of a router. The routers are designed under many limitation, such as physical bound of CPU, memory and system bus. We usually use a pair of common principle to estimate a router: packet per second and bit per second. These two principles are coupled together, and in general, we almost can not correctly estimate a router by either of them. So we don't define nominal physical router capacity in this document. 2.3. Capacity at the IP Layer There are many factors that can reduce the IP information carrying capacity of the link. 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. Cui Expires April 19, 2011 [Page 8] Internet-Draft Network Capacity October 2010 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 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. Cui Expires April 19, 2011 [Page 9] Internet-Draft Network Capacity October 2010 For a discussion of duplicates, please see Section 4.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 [RFC2330], 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. 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. The "maximum" means that IP-type-P Cui Expires April 19, 2011 [Page 10] Internet-Draft Network Capacity October 2010 link capacity is the capacity representation when the link is fully utilized (i.e., nominal physical link capacity is fully used.) In theory, IP-layer link capacity may be calculated out from nominal physical link capacity. Usually, for any link whose link protocol is given, we can know well the encapsulation, overhead and overtail of the link layer protocol. In these cases, for Type P Packets, whose length is Lp, we can get IP-layer link capacity as: C(L,T,I) = [Lp/(Lh + Lp + Lt)] * [1 - BER(T, T+I)] * [1 - BDR(T, T+I)] * P(L) In this formula, - Lp denotes type P packet length (in IP layer), - Lh denotes link layer protocol overhead length, - Lt denotes link layer protocol overtail length, - BER(T, T+I) denotes Block Error or Lost Rate during the interval [T, T+I], - BDR(T, T+I) denotes Block Duplication Rate during the interval [T, T+I], - P(L) denotes nominal physical link capacity of the given link. Like nominal physical link capacity, IP-type-P link capacity is also a theoretical maximum value. But IP-type-P link capacity is not constant over time, becauese there are many types of link layer protocol and BER and BDR (e.g., BER/BDR of radio channel) may vary in different period. As defined in section 2.1.5, link is the layer 2 connection between nodes, so the nodes which are connected by the link are not part of the given link. However, there may be some Non-IP-Node in the link, such as an ethereal switch. The IP-type-P link capacity is affected by the switch's ability to process and forward IP packets for the given link. IP-type-P link capacity is affected by on-way Non-IP-Node but not affected by the nodes which are connected by the IP link. This means, the injecting node may affect how many packets are transpored between the source S and the destination D during the interval [T, T+I], and the incepting node may also affect how many packets are correctly received in the destination D, but these factors do not affect IP-type-P link capacity, because the capacity is the maximum value can be represented by the link. IP-type-P link capacity is similar to IP-type-P link usage in some percent. The comparison is described in the next section. Cui Expires April 19, 2011 [Page 11] Internet-Draft Network Capacity October 2010 2.3.3. 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. An important distinction between usage and capacity is that the capacity is a theoretical value (constant number) while the usage is a factually represented value (variable number). This is to say, Used(L,T,I) is not the maximum number, but rather, the actual average rate that IP bits 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.4. 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 available capacity over the link. 2.3.5. 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.6. Definition: IP-type-P Router Capacity As mentioned in section 2.2, we don't define nominal physical router capacity in this document, we only discuss the router IP capaicy for given packet type. We define the IP-type-P router capacity, C(R,T,I), to be the maximum number of IP-layer bits (in the formation of type P packet) that can Cui Expires April 19, 2011 [Page 12] Internet-Draft Network Capacity October 2010 be correctly transfered from the ingress interfaces to the egress interfaces during the interval [T, T+I], divided by I. Like nominal physical link capacity and IP-layer link capacity, IP-type-P router capacity is also a theoretical maximum value and typically constant over time. Note this is only a nominal value or an approximation, because the accurate IP layer router capacity depends on many factors. Any router faces the common challenge, its capacity representation depends on its atchitect design, memory (e.g. queueing) management, interface deployment and other implementation issues. for example, a router can support 1000 interfaces and the capacity of 1T bps for IP type P at best. When we configure this router with 100 interfaces/ links, we can get this capacity value (i.e., 1T bps). But if the router is configured with only one ingress interface/link and one egress interface/link, maybe the maximum capacity value this router can present is less than 1T bps, because of its internal bus structure factors, even each link has the IP layer capacity of 2T bps. On the other hand, as link capacity is node-independent, router capacity is not dependent on bits injection. The ingress link (i.e., the link which is attached to the ingress interface) may affect how many packets are injected to the router and the egress link (i.e., the link which is attached to the egress interface) may affect how many packets are forwarded to the next hop, but note the router capacity is the maximum number that we can get in all cases, for the given type P packets. 2.3.7. Definition: IP-type-P Router Usage The average usage of a Router R, Used(R,T,I), is the actual number of IP-layer bits (in the formation of type P packet) correctly transfered from any ingress interface to the right engree interface during the interval [T, T+I], divided by I. An important distinction between usage and capacity is that Used(R,T,I) is not the maximum number, but rather, the actual number of IP bits that are correctly transfered. The information forwarded through the router can be generated by any source, including those sources that are not directly attached to the router. In addition, each information flow from these sources may share the router in their respective path. Cui Expires April 19, 2011 [Page 13] Internet-Draft Network Capacity October 2010 2.3.8. Definition: IP-type-P Router Utilization We express usage as a fraction of the overall IP-layer router capacity. Util(R,T,I) = ( Used(R,T,I) / C(R,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 router is fully saturated). Multiplying the utilization by 100 yields the percent utilization of the router. By using the above, we can now define the capacity available throuth the router. 2.3.9. Definition: IP-type-P Available Router Capacity We can now determine the amount of available capacity on a congested router by multiplying the IP-layer router capacity with the complement of the IP-layer router utilization. Thus, the IP-layer available router capacity becomes: AvailCap(R,T,I) = C(R,T,I) * ( 1 - Util(R,T,I) ) As mentioned in router capacity section, AvailCap(R,T,I) is only an approximation, because the accurate available router capacity depends on many internal factors. 2.3.10. Definition: IP-type-P Path Capacity Using our definition for IP-layer link capacity and IP-layer router capacity, we can then extend these notions to an entire path. We define the IP-type-P IP-layer path capacity, C(P,T,I), to be the maximum number of IP-layer bits (in the formation of type P packet) that can be correctly transfered from the source to the destination during the interval [T, T+I], divided by I. Like link capacity and router capacity, path capacity is also a theoretical number. As mentioned earlier, the path of length n is a sequence of the form (N0, L1, N1, ..., Ln, Nn) and N1, N2, ..., Nn-1 are all routers and part of the path. But these links and routers may be part of one or multiple paths, for example, in the following scenario: Cui Expires April 19, 2011 [Page 14] Internet-Draft Network Capacity October 2010 +------+ +------+ +------+ +------+ | H1 |---L1---| | | |---L2---| H2 | +------+ | | | | +------+ | | | | | |L5 |L3 | R1 |---L4---| R2 | +------+ | | | | | | R3 | | | | | | +------+ | | | | | |L6 +------+ | | | | +------+ | H3 |---L7---| | | | | H4 | +------+ +------+ +------+ +------+ Host, Router, Link and Path Figure 1 There are multiple paths in this network, such as: Path P1 (from H1 to H2) -- (H1, L1, R1, L4, R2, L2, H2); Path P2 (from H1 to H3) -- (H1, L3, H3); Path P3 (from H1 to H3) -- (H1, L1, R1, L7, H3); Path P4 (from H2 to H1) -- (H2, L2, R2, L4, R1, L1, H1); Path P5 (from H2 to H3) -- (H2, L2, R2, L4, R1, L7, H3); and, Path P6 (from H2 to H4) -- (H2, L5, R3, L6, H4). Note this is not an exhaustive list. There are many other paths in this network, e.g., (R1, L4, R2). In this scenario, the path (H1, L3, H4) and the path (H2, L5, R3, L6, H4) are exclusive path. The IP-layer capacity of an exclusive path may be calculated by: C(P,T,I) = min {1..n} {C(Ln,T,I), C(Rn,T,I)} we can also find that the link of L1, L2, L4 are all shared by multiple paths and the router of R1 and R2 are the same. Because of the capacity sharing, path capacity rather depends on the capacity contribution from the links and the routers than the IP-layer capacity of themselves. So for any given path whose link or router overlaps with other path, the IP-layer path capacity becomes more complex, it depends on not only the IP-layer capacity of the links and the routers but also the "competitive" traffic (also in formation of type P packet) of other paths, which have overlap segment with the given path. This means the capacity of non-exclusive path is a variable, is external situation dependent. Cui Expires April 19, 2011 [Page 15] Internet-Draft Network Capacity October 2010 It is very difficult to calculate IP-type-P path capacity of non- exclusive path in general but we can get out the maximum number of path capacity from links and routers, to indicate the upper bound on path capacity. The maximum number of IP-layer capacity of non-exclusive path may be calculated by: Cmax(P,T,I) = min {1..n} {C(Ln,T,I), C(Rn,T,I)} 2.3.11. Definition: IP-type-P Available Path Capacity Using our definition for IP-layer available link capacity and IP- layer available router capacity, we can then extend these notions to an entire path, such that the IP-layer available path capacity simply becomes that of the link and router with the smallest available capacity along that path. AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I), AvailCap(Rn,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. 3. Changes from RFC5136 In general, this document clarifies some definitions (e.g., path) and expounds that the capacity metrics (e.g., IP-type-P link capacity) are theoretical number. In addition, usage metrics (e.g., IP-type-P link usage) are very different from capacity metrics because they are actual number represented in measurement cases. 3.1. Node Definition Section 2.1 from [RFC5136] has been changed from: We define nodes as hosts, routers, Ethernet switches, or any other device where the input and output links can have different characteristics. to Section 2.1.1 of this memo: Node is a computer that implements IP protocol. Cui Expires April 19, 2011 [Page 16] Internet-Draft Network Capacity October 2010 Reason/summarization: The reason for this modification is to follow the most idiomatic definition. Non-IP device is excluded in the notion of node. 3.2. Link Definition Section 2.1 from [RFC5136] has been changed from: A link is a connection between two of these network devices or nodes. to Section 2.1.5 of this memo: Link is a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. Reason/summarization: The reason for this modification is to clarify the notion. The connection between layer1 or layer2 devices is not an absolute link, but only a segment of link. 3.3. Path Definition Section 2.1 from [RFC5136] has been changed from: 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. to Section 2.1.6 of this memo: A path of length n is a sequence of the form (N0, L1, N1, ..., Ln, Nn), where n >= 0, each Ni is a node, each Li is a link between Ni-1 and Ni, each N1...Nn-1 is a router. A pair (Li, Ni) is termed a 'hop'. In an appropriate operational configuration, the links and routers in the path facilitate network-layer communication of packets from N0 to Nn. Reason/summarization: The reason for this modification is to emphasize that routers in the path are essential component of the path. Cui Expires April 19, 2011 [Page 17] Internet-Draft Network Capacity October 2010 3.4. Definition: Nominal Physical Capacity Section 2.2 from [RFC5136] has been changed from "Definition: Nominal Physical Link Capacity" to "Definition: Nominal Physical Capacity". And some statement are added, including: Note when we define nominal physical capacity of link, link terminals are considered while the nodes (host or router) which are connected by the link are not gathered. This is because the link terminal (e.g., network interface card) is not integrant of computer, it is only an accessory of the computer. However, there may be some non- IP-node in the link, such as the ethereal switch. The physical link capacity is affected by the switch's ability to process and forward information bits for the given link. and, However, it is difficult to define the nominal physical capacity of a router. The routers are designed under many limitation, such as physical bound of CPU, memory and system bus. We usually use a pair of common principle to estimate a router: packet per second and bit per second. These two principles are coupled together, and in general, we almost can not correctly estimate a router by either of them. So we don't define nominal physical router capacity in this document. 3.5. IP-type-P Link Capacity Section 2.3.2 from [RFC5136] has been changed from: 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. to Section 2.3.2 of this memo: 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. The "maximum" means that IP-type-P link capacity is the capacity representation when the link is fully Cui Expires April 19, 2011 [Page 18] Internet-Draft Network Capacity October 2010 utilized (i.e., nominal physical link capacity is fully used.) In theory, IP-layer link capacity may be calculated out from nominal physical link capacity. Usually, for any link whose link protocol is given, we can know well the encapsulation, overhead and overtail of the link layer protocol. In these cases, for Type P Packets, whose length is Lp, we can get IP-layer link capacity as: C(L,T,I) = [Lp/(Lh + Lp + Lt)] * [1 - BER(T, T+I)] * [1 - BDR(T, T+I)] * P(L) In this formula, - Lp denotes type P packet length (in IP layer), - Lh denotes link layer protocol overhead length, - Lt denotes link layer protocol overtail length, - BER(T, T+I) denotes Block Error or Lost Rate during the interval [T, T+I], - BDR(T, T+I) denotes Block Duplication Rate during the interval [T, T+I], - P(L) denotes nominal physical link capacity of the given link. Like nominal physical link capacity, IP-type-P link capacity is also a theoretical maximum value. But IP-type-P link capacity is not constant over time, becauese there are many types of link layer protocol and BER and BDR (e.g., BER/BDR of radio channel) may vary in different period. As defined in section 2.1.5, link is the layer 2 connection between nodes, so the nodes which are connected by the link are not part of the given link. However, there may be some Non-IP-Node in the link, such as the ethereal switch. The IP-type-P link capacity is affected by the switch's ability to process and forward IP packets for the given link. IP-type-P link capacity is affected by on-way Non-IP-Node but not affected by the nodes which are connected by the IP link. This means, the injecting node may affect how many packets are transpored between the source S and the destination D during the interval [T, T+I], and the incepting node may also affect how many packets are correctly received in the destination D, but these factors do not affect IP-type-P link capacity, because the capacity is the maximum value can be represented by the link. IP-type-P link capacity is similar to IP-type-P link usage in some percent. The comparison is described in the next section. Reason/summarization: Cui Expires April 19, 2011 [Page 19] Internet-Draft Network Capacity October 2010 This modification clarifies the definition and calculation of link capacity and explicitly indicates that node doesn't affect link capacity but the Non-IP-Node which is part of link does. 3.6. IP-type-P Router Capacity Section 2.3.6 is newly added in this memo, as: As mentioned in section 2.2, we don't define nominal physical router capacity in this document, we only discuss the router IP capaicy for given packet type. We define the IP-type-P router capacity, C(R,T,I), to be the maximum number of IP-layer bits (in the formation of type P packet) that can be correctly transfered from the ingress interfaces to the egress interfaces during the interval [T, T+I], divided by I. Like nominal physical link capacity and IP-layer link capacity, IP-type-P router capacity is also a theoretical maximum value and typically constant over time Note this is only a nominal value or an approximation, because the accurate IP layer router capacity depends on many factors. Any router faces the common challenge, its capacity representation depends on its atchitect design, memory (e.g. queueing) management, interface deployment and other implementation issues. for example, a router can support 1000 interfaces and the capacity of 1T bps for IP type P at best. When we configure this router with 100 interfaces/ links, we can get this capacity value (i.e., 1T bps). But if the router is configured with only one ingress interface/link and one egress interface/link, maybe the maximum capacity value this router can present is less than 1T bps, because of its internal bus structure factors, even each link has the IP layer capacity of 2T bps. On the other hand, as link capacity is node-independent, router capacity is not dependent on bits injection. The ingress link (i.e., the link which is attached to the ingress interface) may affect how many packets are injected to the router and the egress link (i.e., the link which is attached to the egress interface) may affect how many packets are forwarded to the next hop, but note the router capacity is the maximum number that we can get in all cases, for the given type P packets. Reason/summarization: This modification defines IP-layer router capacity aspect from network capacity. Cui Expires April 19, 2011 [Page 20] Internet-Draft Network Capacity October 2010 3.7. IP-type-P Router Usage Section 2.3.7 is newly added in this memo, as: The average usage of a Router R, Used(R,T,I), is the actual number of IP-layer bits (in the formation of type P packet) correctly transfered from any ingress interface to the right engree interface during the interval [T, T+I], divided by I. An important distinction between usage and capacity is that Used(R,T,I) is not the maximum number, but rather, the actual number of IP bits that are correctly transfered. The information forwarded through the router can be generated by any source, including those sources that are not directly attached to the router. In addition, each information flow from these sources may share the router in their respective path. Reason/summarization: This modification defines IP-layer router usage aspect from network capacity. 3.8. IP-type-P Router Utilization Section 2.3.8 is newly added in this memo, as: We express usage as a fraction of the overall IP-layer router capacity. Util(R,T,I) = ( Used(R,T,I) / C(R,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 router is fully saturated). Multiplying the utilization by 100 yields the percent utilization of the router. By using the above, we can now define the capacity available throuth the router. Reason/summarization: This modification defines IP-layer router utilization aspect from network capacity. 3.9. IP-type-P Available Router Capacity Section 2.3.9 is newly added in this memo, as: Cui Expires April 19, 2011 [Page 21] Internet-Draft Network Capacity October 2010 We can now determine the amount of available capacity on a congested router by multiplying the IP-layer router capacity with the complement of the IP-layer router utilization. Thus, the IP-layer available router capacity becomes: AvailCap(R,T,I) = C(R,T,I) * ( 1 - Util(R,T,I) ) As mentioned in router capacity section, AvailCap(R,T,I) is only an approximation, because the accurate available router capacity depends on many internal factors. Reason/summarization: This modification defines IP-layer available router capacity aspect from network capacity. 3.10. IP-type-P Path Capacity Section 2.3.3 from [RFC5136] has been changed from: 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. to Section 2.3.10 of this memo: We define the IP-type-P IP-layer path capacity, C(P,T,I), to be the maximum number of IP-layer bits (in the formation of type P packet) that can be correctly transfered from the source to the destination during the interval [T, T+I], divided by I. Like link capacity and router capacity, path capacity is also a theoretical number. The IP-layer capacity of an exclusive path may be calculated by: C(P,T,I) = min {1..n} {C(Ln,T,I), C(Rn,T,I)} It is very difficult to calculate IP-type-P path capacity of non- Cui Expires April 19, 2011 [Page 22] Internet-Draft Network Capacity October 2010 exclusive path in general but we can get out the maximum number of path capacity from links and routers, to indicate the upper bound on path capacity. The maximum number of IP-layer capacity of non-exclusive path may be calculated by: Cmax(P,T,I) = min {1..n} {C(Ln,T,I), C(Rn,T,I)} Reason/summarization: This modification clarifies how to correctly evaluate path capacity. Router capacity is considered for path capacity. 3.11. IP-type-P Available Path Capacity Section 2.3.7 from [RFC5136] has been changed from: 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)} to Section 2.3.11 of this memo: Using our definition for IP-layer available link capacity and IP- layer available router capacity, we can then extend these notions to an entire path, such that the IP-layer available path capacity simply becomes that of the link and router with the smallest available capacity along that path. AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I), AvailCap(Rn,T,I)} Reason/summarization: This modification clarifies how to correctly evaluate available path capacity. Available router capacity is considered for available path capacity. 4. Discussion 4.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 Cui Expires April 19, 2011 [Page 23] Internet-Draft Network Capacity October 2010 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. 4.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. 4.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. 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. 4.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 Cui Expires April 19, 2011 [Page 24] Internet-Draft Network Capacity October 2010 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. 4.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 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. Cui Expires April 19, 2011 [Page 25] Internet-Draft Network Capacity October 2010 5. Conclusion In this document, we have defined a set of quantities related to the capacity of links, routers 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, routers 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. 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. 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgments The author would especially like to acknowledge Phil Chimento and Joseph Ishac for their great contribution on the item of network capacity. The author would like to acknowledge Mark Allman, Patrik Arlos, Matt Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their contribution on [RFC5136], which is the basis of this document. The author would also like to acknowledge Brian E Carpenter, Adrian Farrel, Spencer Dawkins, David Harrington and Barry Leiba for their Cui Expires April 19, 2011 [Page 26] Internet-Draft Network Capacity October 2010 review and discussion in the early stage of this document. 9. References 9.1. Normative References [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 9.2. Informative References [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [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. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008. [V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44, "Data Compression Procedures", November 2000. Cui Expires April 19, 2011 [Page 27] Internet-Draft Network Capacity October 2010 Author's Address Xiangsong Cui (editor) Huawei KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base Beijing, 100085 P.R. China Phone: Email: Xiangsong.Cui@huawei.com Cui Expires April 19, 2011 [Page 28]