RFC5136 日本語訳

Network Working Group                                        P. Chimento
Request for Comments: 5136                       JHU Applied Physics Lab
Category: Informational                                         J. Ishac
                                              NASA Glenn Research Center
                                                           February 2008

Chimentoがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5136年のJHU応用物理学研究室カテゴリ: 情報のJ.Ishac NASAグレンリサーチセンタ2008年2月

                       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交通に関連する用語の'容量'と'利用可能なCapacity'に定義を提供します。 そうすることによって、私たちは、現在の、そして、将来のさまざまの見積りのテクニックの議論と分析に一般的な枠組みを提供することを望んでいます。

Chimento & Ishac             Informational                      [Page 1]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[1ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 リンクと経路. . . . . . . . . . . . . . . . . . . . . 4 2.2。 定義: 名目上の物理的なリンク容量. . . . . . . . 4 2.3。 IP層. . . . . . . . . . . . . . . . . 5 2.3の.1における容量。 定義: ビット. . . . . . . . . . . . . . 5 2.3をIP層にしてください。.1 .1。 標準、正しく、.2にパケット. . . . . . . 5 2.3.1を形成します。 Pパケット. . . . . . . . . . . . . . . . . . 6 2.3.2をタイプしてください。 定義: IPタイプPは容量. . . . . . . . . 7 2.3.3をリンクします。 定義: IPタイプP経路容量. . . . . . . . . 7 2.3.4。 定義: IPタイプPは用法. . . . . . . . . . . 7 2.3.5をリンクします。 定義: IPタイプPは利用. . . . . . . . 8 2.3.6をリンクします。 定義: 手があいているIPタイプPは容量. . . . 8 2.3.7をリンクします。 定義: IPタイプPの有効な経路容量. . . . 8 3。 議論. . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1。 時間と標本抽出. . . . . . . . . . . . . . . . . . . . 9 3.2。 ハードウェアは.93.3をコピーします。 他の可能性は.93.4を因数分解します。 文学. . . . . . . . . . . . . 10 3.5の一般的な用語。 バルク転送容量(BTC). . . . . . . . 10 4との比較。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 5。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 11 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 12

Chimento & Ishac             Informational                      [Page 2]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[2ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

1.  Introduction

1. 序論

   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.

リンクかネットワーク経路の容量を測定するのは、簡単に聞こえるタスクですが、ほんとうは、かなり複雑である場合があります。 どんな物理的な媒体も、情報がコード化されるのを必要とします、そして、媒体に頼っていて、1つの位置からもう1つの位置まで物理的に送信される信号の系列に情報を変換するために、様々な計画があります。

   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秒あたり数100のキロビットだけの情報伝達能力がいくつかのキャリヤー頻度にあるかもしれません。 しばしば同様の、または、同じ用語は容量のこれらの異なったアプリケーション、あいまいさと混乱との一助となることについて言及するのに使用されて、統一された用語体系の不足で適切に様々なテクニックとツールを組立てて、検査して、使用するのは難しくなります。

   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に、物理的な層の縁どりと通常High-レベルData Link Control(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チャンネルは容量において異なるかもしれません。

Chimento & Ishac             Informational                      [Page 3]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[3ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

   The important points to derive from this discussion are these: First,
   capacity is only meaningful when defined relative to a given protocol
   layer in the network.  It is meaningless to speak of "link" capacity
   without qualifying exactly what is meant.  Second, capacity is not
   necessarily fixed, and consequently, a single measure of capacity at
   any layer may in fact provide a skewed picture (either optimistic or
   pessimistic) of what is actually available.

この議論から引き出す重要なポイントはこれらです: まず最初に、ネットワークにおける与えられたプロトコル層に比例して定義されると、容量は重要であるだけです。 まさに意味されることに資格を与えないで「リンク」容量について話すのは無意味です。 2番目に、容量は必ず固定されるというわけではありません、そして、その結果、事実上、どんな層の容量のただ一つの基準も実際に利用可能なことにおける(楽観的であるか悲観的)の歪曲された絵を提供するかもしれません。

2.  Definitions

2. 定義

   In this section, we specify definitions for capacity.  We begin by
   first defining "link" and "path" clearly, and then we define a
   baseline capacity that is simply tied to the physical properties of
   the link.

このセクションでは、私たちは容量のための定義を指定します。 私たちは最初に明確に「リンク」と「経路」を定義することによって、始めます、そして、次に、単にリンクの物理的性質に結ばれる基線容量を定義します。

2.1.  Links and Paths

2.1. リンクと経路

   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パフォーマンスMetrics(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.

私たちはホスト、ルータ、イーサネットスイッチ、または入出力リンクが異なった特性を持つことができるいかなる他の装置ともノードを定義します。 リンクはこれらのネットワーク装置か2つのノードの間の関係です。 そして、私たちは、ノード(N1、N2、…、Nn+1)の系列を接続しながら、一連のリンク(L1、L2、…、Ln)と長さnの経路Pを定義します。 ソースSと目的地Dは+1に、それぞれN1とNnに住んでいます。 その上、私たちは特殊なものとして経路の長さが1であるところでリンクLを定義します。

2.2.  Definition: Nominal Physical Link Capacity

2.2. 定義: 名目上の物理的なリンク容量

   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.

名目上のPhysical Link Capacity(NomCap(L))はリンクLが支持できる理論上の最大のデータ量です。 例えば、OC-3リンクは155.520ができるでしょう。メガビット/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)の値は本書では提示された他の定義に影響を及ぼしません。 代わりに、それはそれらの値で上限を提供します。

Chimento & Ishac             Informational                      [Page 4]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[4ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

2.3.  Capacity at the IP Layer

2.3. IP層の容量

   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-層のビット」で残っている定義をすべて与えます。

2.3.1.  Definition: IP-layer Bits

2.3.1. 定義: 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パケットの八重奏の数が受けた8(8)回と定義されます、IPヘッダーの最初の八重奏からIPパケットペイロードの最後の八重奏まで、包括的です。

   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.Howeverへのパケット到着の間に下がるのが必要でなく、パケットの中に下がる境界はそれらが落下するパケットを無効にするでしょう。 明確に、間隔中に含まれている部分的なパケットからのデータは数えられないでしょう。 これは人工的に値のいくつかに偏るかもしれません、間隔の長さとその間隔の間に受け取られたデータ量によって。 私たちは次のセクションの正しく受信されたデータを構成することについて詳しく説明します。

2.3.1.1.  Standard or Correctly Formed Packets

2.3.1.1. 標準の、または、正しく形成されたパケット

   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でそのような規格で形成されたパケットのための1セットの評価基準を推薦します。 しかしながら、それはこのドキュメントによる使用に不十分です。 したがって、私たちは[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

まず最初に、IPの下の層で間違って、適切にIP層に通過できないデータを数えてはいけません。 例えば、無線のメディアには、ワイヤードなメディアよりかなり大きい誤り率がしばしばあります、IPリンク容量の減少をもたらして。 IPPM枠組み、IPの合法化に失敗するパケットに従って

Chimento & Ishac             Informational                      [Page 5]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[5ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

   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.

ヘッダーを捨てなければなりません。 明確に[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断片を数えなければなりません。 IP断片を捨てて、IPPM枠組みはこの領域で異なります。

   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パケットも含まなければなりません。

2.3.1.2.  Type P Packets

2.3.1.2. Pパケットをタイプしてください。

   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」パケットについて言及します。 RFC2330、セクション13で定義されるように、「タイプP」はメートル法によって参照をつけられるパケット流れの明白な仕様であるかもしれないことのためのプレースホルダであるかそれが集合を包含する非常にゆるい仕様であるかもしれません。 私たちは2つのことを強調するのにこれらの定義における「タイプ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つの異なるアプローチを示します: 人はパケットタイプの広いスペクトルを使用することで容量を測定することになっています、「タイプP」が一般的な可能な同じくらいセットであると示唆して。 2番目は特別に「タイプP」が非常に特定で辛うじて定義されているべきであると示唆する関心の流れのタイプに辛うじて焦点を合わせることです。 最初のアプローチは興味があるプロバイダー、アプリケーションユーザへの秒の傾向があります。

Chimento & Ishac             Informational                      [Page 6]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[6ページ]のRFC5136は2008年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」名称に含まれているなら、ツールはそれが測定することを意図した経路を測定していないかもしれません。 ツール作者、およびユーザは彼らのサービスプロバイダーにこのポイントについて問い合わせたがっているかもしれません。

2.3.2.  Definition: IP-type-P Link Capacity

2.3.2. 定義: 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.

私たちはIP-層のリンク容量、Iが間隔[T、T+I]の間のソースSから送信して、目的地Dで正しくリンクLの上に受け取ることができるIP-層のビットの最大数になるように割られたC(L、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パケットは異なった影響を容量に与えるかもしれません、処理される交通の量かタイプに頼っていて。

2.3.3.  Definition: IP-type-P Path Capacity

2.3.3. 定義: IPタイプP経路容量

   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..nC(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-層のビットの数を指定します。 それはソースと目的地の間の交通に有効な全能力を表します。 混雑しているリンクのにおける使用について、どのくらいの容量があるかを決定するのは潜在的にはるかに役に立ちます。 しかしながら、有効な容量を定義するために、私たちは、最初に、どのくらいが使用されているかを指定しなければなりません。

2.3.4.  Definition: IP-type-P Link Usage

2.3.4. 定義: IPタイプPリンク用法

   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の平均した使用法(Used(L、T、I))はどんなソースからのIP-層のビットの実数です、Iが割られた間隔[T、T+I]の間、リンクLの上に正しく受け取られています。

Chimento & Ishac             Informational                      [Page 7]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[7ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

   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.

用法と容量の大切な区別はUsed(L、T、I)が最大数ではなく、むしろビットが送った正しく受け取られるIPの実数であるということです。 リンクの向こう側に伝えられた情報はどんなソースによっても発生できます、面があるために直接添付されないかもしれないリンクのそれらの源を含んでいて。 さらに、これらのソースからのそれぞれの情報流動はSとDの間の総合的な経路でどんな数(1〜nまでの)のリンクも共有するかもしれません。

2.3.5.  Definition: IP-type-P Link Utilization

2.3.5. 定義: IPタイプPリンク利用

   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) )

Util(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.Noteの間の経路と同様にリンクの上に有効な容量を定義できます。これは本質的には[PDM]への定義です。

2.3.6.  Definition: IP-type-P Available Link Capacity

2.3.6. 定義: IPタイプPの有効なリンク容量

   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--Util(L、T、I))

2.3.7.  Definition: IP-type-P Available Path Capacity

2.3.7. 定義: IPタイプPの有効な経路容量

   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..nAvailCap(Ln、T、I)

   Since measurements of available capacity are more volatile than that
   of link capacity, we stress the importance that both the time and
   interval be specified as their values have a great deal of influence
   on the results.  In addition, a sequence of measurements may be
   beneficial in offsetting the volatility when attempting to
   characterize available capacity.

有効な容量の測定値がリンク容量のものより不安定であるので、それらの値が大きな影響を結果に与えるとき、私たちは指定されていた状態で時間と間隔の両方がある重要性を強調します。 さらに、測定値の系列は有効な容量を特徴付けるのを試みるとき不安定さを相殺するのにおいて有益であるかもしれません。

Chimento & Ishac             Informational                      [Page 8]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[8ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

3.  Discussion

3. 議論

3.1.  Time and Sampling

3.1. 時間と標本抽出

   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.

「瞬時に起こっている」aへのメートル法のクローザーはそうです、より重要。それが十分大きい期間にわたるメートル法を抽出しながら考えがあることになっている そうすることによって、私たちは測定値から有効な統計的推測をさせます。 ここの明白な落とし穴はバイアスを引き起こす道で標本抽出であることです。 例えば、サンプリング周波数が基礎症状の頻度の倍数である状況。

3.2.  Hardware Duplicates

3.2. ハードウェア写し

   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」の使用によるこれらの定義に影響できます。 例えば、重要なデータでは唯一送られたパケットを数えるためには唯一の制限は容量に関するユーザにより役に立つかもしれません。 対照的に、 より一般的で、無制限である、メートル法、生の容量に関するユーザに適当であるかもしれません。 したがって、適切にハードウェア写しが一般的であるかもしれない状況における結果を見て、解釈するのは、ユーザ次第です。

3.3.  Other Potential Factors

3.3. 他の潜在的要素

   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リンクレイヤ容量を変更します。

Chimento & Ishac             Informational                      [Page 9]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[9ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

   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.

リンクはたまたまRObust Header Compression(ROHC)[RFC3095]かV.44などの圧縮技術を使うはずです。[V44]、元の数ビットはリンクの向こう側に伝えられません。 しかしながら、IP-層のビットの充満している(圧縮されない)数は数えられるべきです。

3.4.  Common Terminology in Literature

3.4. 文学の一般的な用語

   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メガビット/sでおそらく答えるでしょう。 しかしながら、電気技術者は25MHzで答えるかもしれません、そして、エンドユーザは彼の観測された帯域幅が8メガビット/sであるとあなたに言うかもしれません。 対照的に、「容量」という用語は、全く積みすぎられるようにであるというわけではない実際に測定されているものを反映するほうがよい適切な用語です。

3.5.  Comparison to Bulk Transfer Capacity (BTC)

3.5. バルク転送容量との比較(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

大量Transfer Capacity(BTC)[RFC3148]は本書ではいくつかの基本的な方法で定義と異なっている経路容量で異なった見解を提供します。 まず最初に、BTCはトランスポート層で作動します、データを送りたがっているアプリケーションに有効な容量の量を測って。 意味ヘッダー、ユニークなデータは測定されるだけです、そして、再送されたデータは計算に含まれていません。 対照的に、IP-層のリンク容量は、IPヘッダーを含めて、パケットペイロードの中に含まれたデータのユニークさに無関心です。 (パケットのハードウェア複製は前項で記述された異常です。) 2番目に、BTCは、測定値を得るのにTCPなどの単独の混雑意識している輸送接続を利用します。 その結果、BTC実現は強く異なった経路特性、topologies、および距離に反応します。 これらの違いがコントロールループ(伝播遅延、セグメント再命令など)に影響できるので、測定値において、反応はアルゴリズム就職にさらに依存しています。 例えば、リンクが噛み付いている誤りの大きい持続時間を受けるところで単一の出来事を考えてください。 出来事でIP-層のパケットを捨てることができました、そして、無くなっているパケットはIP-層のリンク容量を減少させるでしょう。 しかしながら、同じ出来事とその後の損失は損失回復の引き金となるでしょう。

Chimento & Ishac             Informational                     [Page 10]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[10ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

   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測定と潜在的に減少している送付は評価します。 したがって、BTCの測定は本書では定義のいずれにも対応していません。 両方のテクニックはネットワーク経路の特性について調査することが、異なった見解から役に立ちます。

4.  Security Considerations

4. セキュリティ問題

   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.

これらの定義を実行するのを試みるツールは各実現に特定の安全保障問題を紹介するかもしれません。 ネットワークのセキュリティ、プライバシー、および性能に影響を与えて、アクティブなものと同様に受け身の測定技術を乱用できます。 これらの定義に基づくどんな測定技術も測定が実行されているネットワークを保護するのに必要であるテクニックの議論を含まなければなりません。

5.  Conclusion

5. 結論

   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ネットワークでリンクと経路の容量に関連する1セットの量を定義しました。 これらの定義では、私たちは、できるだけ明確であり、リンクと経路が持つことができる様々な特性を考慮に入れようとしました。 これらの定義の目標は容量測定基準を提案する研究者がこれらの定義にそれらの測定基準に関連して、それらがこれらの量にどれくらいよく近似するかに関してそれらの測定基準を評価するのを可能にすることです。

   In addition, we have pointed out some key auxiliary parameters and
   opened a discussion of issues related to valid inferences from
   available capacity metrics.

さらに、私たちは、利用可能な容量測定基準からいくつかの主要な補助のパラメタを指摘して、有効な推論に関連する問題の議論を開きました。

6.  Acknowledgments

6. 承認

   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、マット・マシス、アル・モートン、スタニスラフShalunov、およびマットZekauskasを承認したがっています。 また、私たちはこのドキュメントの彼らの議論とフィードバックについてIETF IPPM Mailing Listのメンバーに感謝します。

Chimento & Ishac             Informational                     [Page 11]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[11ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。

   [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パフォーマンス測定基準のための枠組み」RFC2330)は1998がそうするかもしれません。

7.2.  Informative References

7.2. 有益な参照

   [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.ムーア、および「パケットディアスポラのテクニックと容量見積り方法論」、ネットワーク12(6)におけるIEEE/ACM取引: 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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日

   [RFC3148]  Mathis, M. and M. Allman, "A Framework for Defining
              Empirical Bulk Transfer Capacity Metrics", RFC 3148,
              July 2001.

[RFC3148] マシスとM.とM.オールマン、「実証的なバルク転送容量測定基準を定義するための枠組み」、RFC3148、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月。

Chimento & Ishac             Informational                     [Page 12]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[12ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

Authors' Addresses

作者のアドレス

   Phil Chimento
   JHU Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, Maryland  20723-6099
   USA

フィルChimento JHU応用物理学研究室11100のジョーンズ・ホプキン・Roadメリーランド20723-6099ローレル(米国)

   Phone: +1-240-228-1743
   Fax:   +1-240-228-0789
   EMail: Philip.Chimento@jhuapl.edu

以下に電話をしてください。 +1-240-228-1743 Fax: +1-240-228-0789 メールしてください: Philip.Chimento@jhuapl.edu

   Joseph Ishac
   NASA Glenn Research Center
   21000 Brookpark Road, MS 54-5
   Cleveland, Ohio  44135
   USA

ジョゼフIshac NASAグレンリサーチセンタ21000Brookpark道路、MS54-5クリーブランド、オハイオ44135米国

   Phone: +1-216-433-6587
   Fax:   +1-216-433-8705
   EMail: jishac@nasa.gov

以下に電話をしてください。 +1-216-433-6587 Fax: +1-216-433-8705 メールしてください: jishac@nasa.gov

Chimento & Ishac             Informational                     [Page 13]

RFC 5136                    Network Capacity               February 2008

Chimento&Ishacの情報[13ページ]のRFC5136は2008年2月に容量をネットワークでつなぎます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Chimento & Ishac             Informational                     [Page 14]

Chimento&Ishac情報です。[14ページ]