[要約] RFC 5136は、ネットワーク容量の定義に関するガイドラインであり、ネットワークの能力を評価するための方法を提供しています。その目的は、ネットワークのパフォーマンスを向上させるために、ネットワークの容量を正確に評価することです。
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.
一部のメディアでは、これらの信号の最大頻度は「容量」と考えることができます。他のメディアでは、メディア（チャネル）の信号伝送頻度と情報容量がまったく異なる場合があります。たとえば、衛星チャネルには、少数のギガヘルツのキャリア周波数がありますが、1秒あたり数百キロビットの情報キャリー容量があります。多くの場合、類似または同一の用語は、これらの異なる容量のアプリケーションを参照するために使用され、曖昧さと混乱を増し、統一された命名法の欠如により、さまざまな技術とツールを適切に構築、テスト、および使用することが困難になります。
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（無線周波数）通信は、物理媒体（AIR）が損失しているため、フォワードエラー補正を実装するためにコーディングスキームに冗長性を追加することがよくあります。これにより、情報容量がさらに低下する可能性があります。
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パフォーマンスメトリック（IPPM）フレームワークドキュメント[RFC2330]にあるリンクとパスの概念を広げて、IP認識なしにIP容量に影響を与える可能性のあるネットワークデバイスを含める必要があります。たとえば、さまざまな速度でポートを操作できるイーサネットスイッチを検討してください。
We define nodes as hosts, routers, Ethernet switches, or any other device where the input and output links can have different characteristics. A link is a connection between two of these network devices or nodes. We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. Furthermore, we define a link L as a special case where the path length is one.
ノードをホスト、ルーター、イーサネットスイッチ、または入力リンクと出力リンクに異なる特性を持つことができる他のデバイスとして定義します。リンクは、これらの2つのネットワークデバイスまたはノード間の接続です。次に、長さnのパスPを一連のリンク（L1、L2、...、LN）として定義し、一連のノード（N1、N2、...、NN 1）を接続します。ソースSと宛先Dは、それぞれN1とNN 1に存在します。さらに、リンクLをパスの長さが1つある特別なケースとして定義します。
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 Mbit/sです。これは、ネットワーク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倍として定義されます。
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から始まる宛先Dで記録され、時刻t Iで終了します。定義は平均に基づいているため、2つのタイムパラメーター、tおよびiは、次の値のレポートまたは推定に添付する必要があります。彼らが意味のあるままであるように注文してください。間隔の境界点が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リンク容量が減少します。IPPMフレームワークに従って、IPヘッダーの検証に失敗するパケットを破棄する必要があります。具体的には、[RFC1812]の要件、セクション5.2.2、IPヘッダー検証に関する確認する必要があります。これには、有効な長さ、チェックサム、およびバージョンフィールドを含みます。
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」は、メトリックによって参照されるパケットフローの明示的な仕様となる可能性のあるプレースホルダーであるか、集約を含む非常に緩い仕様である可能性があります。これらの定義の「タイプP」指定を使用して、2つのことを強調するために使用します。まず、容量測定の値は定義で参照されるフローのタイプに依存することです。これは、ネットワークがマーキングと分類に基づいて（キューイングとスケジューリングの点で）異なる方法でパケットを扱う可能性があるためです。また、ネットワークは、パケットの種類またはフロータイプに基づいてフローバランスを任意に決定する場合があり、それにより容量の測定に影響します。第二に、容量の測定は、参照パケットのタイプだけでなく、利子の流れがパスのリンクを共有する「母集団」のパケットのタイプにも依存します。
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.
このすべては、測定に対する2つの異なるアプローチを示しています。1つは、幅広いパケットタイプを使用して容量を測定することであり、「タイプP」を可能な限り汎用に設定する必要があることを示唆しています。2つ目は、特定の関心のあるフローの種類に狭く焦点を当てることです。これは、「タイプP」が非常に具体的で狭く定義されるべきであることを示唆しています。最初のアプローチは、プロバイダーにとって興味深いものである可能性が高く、2番目はアプリケーションユーザーになります。
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.
実際的な問題として、一部のプロバイダーは、特定の特性を持つパケットを他のパケットとは異なる方法で扱う可能性があることに注意する必要があります。たとえば、アクセス制御リスト、ルーティングポリシー、およびその他のメカニズムを使用して、さまざまなルートを介して特定のIPオプションを使用してICMPパケットまたは転送パケットをフィルタリングすることができます。容量測定ツールがこれらの特別なパケットを使用し、「タイプ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.
IP層リンク容量c（l、t、i）を定義し、ソースSから送信し、間隔中にリンクl上で宛先Dによって正しく受信される可能性のあるIP層ビットの最大数であると定義します。[T、T I]、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)}
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の平均使用（L、T、I）は、任意のソースからの実際のIPレイヤービットの数であり、間隔[t、t i]の間にリンクlで正しく受信され、IをIで割ったものです。
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) )
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) )
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)}
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 Mbit/sで回答する可能性があります。ただし、電気エンジニアは25 MHzで回答する場合があり、エンドユーザーは、観測された帯域幅が8 Mbit/sであることを伝える場合があります。対照的に、「容量」という用語は非常に過負荷ではなく、実際に測定されているものをよりよく反映する適切な用語です。
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.
著者は、マーク・オールマン、パトリック・アルロス、マット・マティス、アル・モートン、スタニスラフ・シャルノフ、マット・ゼカウスカスの提案、コメント、レビューを認めたいと考えています。また、このドキュメントに関する議論とフィードバックについて、IETF IPPMメーリングリストのメンバーに感謝します。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「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.
[PDM] Dovrolis、C.、Ramanathan、P。、およびD. Moore、「パケット分散技術と容量推定方法」、ネットワーキングに関するIEEE/ACMトランザクション12（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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（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] Mathis、M。およびM. Allman、「経験的バルク容量メトリックを定義するためのフレームワーク」、RFC 3148、2001年7月。
[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44, "Data Compression Procedures", November 2000.
[V44] ITU Telecommunication Standardization Sector（ITU-T）推奨V.44、「データ圧縮手順」、2000年11月。
Authors' Addresses
著者のアドレス
Phil Chimento JHU Applied Physics Lab 11100 Johns Hopkins Road Laurel, Maryland 20723-6099 USA
Phil Chento Jhu Applied Physics Lab 11100 Johns Hopkins Road Laurel、Maryland 20723-6099 USA
Phone: +1-240-228-1743
Fax: +1-240-228-0789
EMail: Philip.Chimento@jhuapl.edu
Joseph Ishac NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, Ohio 44135 USA
ジョセフイシャックナサグレンリサーチセンター21000ブルックパークロード、MS 54-5オハイオ州クリーブランド44135 USA
Phone: +1-216-433-6587
Fax: +1-216-433-8705
EMail: jishac@nasa.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。