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.
容量を測定することは簡単に聞こえる作業ですが、実際には、非常に複雑になることがあります。また、このテーマに関する統一命名法の欠如は、それがますます困難に適切に構築、テスト、およびこれらの構造を中心に構築手法やツールを使用できるようになります。この文書では、用語「キャパシティ」とIPネットワーク内の送信元と宛先の間を移動するIPトラフィックに関連する「空き容量」の定義を提供します。そうすることによって、我々は、現在および将来の推定技術の多様なセットの議論と分析のための共通のフレームワークを提供したいと考えています。
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
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.
当社は、情報搬送能力に興味を持っていますが、でもこれは簡単ではありません。層の各々は、媒体に応じて、情報を運ぶのタスクにオーバーヘッドを追加します。有線イーサネットは、マンチェスター符号化や「理論」能力に大幅に削減4/5コーディングを、使用しています。同様に、RF（無線周波数）通信は、多くの場合、物理媒体（空気）が非可逆であるため、順方向誤り訂正を実施するように符号化方式に冗長性を追加します。これにより、情報容量を減らすことができます。
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.
符号化方式に加えて、通常、物理層及びリンク層は、多重化および制御の目的のためにフレーミングビットを追加します。例えば、SONET上の物理層フレーミングおよび典型的には、このようなハイレベルデータリンク制御（HDLC）、PPP、またはATMのようないくつかのレイヤ2フレーミングがあります。
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.
別に符号化効率の問題から、チャネルへのアクセスを制御する方法の問題も能力に影響を与える可能性がある、があります。例えば、衝突検出、回避、及び回収機構を持つ複数のアクセス媒体は、ユーザーの観点から変化する容量を有します。この変化する容量は、機構自体に起因するユーザがどのようにビジー媒体を競合ユーザー、および境界の総数に依存します。 RFチャネルはまたなど、シャドウイング、範囲、環境条件に応じて、容量に移動性を変えることができます
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.
この議論から派生する重要な点は、これらは、次のとおり、ネットワーク内の所与のプロトコル層に対して定義された場合、まず、容量のみ意味があります。意味しているまさに修飾せずに「リンク」容量の話すことは無意味です。第二に、容量は、必ずしも固定されておらず、その結果、任意の層における容量の単一測定値は、実際に、実際に利用可能なものの（楽観的または悲観的のいずれか）斜め画像を提供することができます。
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.
このセクションでは、容量の定義を指定します。我々は明らかに最初に定義する「リンク」と「パス」で始まり、その後、我々は、単にリンクの物理的性質に結び付けられているベースラインの容量を定義します。
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.
容量を定義するために、我々はIPを意識せずにIP能力に影響を与えることができ、ネットワークデバイスが含まれるようにIPパフォーマンス・メトリック（IPPM）フレームワークドキュメント[RFC2330]で見つけたリンクとパスの概念を広げる必要があります。例えば、異なる速度でポートを操作することができるイーサネットスイッチを考えます。
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.
我々は、ホスト、ルータ、イーサネットスイッチ、または入力および出力リンクは、異なる特性を有することができる任意の他の装置としてのノードを定義します。リンクは、これらのネットワークデバイスまたはノードの二つの間の接続です。我々は、次に、ノード（N1、N2、...、Nnは+ 1）の配列を接続する一連のリンク（L1、L2、...、LN）として長さNの経路Pを画定します。ソースSと宛先Dは、それぞれ、N1およびNnは+ 1に存在します。さらに、我々は、経路長が1である特別な場合として、リンクLを定義します。
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.
公称物理リンク容量は、NomCap（L）、リンクLがサポートできるデータの理論的な最大量です。例えば、OC-3リンクが155.520メガビット/秒ことができるであろう。これは、物理層での測定ではなく、我々は、別途定義するネットワークIP層であることを強調します。 NomCap（L）は経時典型的に一定であるが、このような衛星リンクのための追加のトランスポンダの動的な活性化としてその特性さもなければ可能にリンクが存在します。
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.
公称物理リンク容量はIP層容量のために一般的に使用されるリンク層容量と残りの定義を区別するのに役立つ手段として設けられています。結果として、NomCap（L）の値は、この文書の他の定義に影響を及ぼしません。その代わりに、それらの値の上限を提供します。
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.
すでに導入で議論されているそのうちのいくつかはリンクの容量を運ぶIP情報を減らすことができ、多くの要因があります。しかし、この文書の目的は、そのような要因の完全なリストになることはありません。むしろ、我々は、このように正確な容量を測定しようとするアルゴリズムやツールを実装したものに思考のための食糧を提供し、次のセクションでは、主要な例のいくつかを概説します。
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.
残りの定義は、すべてのリンクの公称物理的容量からこれらの定義を区別するために「IPレイヤビット」の用語に与えられています。
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レイヤビットは包括IPパケットペイロードの最後のオクテットにIPヘッダの最初のオクテットから、受信したすべてのIPパケットのオクテットの8（8）倍の数として定義されます。
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.
IPレイヤビットは時刻Tに開始して時刻T + Iで終わる宛先Dに記録されています。定義は平均値、2時間パラメータに基づいているため、Tと私は、彼らが意味のままにするために次の値のいずれかのレポートや見積もりを添付しなければなりません。間隔境界点は、しかし、パケット内に収まる境界は、彼らが落ちた上のパケットを無効にするD.でパケットの到着の間に入ることを必要とされていません。具体的には、区間内に含まれる部分パケットからのデータはカウントされないであろう。これは、人工的間隔とその間隔の間に受信されるデータの量の長さに応じて、値の一部を付勢してもよいです。私たちは、次のセクションでは、正しく受信したデータを構成するものについて詳しく説明します。
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].
この文書の定義は、IPパケットが正しく受信されなければならないことを指定します。 IPPMフレームワークは[RFC2330]のセクション15で、標準的な成形されたパケットのための基準のセットをお勧めします。しかし、それはこのドキュメントで使用するには不十分です。したがって、私たちは[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.
まず、IP下の層にエラーがあり、適切にIP層に渡すことができないデータをカウントしてはなりません。例えば、無線媒体は、しばしばIPリンク容量の低下をもたらす、有線媒体よりもかなり大きいエラー率を有しています。 IPPMフレームワークに従って、IPヘッダの検証に失敗したパケットを廃棄しなければなりません。具体的には、[RFC1812]での要件は、IPヘッダの検証のセクション5.2.2は、有効長、チェックサム、バージョンフィールドを含む、チェックしなければなりません。
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.
IPPMフレームワークは、任意のトランスポートヘッダが正確性とIPオプションを持つすべてのパケットを無視することを確認することが必要、さらに制限を指定します。しかし、この文書に記載されている定義は、IPレイヤビットのトラバースに関するものです。そのデータは単にIPパケットの一部とみなされる結果として、上位層からのデータが有効であるために必要な又は理解されていません。同じことは、IPオプションにも当てはまります。彼らは完全なパケットの組み立てが可能でない場合であっても、リンクのリソースを費やすように有効なIPフラグメントもカウントされなければなりません。 IPPMフレームワークは、IPフラグメントを破棄し、この地域で異なります。
For a discussion of duplicates, please see Section 3.2.
重複の議論については、3.2節を参照してください。
In summary, any IP packet that can be properly processed must be included in these calculations.
要約すると、適切に処理することができます任意のIPパケットは、これらの計算に含めなければなりません。
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.
この文書に記載されている定義は、フローまたはフローの集合の特定のタイプを指定する「タイプP」パケットを指します。 RFC 2330、セクション13で定義されているように、「タイプP」は、メトリックによって参照されるパケットフローの明示的な指定であってもよく、またはそれは凝集体を包含する非常に緩い仕様とすることができるもののプレースホルダです。まず、容量測定の値が定義で参照フローの種類に依存していること：我々は2つのことを強調するために、これらの定義における「タイプP」呼称を使用しています。ネットワークは彼らのマーキングや分類に基づいて（キューイングおよびスケジューリングの面で）違ったパケットを扱う可能性があるためです。ネットワークはまた、任意に流れるバランスをするパケットタイプまたはフロータイプに基づいており、それによって容量の測定に影響を与えることを決定してもよいです。第二に、容量の測定は、参照パケットの種類に、だけでなく、関心の流れは、パス内のリンクを共有すると、「人口」内のパケットの種類に依存しないだけ。
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.
一つは、「タイプP」はできるだけ汎用として設定されるべきであることを示唆し、パケットタイプの広いスペクトルを使用して容量を測定することである：このすべては、測定する2つの異なるアプローチを示しています。第二は、「タイプP」は、非常に特異的であり、狭く定義されるべきであることを示唆している特定の関心の流れの種類に狭く集中することです。最初のアプローチは、プロバイダへの関心のアプリケーション・ユーザーへの第二である可能性が高いです。
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.
実際問題として、いくつかのプロバイダは、他のパケットとは異なる特定の特性を持つパケットを扱うことに留意すべきです。例えば、アクセス制御リスト、ルーティングポリシー、および他のメカニズムは、異なる経路を介してICMPパケットまたは特定のIPオプションを持つフォワードパケットをフィルタリングするために使用することができます。容量測定ツールは、これらの特殊なパケットを使用し、それらは「P型」の指定に含まれている場合、ツールは、それが測定することを意図したパスを測定しなくてもよいです。ツールの作者と同様に、ユーザーは、自分のサービスプロバイダとこの点を確認したいことがあります。
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.
我々は、ソースSから送信され、正しく間隔の間にリンクL上宛先Dによって受信することができるIPレイヤビットの最大数であることが、C（L、T、I）、IPレイヤのリンク容量を定義しますI.で割った[T、T + 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.
先に述べたように、この定義は、時間の経過とともに変更される可能性があり、多くの要因に影響されます。例えば、特定のリンクのためのデバイスの処理能力と前方IPパケットが処理されるトラフィックの量や種類に応じて、容量に影響を変化していることができます。
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.
IPレイヤのリンク容量のための私達の定義を使用して、我々は、IPレイヤのパス能力は、単にそのパスに沿って、最小容量のリンクのものとなるように、パス全体にこの概念を拡張することができます。
C(P,T,I) = min {1..n} {C(Ln,T,I)}
C（P、T、I）=分{1..nの} {C（L nを、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.
以前の定義は、リソースは、任意の輻輳の自由でなければならないリンクまたはパスを介して送信することができるIPレイヤのビット数を指定します。これは、送信元と宛先の間のトラフィックに使用可能な全容量を表しています。混雑したリンク上で使用するために提供されていますどのくらいの容量を決定することは、潜在的にはるかに便利です。しかし、利用可能な容量を定義するために、我々は最初に使用されているどのくらい指定する必要があります。
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.
、（L、T、I）中古リンクLの平均使用量はI.で割った、正常間隔[T、T + I]中、リンクLを介して受信し、任意のソースからIPレイヤビットの実際の数であります
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.
使用量と容量との間の重要な違いは、使用されたもの（L、Tは、I）は最大値ではない、むしろ、IPビットの実際の数は正しく受信される送信しました。リンクを介して送信された情報は、直接リンクのいずれかの側に取り付けられなくてもよいものソースを含む、任意の供給源によって生成することができます。加えて、これらのソースからの各情報の流れは、SとDとの間の全体的な経路内のリンクの（1からnまでの）任意の数を共有することができます
We express usage as a fraction of the overall IP-layer link capacity.
我々は、全体のIPレイヤのリンク容量の割合としての使用を発現します。
Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )
使用率（L、T、I）=（中古（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].
従って、使用は、現在使用されている容量の割合を表し、ゼロの値（意味何が使用されていない）と1（リンクを意味することは、完全に飽和である）です。 100で利用率を乗算すると、リンクの利用率が得られます。上記を使用して、我々は今、リンク上で利用可能な容量ならびにSとDとの間の経路を定義することができ、これは、本質的に[PDM]で定義であることに留意されたいです。
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:
私たちは今、IPレイヤのリンク利用率の補数とIPレイヤのリンク容量を乗じて混雑したリンク上で利用可能な容量の量を決定することができます。このように、IPレイヤ可能なリンク容量は次のようになります。
AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )
AvailCap（L、T、I）= C（L、T、I）*（1 - 使用率（L、T、I））
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.
IPレイヤ可能なリンク容量のための私達の定義を使用して、我々はその後、IPレイヤ可能なパスの容量は、単にそのパスに沿って利用可能な最小容量のリンクのものとなるように、パス全体にこの概念を拡張することができます。
AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}
AvailCap（P、T、I）=分{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.
利用可能な容量の測定は、リンク容量のそれよりも揮発性なので、我々はそれらの値が結果に与える影響の多くを持っているように、時間と時間の両方を指定することの重要性を強調する。また、測定のシーケンスは、利用可能な容量を特徴付けるためにしようとすると揮発性を相殺するのに有益であり得ます。
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.
メトリックがあるに近い「瞬間」は、より重要なことは、十分に大きい期間にわたってメトリックをサンプリングするための計画を持っていることです。そうすることによって、我々は、有効な統計的推論が測定から行うことができます。ここで明らかな落とし穴は、バイアスの原因となるようにサンプリングされます。例えば、サンプリング周波数は、基礎となる条件の周波数の倍数である状況。
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.
私たちは、簡単にパケットのハードウェアの重複が発生する可能性がパスの影響を考慮する。そのような環境では、ネットワーク経路内のノードは、パケットを複製してもよいし、先にこれらのパケットの複数の同一のコピーを受信することができます。元のパケットと複製の両方が正しく受信された送信者から発信されるように見えることができます。このように、ほとんどの一般的な形式で、重複したIPパケットは、これらの定義にカウントされます。しかし、ハードウェアの重複がパケット受信の追加の制限を追加するための「タイプP」の使用に応じてこれらの定義に影響を与えることができます。例えば、制限は、意味のあるデータの容量に関するユーザにとってより有用である可能性があるユニークな送信されたパケットをカウントします。対照的に、より一般的な、無制限のメトリックは、生の能力に関係しているユーザのために適切であり得ます。これにより、適切に範囲にユーザに任されて、ハードウェアの重複が優勢であってもよい状況で結果を解釈します。
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.
すべてのIPヘッダ及びペイロードビットは関係なく、コンテンツのカウントされなければならないようにIPカプセル化は定義に影響を与えません。しかし、異なるサイズのIPパケットは、このように、全体的なIPリンク層の容量を変更すること、データを送信するために下位層に必要なオーバーヘッドの量の変化をもたらすことができます。
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.
リンクは、ロバストヘッダ圧縮（ROHC）[RFC3095]またはV.44 [V44]として圧縮方式を用いることが起こるべきである、オリジナルのビットの一部は、リンクを介して送信されていません。しかし、IPレイヤのビットの膨張（圧縮されていない）数を数えなければなりません。
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.
また、文献ではしばしば、我々はこの文書の容量として説明したものを参照するための用語「帯域幅」をオーバーロードします。 802.11bのリンクの帯域幅を問い合わせるときたとえば、ネットワークエンジニアは、おそらく11メガビット/秒でお答えします。しかし、電気技師は、25 MHzのに答えることができ、エンドユーザーは自分の観測帯域幅は8メガビット/秒であることを伝えることがあります。これとは対照的に、用語「容量」は、オーバーロードはかなりとしてではなく、より良い実際に測定されているものを反映した適切な用語です。
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.
バルク転送能力（BTC）[RFC3148]はいくつかの基本的な方法でこの文書における定義と異なるパス能力に異なる視点を提供します。まず、BTCは、データを送信したいアプリケーションに利用可能な容量の量を測る、トランスポート層で動作します。唯一のユニークなデータは、ヘッダを意味し、測定され、再送データが計算に含まれていません。対照的に、IPレイヤー・リンク容量は、IPヘッダを含み、パケットペイロード内に含まれるデータの一意性に無関心です。 （パケットのハードウェア複製が異常は、前のセクションで対処される。）第二に、BTCは、測定値を得るために、TCPのような単一の輻輳認識トランスポート接続を利用します。結果として、BTC実装は異なるパス特性、トポロジ、および距離に強く反応します。これらの違いは、制御ループ（伝搬遅延、セグメント並べ替え、等）に影響を与えることができるので、反応を測定するために使用されるアルゴリズムにさらに依存しています。例えば、リンクは、ビットエラーの大きな期間を受ける単一のイベントを考慮する。イベントは、IP層パケットが破棄される可能性があり、そして失われたパケットは、IPレイヤのリンク容量を低減するであろう。しかし、同じイベントと後続の損失、データの再送及び潜在的に低減送信速度が得られるBTC測定のための損失の回復をトリガすることになります。したがって、BTCの測定は、この文書の定義のいずれにも該当しません。両方の技術は、ネットワークパスの特性を探索するのに有用であるが、異なる視点からのものです。
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.
この文書では、IPネットワーク内の送信元と宛先の間を移動するIPトラフィックに関する定義を指定します。これらの定義は、すべてのセキュリティ上の問題を提起していないとネットワーク・プロトコル・スイートに直接影響を持っていません。
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.
これらの定義を実装しようとするツールは、各実装に固有のセキュリティ問題を導入することができます。アクティブとパッシブの両方の測定技術は、セキュリティ、プライバシー、およびネットワークのパフォーマンスに影響を与える、悪用される可能性が。これらの定義に基づいて任意の測定技術は、測定が実行されているネットワークを保護するために必要な技術の議論を含まなければなりません。
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.
この文書では、IPネットワーク内のリンクとパスの能力に関連した量のセットを定義しました。これらの定義では、我々は可能な限り明確にすると、アカウントにリンクやパスが持つことのできる様々な特性を取るしようとしています。これらの定義の目標は、これらの定義にそれらのメトリックを関連付けるために、彼らはこれらの量を近似どれだけに関して、これらの指標を評価する能力の指標を提案している研究者を有効にすることです。
In addition, we have pointed out some key auxiliary parameters and opened a discussion of issues related to valid inferences from available capacity metrics.
また、我々はいくつかの重要な補助パラメータを指摘し、使用可能な容量指標から有効な推論に関連する問題の議論を開きました。
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.
著者は彼らの提案、コメント、レビューのためにマーク・オールマン、パトリックArlos、マット・マシス、アル・モートン、スタニスラフ・シャルノブ、およびマットZekauskasを確認したいと思います。また、この文書に彼らの議論とフィードバックのためのIETF IPPMメーリングリストのメンバーに感謝します。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[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.
ネットワーク12上の[PDM] Dovrolis、C.、ラマナサン、P.、およびD.ムーア、 "パケット分散技術と容量推定方法論"、IEEE / ACM取引（6）：963から977、2004年12月。
[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.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.
[RFC3148]マティス、M.およびM.オールマン、「実証バルク転送容量のメトリックを定義するためのフレームワーク」、RFC 3148、2001年7月。
[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44, "Data Compression Procedures", November 2000.
[V44] ITU電気通信標準化部門（ITU-T）勧告V.44、 "データ圧縮手順"、2000年11月。
Authors' Addresses
著者のアドレス
Phil Chimento JHU Applied Physics Lab 11100 Johns Hopkins Road Laurel, Maryland 20723-6099 USA
フィル・Chimento JHU応用物理研究所11100ジョンズホプキンスロードローレル、メリーランド州20723から6099 USA
Phone: +1-240-228-1743 Fax: +1-240-228-0789 EMail: Philip.Chimento@jhuapl.edu
電話：+ 1-240-228-1743ファックス：+ 1-240-228-0789 Eメール：Philip.Chimento@jhuapl.edu
Joseph Ishac NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, Ohio 44135 USA
ジョセフIshac NASAグレンリサーチセンター21000ブルックパークロード、MS 54-5クリーブランド、オハイオ州44135 USA
Phone: +1-216-433-6587 Fax: +1-216-433-8705 EMail: jishac@nasa.gov
電話：+ 1-216-433-6587ファックス：+ 1-216-433-8705 Eメール：jishac@nasa.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。