Network Working Group D. Newman
Request for Comments: 4814 Network Test
Category: Informational T. Player
Spirent Communications
March 2007
Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
ハッシュと詰め物：ネットワークデバイスのベンチマークで見落とさ要因
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic.
テストエンジニアが意図した負荷、パケット長、試験時間、およびトラフィックの方向を含む所定の測定に影響を与えるすべての要因を、宣言するために痛みを取ります。しかし、現在のベンチマーク実施は、試験結果に大きな影響を持つ2つの要因を一望します。まず、既存の方法論は、これらのフィールドは、試験結果に影響を与える可能性にもかかわらず、アドレスやその他の試験トラフィックの内容の報告を必要としません。第二に、いくつかのリンク層技術によって試験トラフィックに挿入された「もの」のビットとバイトが順番にテスト結果に影響を与え重大な変数のオーバーヘッドを、追加します。この文書では、これらの要因の影響を説明します。テストトラフィックの内容のためのガイドラインを推奨しています。そしてテストトラフィックにbit-およびバイトスタッフィングの確率を決定するための数式を提供しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Considerations . . . . . . . . . . . . . . . . . . . . 4
3.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Randomness . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Content Variations . . . . . . . . . . . . . . . . . . 5
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
4.2. IEEE 802 MAC Addresses . . . . . . . . . . . . . . . . . . 7
4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 8
4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 9
4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 9
4.5. Transport-Layer Addressing . . . . . . . . . . . . . . . . 10
4.6. Application-Layer Patterns . . . . . . . . . . . . . . . . 10
5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 11
5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 11
5.2. PPP Bit-Stuffing . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 14
5.2.2. Bit-Stuffing for Finite Strings . . . . . . . . . . . 15
5.2.3. Applied Bit-Stuffing . . . . . . . . . . . . . . . . . 16
5.3. POS Byte-Stuffing . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 17
5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 17
5.3.3. Applied Byte-Stuffing . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Appendix B. Proof of Formula for Finite Bit-Stuffing . . . . . . 20
Appendix C. Explicit Calculation of Bit-Stuffing Overhead for
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix D. Explicit Calculation of Bit-Stuffing Overhead for
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix E. Terminology . . . . . . . . . . . . . . . . . . . . . 24
Experience in benchmarking networking devices suggests that the contents of test traffic can have a profound impact on test results. For example, some devices may forward randomly addressed traffic without loss, but drop significant numbers of packets when offered packets containing nonrandom addresses.
ベンチマークネットワーキングデバイスでの経験は、試験トラフィックの内容は、試験結果に大きな影響を持つことができることを示唆しています。例えば、一部のデバイスは、ランダムに損失することなく、トラフィックに対処して転送しますが、非ランダムアドレスを含むパケットを提供した際に、パケットのかなりの数を低下することがあります。
Methodologies such as [RFC2544] and [RFC2889] do not require any declaration of packet contents. These methodologies do require the declaration of test parameters such as traffic distribution and traffic orientation, and yet packet contents can have at least as great an impact on test results as the other factors. Variations in packet contents also can lead to non-repeatability of test results: Two individuals may follow methodology procedures to the letter, and still obtain very different results.
このような[RFC2544]及び[RFC2889]などの方法論は、パケットの内容のいずれかの宣言を必要としません。これらの方法は、トラフィック分布やトラフィックの向きなどの試験パラメータの宣言を必要としない、しかもパケットの内容は、他の因子のような試験結果に少なくともとして大きな影響を与えることができます。パケットの内容の変化は、また、テスト結果の非再現性につながることができます：二人は手紙に方法論の手順に従ってください、そしてまだ非常に異なる結果を得ることができます。
A related issue is the insertion of stuff bits or bytes by link-layer technologies using PPP with High-Level Data Link Control (HDLC)-like framing. This stuffing is done to ensure sequences in test traffic will not be confused with control characters.
関連する問題は、ハイレベルデータリンク制御（HDLC）様のフレーミングでPPPを使用してリンク層技術により、スタッフビットまたはバイトの挿入です。この詰め物は、テストトラフィックのシーケンスは制御文字と混同されることはありません保証するために行われます。
Stuffing adds significant and variable overhead. Currently there is no standard method for determining the probability that stuffing will occur for a given pattern, and thus no way to determine what impact stuffing will have on test results.
スタッフィングは、重要な変数のオーバーヘッドが追加されます。現在そのスタッフィングが所定のパターンで発生する確率を決定するための標準的な方法、及び試験結果になりますどのような影響スタッフィングを決定することはできません。
This document covers two areas. First, we discuss strategies for dealing with randomness and nonrandomness in test traffic. Second, we present formulas to determine the probability of bit- and byte-stuffing on Point-to-Point Protocol (PPP) and Packet over SONET (POS) circuits. In both areas, we provide recommendations for obtaining better repeatability in test results.
この文書では、二つの領域をカバーしています。まず、我々はテストトラフィックにランダムとnonrandomnessに対処するための戦略を議論します。第二に、我々はポイントツーポイントプロトコル（PPP）およびSONETを介してパケット（POS）回線上のbit-およびバイトスタッフィングの確率を決定するための式を提示します。両方の領域では、我々は、テスト結果により良い再現性を得るための推奨事項を提供します。
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, using dedicated address space.
このメモで説明されているような活動をベンチマーキングは、専用のアドレス空間を使用して、実験室環境で制御刺激を使用して技術の特性に限定されています。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network, or misroute traffic to the test management network.
ベンチマークネットワークトポロジは、独立したテストのセットアップになり、テスト管理ネットワークへの生産ネットワーク、またはmisrouteトラフィックにテストトラフィックを転送することができるデバイスに接続しないでください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Repeatability is a desirable trait in benchmarking, but it can be an elusive goal. It is a common but mistaken belief that test results can always be recreated provided the device under test and test instrument are configured identically for each test iteration. In fact, even identical configurations may introduce some variations in test traffic, such as changes in timestamps, TCP sequence numbers, or other common phenomena.
再現性は、ベンチマークでは望ましい特性であるが、それはとらえどころのない目標ですることができます。試験結果が必ずしも各テスト反復に対して同一に構成されている試験と試験装置の下にデバイスを提供再作成することができる共通だが誤った信念です。実際には、でも、同一の構成には、このようなタイムスタンプの変更、TCPシーケンス番号、または他の一般的な現象として、テストトラフィックのいくつかのバリエーションを、導入することができます。
While this variability does not necessarily invalidate test results, it is important to recognize the existing variation. Exact bit-for-bit repeatability of test traffic is a hard problem. A simpler approach is to acknowledge that some variation exists, characterize that variation, and describe it when analyzing test results.
この変動は必ずしもテストの結果が無効になることはありませんが、既存の変化を認識することが重要です。テストトラフィックの正確なビットごとの再現は難しい問題です。単純なアプローチは、いくつかのバリエーションが存在することを認めること変化を特徴付ける、およびテスト結果を分析する際にそれを記述することです。
Another issue related to repeatability is the avoidance of randomness in test traffic. For example, benchmarking experience with some IEEE 802.11 devices suggests that nonrandom media access control (MAC) and IP addresses must be used across multiple trials. Although this would seem to contradict some recommendations made in this document, in fact either nonrandom or pseudorandom patterns may be more desirable depending on the test setup. There are also situations where it may be desirable to use combinations of the two, for example by generating pseudorandom traffic patterns for one test trial and then re-using the same pattern across all trials. The keywords in this document are RECOMMENDs and not MUSTs with regard to the use of pseudorandom test traffic patterns.
再現性に関連する別の問題は、テストトラフィックのランダム性の回避です。例えば、いくつかのIEEE 802.11デバイスとの経験をベンチマークすることは非ランダムメディアアクセス制御（MAC）とIPアドレスが複数の試行にまたがって使用しなければならないことを示唆しています。これは、この文書で行われたいくつかの勧告と矛盾するように見えるだろうが、実際には非ランダムまたは擬似いずれかのパターンは、テスト・セットアップに応じてより望ましいです。次に一つのテスト試験及びすべての試験を横切る再使用して、同じパターンのための擬似ランダムトラフィックパターンを生成することによって、例えば、両者の組み合わせを使用することが望ましい状況もあります。この文書に記載されているキーワードは、擬似ランダムテストトラフィックパターンの使用に関してマストを推奨していません。
Note also that this discussion covers only repeatability, which is concerned with variability of test results from trial to trial on the same test bed. A separate concern is reproducibility, which refers to the precision of test results obtained from different test beds. Clearly, reproducibility across multiple test beds requires repeatability on a single test bed.
この議論は、同じテストベッド上で試験に試験からの試験結果の変動性に関係しているだけ再現性をカバーすることにも留意されたいです。別の懸念は、異なるテストベッドから得られた試験結果の精度を指す再現性です。明らかに、複数のテストベッドを横切って再現性は、単一のテストベッド上の再現性を必要とします。
This document recommends the use of pseudorandom patterns in test traffic under controlled lab conditions. The rand() functions available in many programming languages produce output that is pseudorandom rather than truly random. Pseudorandom patterns are sufficient for the recommendations given in this document, provided they produce output that is uniformly distributed across the pattern space.
この文書では、制御された実験室条件下でテストトラフィックの擬似ランダムパターンを使用することを推奨しています。多くのプログラミング言語で利用できるランド（）関数は、真にランダムではなく、擬似ランダム出力を生成します。疑似ランダムパターンは、それらが一様にパターンスペースに分散された出力を生成設け、この文書で指定された推奨事項については十分です。
Specifically, for any random bit pattern of length L, the probability of generating that specific pattern SHOULD equal 1 over 2 to the Lth power.
具体的には、長さLの任意のランダムなビットパターンのために、その特定のパターンを生成する確率は、第Lのパワーに2上に1に等しくなければなりません。
The contents of test traffic can have a significant impact on metrics such as throughput, jitter, latency, and loss. For example, many network devices feed addresses into a hashing algorithm to determine upon which path to forward a given packet.
試験トラフィックの内容は、スループット、ジッタ、待ち時間、損失などの指標に大きな影響を与えることができます。例えば、多くのネットワークデバイスは、与えられたパケットを転送するパスの際に決定するために、ハッシュアルゴリズムにアドレスを供給する。
Consider the simple case of an Ethernet switch with eight network processors (NPs) in its switching fabric:
そのスイッチングファブリックの8つのネットワークプロセッサ（NPS）とイーサネットスイッチの簡単な場合を考えます。
ingress
||
\/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ___ ___ ___ ___ ___ ___ ___ ___ |
|| | | | | | | | | | | | | | | | |
||NP0| |NP1| |NP2| |NP3| |NP4| |NP5| |NP6| |NP7| |
||___| |___| |___| |___| |___| |___| |___| |___| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||
\/
egress
To assign incoming traffic to the various NPs, suppose a hashing algorithm performs an exclusive-or (XOR) operation on the least significant 3 bits of the source and destination MAC addresses in each frame. (This is an actual example the authors have observed in multiple devices from multiple manufacturers.)
種々のNPへの着信トラフィックを割り当てるには、ハッシュアルゴリズムは、各フレームの送信元および宛先MACアドレスの最下位3ビットに排他的論理和（XOR）演算を実行すると仮定する。 （これは、著者が複数のメーカーからの複数のデバイスで観察された実際の例です。）
In theory, a random distribution of source and destination MAC addresses should result in traffic being uniformly distributed across all eight NPs. (Instances of the term "random" in this document refer to a random uniform distribution across a given address space. Section 3.2 describes random uniform distributions in more detail.) In practice, the actual outcome of the hash (and thus any test results) will be very different depending on the degree of randomness in test traffic.
理論的には、送信元と宛先MACアドレスのランダムな分布が一様にすべての8つのNPに分散されたトラフィックを生じるはずです。 （この文書における用語のインスタンス「ランダム」は、所与のアドレス空間を横切ってランダムな一様分布を指す。セクション3.2でより詳細にランダムに均一な分布を記載している。）実際には、ハッシュの実際の結果（したがって、任意の試験結果）テストトラフィックのランダム性の度合いに応じて非常に異なるものになります。
Suppose the traffic is nonrandom so that every interface of the test instrument uses this pattern in its source MAC addresses:
テスト機器のすべてのインターフェイスは、その送信元MACアドレスでこのパターンを使用するように、トラフィックが非ランダムであると仮定します。
00:00:PP:00:00:01
00：00：PP：00：00：01
where PP is the source interface number of the test instrument.
PPは、試験機器のソースインタフェース数です。
In this case, the least significant 3 bits of every source and destination MAC address are 001, regardless of interface number. Thus, the outcome of the XOR operation will always be 0, given the same three least significant bits:
この場合、すべての送信元および宛先MACアドレスの最下位3ビットにかかわらず、インターフェース番号、001です。したがって、XOR演算の結果は常に同じ3つの最下位ビットを与え、0になります。
001 ^ 001 = 000
００１ ＾ ００１ ＝ ０００
Thus, the switch will assign all traffic to NP0, leaving the other seven NPs idle. Given a heavy enough load, NP0 and the switch will become congested, even though seven other NPs are available. At most, this device will be able to utilize approximately 12.5 percent of its total capacity, with the remaining 87.5 percent of capacity unused.
このように、スイッチはアイドル他の7つのNPを残し、NP0へのすべてのトラフィックを割り当てます。重い十分な負荷を与え、NP0とスイッチが7つの他のNPが利用可能であっても、混雑になります。せいぜい、このデバイスは、未使用の容量の残りの87.5パーセントと、その総容量の約12.5％を利用することができるであろう。
Now consider the same example with randomly distributed addresses. In this case, the test instrument offers traffic using MAC addresses with this pattern:
今、ランダムに分散したアドレスと同じ例を考えてみます。この場合、試験装置は、このパターンでMACアドレスを使用してトラフィックを提供しています：
00:00:PP:00:00:RR
00：00：PP：00：00：RR
where PP is the source interface number of the test instrument and RR is a pseudorandom number. In this case, there should be an equal probability of the least significant 3 bits of the MAC address having any value from 000 to 111 inclusive. Thus, the outcome of XOR operations should be equally distributed from 0 to 7, and distribution across NPs should also be equal (at least for this particular 3-bit hashing algorithm). Absent other impediments, the device should be able to utilize 100 percent of available capacity.
PPは、試験機器のソースインタフェース番号であり、RRは、擬似乱数です。この場合には、000から包括111に任意の値を有するMACアドレスの最下位3ビットの等しい確率があるべきです。したがって、XOR演算の結果は、同様に0から7に分配されなければならない、とのNP横切って分布も（少なくともこの特定の3ビットのハッシュアルゴリズムのために）等しくなければなりません。存在しない他の障害は、デバイスが利用可能な容量の100％を利用することができなければなりません。
This simple example presumes knowledge on the tester's part of the hashing algorithm used by the device under test. Knowledge of such algorithms is not always possible beforehand, and in any event violates the "black box" spirit of many documents produced by the IETF Benchmarking Working Group (BMWG).
この単純な例では、被試験デバイスによって使用されるハッシュアルゴリズムのテスターの一部で知識を前提。そのようなアルゴリズムの知識は事前に常に可能ではない、いずれにしてもIETFベンチマーク作業部会（BMWG）によって生成さ多くの文書の「ブラックボックス」の精神に違反します。
Therefore, this memo adds a new consideration for benchmarking methodologies to select traffic patterns that overcome the effects of nonrandomness, regardless of the hashing algorithms in use. The balance of this section offers recommendations for test traffic patterns to avoid these effects, starting at the link layer and working up to the application layer.
したがって、このメモは関係なく、使用中のハッシュアルゴリズムの、nonrandomnessの影響を克服するため、トラフィックパターンを選択する方法論をベンチマークのための新たな検討を加えます。このセクションのバランスがリンク層で始まり、アプリケーション層まで働いて、これらの影響を回避するために、テストトラフィックパターンのための勧告を提供しています。
Test traffic SHOULD use pseudorandom patterns in IEEE 802 MAC addresses. The following source and destination MAC address pattern is RECOMMENDED:
テストトラフィックはIEEE 802 MACアドレスに擬似ランダムパターンを使用すべきです。以下の送信元と宛先MACアドレスパターンをお勧めします。
(RR & 0xFC):PP:PP:RR:RR:RR
（RR＆0xFC）：PP：PP：RR：RR：RR
where (RR & 0xFC) is a pseudorandom number bitwise ANDed with 0xFC, PP:PP is the 1-indexed interface number of the test instrument and RR:RR:RR is a pseudorandom number.
ここで、（RR＆0xFC）が0xFC、PPとAND擬似乱数ビット単位である：PPは、試験機器及びRRの1インデックス付きインターフェース番号：RR：RRは、擬似乱数です。
The bitwise ANDing of the high-order byte in the MAC address with 0xFC sets the low-order two bits of that byte to 0, guaranteeing a non-multicast address and a non locally administered address. Note that the resulting addresses may violate IEEE 802 standards by using organizationally unique identifiers (OUIs) not assigned to the test port manufacturer. However, since these addresses will be used only on isolated test networks there should be no possibility of mistaken identity.
0xFCとMACアドレスに上位バイトのビット単位のAND演算は、非マルチキャストアドレス及び非ローカル管理アドレスを保証し、0にそのバイトの下位2ビットを設定します。得られたアドレスは、テストポートメーカーに割り当てられていない組織的一意識別子（のOUI）を使用して、IEEE 802の規格に違反してもよいことに留意されたいです。これらのアドレスは孤立テストネットワーク上でのみ使用されますので、人違いの可能性があってはなりません。
Test traffic SHOULD use PP:PP to identify the source interface number of the test instrument. Such identification can be useful in troubleshooting. Allocating 2 bytes of the MAC address for interface identification allows for tests of up to 65,536 interfaces. A 2-byte space allows for tests much larger than those currently used in device benchmarking; however, tests involving more than 256 interfaces (fully utilizing a 1-byte space) are fairly common.
試験機器のソースインタフェース番号を識別するために、PP：テストトラフィックは、PPを使用すべきです。そのような識別は、トラブルシューティングに有用であり得ます。インタフェース識別するためのMACアドレスの2つのバイトを割り当てることは、最大65,536インターフェイスの試験を可能にします。 2バイトの空間は、現在のデバイスのベンチマークで使用されるものよりもはるかに大きい試験を可能にします。しかし、（完全に1バイトのスペースを利用して）256の以上のインタフェースを含む試験はかなり一般的です。
Note that the "PP:PP" designation refers to the source interface of the test instrument, not the device under test/system under test (DUT/SUT). There are situations where the DUT/SUT interface number may change during the test; one example would be a test of wireless LAN roaming. By referring to the (presumably static) source interface number of the test instrument, test engineers can keep track of test traffic regardless of any possible DUT/SUT changes.
指定試験機器ではなく、テスト中のテスト/システム下のデバイス（DUT / SUT）のソースインタフェースを指す：「PP PP」があることに注意してください。 DUT / SUTのインターフェイス番号は、テスト中に変更されることが状況があります。一例としては、無線LANのローミングのテストになります。試験装置の（おそらく静的な）ソースインタフェース番号を参照することにより、テストエンジニアは関係なく、任意の可能なDUT / SUTの変更のテストトラフィックを追跡することができます。
Further, source interface numbers SHOULD be 1-indexed and SHOULD NOT be zero-indexed. This avoids the low but nonzero probability of an all-zeros MAC address. Some devices will drop frames with all-zeros MAC addresses.
さらに、ソースインターフェース番号は、1インデックス付きであるべきであり、ゼロインデックス付けされるべきではありません。これは、すべてゼロのMACアドレスの低いがゼロでない確率を避けることができます。一部のデバイスはすべてゼロのMACアドレスを持つフレームをドロップします。
It is RECOMMENDED to use pseudorandom patterns in the least significant 3 bytes of the MAC address. Using pseudorandom values for the low-order 3 bytes means choosing one of 16.7 million unique addresses. While this address space is vastly larger than is currently required in lab benchmarking, it does assure more realistic test traffic.
MACアドレスの下位3バイトに擬似ランダムパターンを使用することが推奨されます。下位3バイトのための擬似乱数値を使用すると、1670万個のユニークなアドレスのいずれかを選択することを意味します。このアドレス空間は、現在のラボベンチマーキングに必要とされるよりもはるかに大きいですが、それはより現実的なテストトラフィックを保証ありません。
Note also that since only 30 of 48 bits in the MAC address have pseudorandom values, there is no possibility of randomly generating a broadcast or multicast value by accident.
注意また、そのわずか30 MACアドレスに48ビットの擬似ランダム値を有するので、ランダム偶然ブロードキャストまたはマルチキャストの値を生成する可能性がありません。
It is common benchmarking practice for a test instrument to emulate multiple hosts, even on a single interface. This is desirable in assessing DUT/SUT scalability.
それも、単一のインターフェイス上で、複数のホストをエミュレートするための試験装置のための一般的なベンチマークの練習です。これは、DUT / SUTのスケーラビリティを評価することが望ましいです。
However, test instruments may emulate multiple MAC addresses by incrementing and/or decrementing addresses from a fixed starting point. This leads to situations, as described above in "Address Pattern Variations", where hashing algorithms produce nonoptimal outcomes.
しかし、試験装置は、インクリメントおよび/または固定された出発点からアドレスをデクリメントすることにより、複数のMACアドレスをエミュレートすることができます。ハッシュアルゴリズムが最適でない結果を生み出す「アドレスパターン変奏曲」で前述したようにこれは、状況につながります。
The outcome can be nonoptimal even if the set of addresses begins with a pseudorandom number. For example, the following source/ destination pairs will not be equally distributed by the 3-bit hashing algorithm discussed above:
アドレスのセットは、擬似乱数で始まる場合でも、結果は最適でないことができます。例えば、以下のソース/宛先ペアが等しく上述3ビットのハッシュアルゴリズムによって配布されません。
Source Destination 00:00:01:FC:B3:45 00:00:19:38:8C:80 00:00:01:FC:B3:46 00:00:19:38:8C:81 00:00:01:FC:B3:47 00:00:19:38:8C:82 00:00:01:FC:B3:48 00:00:19:38:8C:83 00:00:01:FC:B3:49 00:00:19:38:8C:84 00:00:01:FC:B3:4A 00:00:19:38:8C:85 00:00:01:FC:B3:4B 00:00:19:38:8C:86 00:00:01:FC:B3:4C 00:00:19:38:8C:87
ソース宛先00：00：01：FC：B3：45 00：00：19：38：8C：80 00：00：01：FC：B3：46 00：00：19：38：8C：81夜12時： 01：FC：B3：47 00：00：19：38：8C：82 00：00：01：FC：B3：48 00：00：19：38：8C：83 00：00：01：FC：B3： 49 00：00：19：38：8C：84 00：00：01：FC：B3：（a）00：00：19：38：8C：85 00：00：01：FC：B3：4B午前〇時00分19秒：38：8C：86 00：00：01：FC：B3：（c）00：00：19：38：8C：87
Again working with our 3-bit XOR hashing algorithm, we get the following outcomes:
再び私たちの3ビットのXORハッシュアルゴリズムでの作業、我々は次のような結果が得られます。
101 ^ 000 = 101 110 ^ 001 = 111 111 ^ 010 = 101 000 ^ 011 = 011 001 ^ 100 = 101 010 ^ 101 = 111 011 ^ 110 = 101 100 ^ 111 = 011
１０１ ＾ ０００ ＝ １０１ １１０ ＾ ００１ ＝ １１１ １１１ ＾ ０１０ ＝ １０１ ０００ ＾ ０１１ ＝ ０１１ ００１ ＾ １００ ＝ １０１ ０１０ ＾ １０１ ＝ １１１ ０１１ ＾ １１０ ＝ １０１ １００ ＾ １１１ ＝ ０１１
Note that only three of eight possible outcomes are achieved when incrementing addresses. This is actually the best case. Incrementing from other combinations of pseudorandom address pairs produces only one or two out of eight possible outcomes.
アドレスをインクリメントするときにのみ、3〜8個の可能性のある結果が達成されることに注意してください。これは実際に最善のケースです。擬似ランダムアドレスペアの他の組み合わせからインクリメントすること8つの可能な結果のうちの1つまたは2つだけを生成します。
Every MAC address SHOULD be pseudorandom, not just the starting one.
すべてのMACアドレスが1つだけ起動していない、擬似ランダムであるべきです。
When generating traffic with multiple addresses, it is RECOMMENDED that all addresses use pseudorandom values. There are multiple ways to use sets of pseudorandom numbers. One strategy would be for the test instrument to iterate over an array of pseudorandom values rather than incrementing/decrementing from a starting address. The actual method is an implementation detail; in the end, any method that uses multiple addresses with pseudorandom patterns will be sufficient.
複数のアドレスを持つトラフィックを生成する場合、すべてのアドレスは、擬似ランダム値を使用することをお勧めします。擬似乱数のセットを使用するために複数の方法があります。 1つの戦略はなく、開始アドレスからデクリメント/増分よりも擬似乱数値の配列を反復処理するための試験装置のためであろう。実際の方法は、実装の詳細です。最後に、擬似ランダムパターンと複数のアドレスを使用する任意の方法が十分であろう。
Experience with benchmarking of IEEE 802.11 devices suggests suboptimal test outcomes may result if different pseudorandom MAC and IP addresses are used from trial to trial. In such cases (not just for 802.11 but for any device using IEEE 802 MAC and IP addresses), testers MAY generate a pseudorandom set of MAC and IP addresses once, or MAY generate a nonrandom set of MAC and IP addresses once. In either case, the same MAC and IP addresses MUST be used in all trials.
IEEE 802.11デバイスのベンチマークの経験は異なる擬似ランダムMACアドレスとIPアドレスが裁判に裁判から使用されている場合は次善のテストの結果が生じる可能性を示唆しています。 （いない802.11ためなく、IEEE 802 MACおよびIPアドレスを使用して、任意のデバイスのためだけに）このような場合、テスターは、MACの擬似乱数セットを生成し、IPは、一旦アドレス、またはMACとIP一度アドレスの非ランダムセットを生成することができます。いずれの場合も、同じMACアドレスとIPアドレスは、すべての試験で使用しなければなりません。
Similar to L2 switches, multiprotocol label switching (MPLS) devices make forwarding decisions based on a 20-bit MPLS label. Unless specific labels are required, it is RECOMMENDED that uniformly random values between 16 and 1,048,575 be used for all labels assigned by test equipment. As per [RFC3032], this avoids using reserved MPLS labels in the range of 0-15 inclusive.
L2スイッチと同様に、マルチプロトコルラベルスイッチング（MPLS）デバイス作る20ビットMPLSラベルに基づいて決定を転送します。特定のラベルが必要とされない限り、16と1,048,575の間で一様にランダムな値が試験装置によって割り当てられたすべてのラベルに使用することが推奨されます。 [RFC3032]に従って、これは、包括0~15の範囲内の予約MPLSラベルを使用して回避します。
When routers make forwarding decisions based solely on the destination network address, there may be no potential for hashing collision of source and destination addresses, as in the case of Ethernet switching discussed earlier. However, the potential still exists for hashing collisions at the network layer, and testers SHOULD take this potential into consideration when crafting the network-layer contents of test traffic.
ルータは、単に宛先ネットワークアドレスに基づいて決定を転送する際に、前述のイーサネットスイッチングの場合のように、送信元アドレスと宛先アドレスの衝突をハッシュするための可能性がないかもしれません。しかし、可能性はまだネットワーク層での衝突をハッシュするために存在し、テストトラフィックのネットワーク層の内容を作り上げる際にテスターを考慮にこの可能性を取る必要があります。
For example, the equal cost multipath (ECMP) feature performs load-sharing across multiple links. Routers implementing ECMP may perform a hash of source and destination IP addresses in assigning flows.
例えば、等コストマルチパス（ECMP）機能は、複数のリンク間で負荷分散を行います。 ECMPを実装するルータがフローを割り当てる際に、送信元および宛先IPアドレスのハッシュを実行してもよいです。
Since multiple ECMP routes by definition have the same metric, routers use some other "tie-breaker" mechanism to assign traffic to each link. As far as the authors are aware, there is no standard algorithm for ECMP link assignment. Some implementations perform a hash of all bits of the source and destination IP addresses for this purpose. Others may perform a hash on one or more bytes in the source and destination IP addresses.
定義により、複数のECMPルートが同じメトリックを有するので、ルータは、各リンクにトラフィックを割り当てるために、いくつかの他の「タイブレーカ」メカニズムを使用します。限り著者が認識しているとして、ECMPリンクの割り当てのための標準的なアルゴリズムはありません。いくつかの実装は、この目的のために、送信元と宛先のIPアドレスのすべてのビットのハッシュを実行します。その他は、送信元と宛先のIPアドレスの内の1つの以上のバイトにハッシュを行うことができます。
Just as in the case of MAC addresses, nonrandom IP addresses can have an adverse effect on the outcome of ECMP link assignment decisions.
ただ、MACアドレスの場合のように、非ランダムIPアドレスは、ECMPリンク割り当ての決定の結果に悪影響を及ぼすことができます。
When benchmarking devices that implement ECMP or any other form of Layer 3 aggregation, it is RECOMMENDED to use a randomly distributed range of IP addresses. In particular, testers SHOULD NOT use addresses that produce the undesired effects of address processing. If, for example, a DUT can be observed to exhibit high packet loss when offered IPv4 network addresses that take the form x.x.1.x/24, and relatively low packet loss when the source and destination network addresses take the form of x.x.R.x/24 (where R is some random value between 0 and 9), test engineers SHOULD use the random pattern.
ECMPまたはレイヤ3集合の任意の他の形態を実装するデバイスのベンチマーク場合は、IPアドレスのランダムに分布範囲を使用することが推奨されます。具体的には、テスト担当者は、アドレス処理の望ましくない影響をもたらすのアドレスを使用しないでください。例えば、DUTは、ソースおよび宛先ネットワークアドレスが/ 24 xxRxの形をとる場合、フォームxx1.x / 24、および比較的低いパケット損失を取るIPv4ネットワークアドレスを提供するとき、高いパケット損失を示すことを観察することができる、場合（Rは0と9の間でいくつかのランダムな値である）、テストエンジニアは、ランダムパターンを使用すべきです。
Some devices with transport- or application-layer awareness use TCP or UDP port numbers in making forwarding decisions. Examples of such devices include load balancers and application-layer firewalls.
フォワーディング決定を行う際におけるtransport-またはアプリケーション層の意識の利用TCPやUDPのポート番号を持つ一部のデバイス。そのようなデバイスの例には、ロード・バランサとアプリケーション層ファイアウォールを含みます。
Test instruments have the capability of generating packets with random TCP and UDP source and destination port numbers. Known destination port numbers are often required for testing application-layer devices. However, unless known port numbers are specifically required for a test, it is RECOMMENDED to use pseudorandom and uniformly distributed values for both source and destination port numbers.
テスト機器は、ランダムなTCPとUDPの送信元と宛先ポート番号を持つパケットを生成する能力を有します。既知の宛先ポート番号は、多くの場合、テストアプリケーション層のデバイスに必要とされます。既知のポート番号は、特に試験のために必要とされない限りしかし、両方のソースと宛先ポート番号の擬似ランダムかつ均一に分布値を使用することが推奨されます。
In addition, it may be desirable to pick pseudorandom values from a selected pool of numbers. Many services identify themselves through use of reserved destination port numbers between 1 and 49151 inclusive. Unless specific port numbers are required, it is RECOMMENDED to pick randomly distributed destination port numbers between these lower and upper boundaries.
また、数字の選択されたプールからの擬似乱数値を選択することが望ましい場合があります。多くのサービスは、1と49151までの間の予約された宛先ポート番号の使用を介して自分自身を識別します。特定のポート番号が必要とされない限り、これらの下側及び上側の境界との間にランダムに分布した宛先ポート番号を選択することが推奨されます。
Similarly, clients typically choose source port numbers in the space between 1024 and 65535 inclusive. Unless specific port numbers are required, it is RECOMMENDED to pick randomly distributed source port numbers between these lower and upper boundaries.
同様に、クライアントは通常1024〜65535までの間の空間に送信元ポート番号を選択します。特定のポート番号が必要とされない限り、これらの下側及び上側の境界との間にランダムに分布したソースポート番号を選択することが推奨されます。
Many measurements require the insertion of application-layer header(s) and payload into test traffic. Application-layer packet contents offer additional opportunities for stuffing to occur, and may also present nonrandom outcomes when fed through application- layer-aware hashing algorithms. Given the vast number of application-layer protocols in use, we make no recommendation for specific test traffic patterns to be used; however, test engineers SHOULD be aware that application-layer traffic contents MAY produce nonrandom outcomes with some hashing algorithms. The same issues that apply with lower-layer traffic patterns also apply at the application layer. As discussed in section 5, the potential for stuffing exists with any part of a test packet, including application-layer contents. For example, some traffic generators insert fields into packet payloads to distinguish test traffic. These fields may contain a transmission timestamp; sequence number; test equipment interface identifier and/or "stream" number; and a cyclic redundancy check (CRC) over the contents of the test payload or test packet. All these fields are potential candidates for stuffing.
多くの測定は、試験トラフィックにアプリケーション層ヘッダ（単数または複数）とペイロードの挿入を必要とします。アプリケーション層のパケットの内容が発生するスタッフィングのための追加の機会を提供し、そして用途向け層対応ハッシュアルゴリズムを介して供給されたときにもランダムでない結果を提示することができます。使用中のアプリケーション層プロトコルの膨大な数を考えると、我々は、使用する特定のテストトラフィックパターンのための勧告を行うありません。しかし、テストエンジニアは、アプリケーション層のトラフィックの内容は、いくつかのハッシュアルゴリズムと非ランダムな結果をもたらすかもしれないことに注意する必要があります。下層トラフィックパターンに適用されるのと同じ問題は、アプリケーション層に適用します。セクション5で説明したように、詰め物の可能性は、アプリケーションレイヤコンテンツを含むテストパケットの任意の部分とが存在します。例えば、一部のトラフィック・ジェネレータは、テストトラフィックを区別するために、パケットのペイロードにフィールドを挿入します。これらのフィールドは、送信タイムスタンプが含まれていてもよいです。シーケンス番号。試験装置インタフェース識別子及び/又は「ストリーム」の数。そして試験ペイロードまたはテストパケットの内容を超える巡回冗長検査（CRC）。すべてのこれらのフィールドは、詰め物の潜在的な候補です。
Link-layer technologies that use High-Level Data Link Control (HDLC)- like framing may insert an extra bit or byte before each instance of a control character in traffic. These "stuffing" insertions prevent confusion with control characters, but they may also introduce significant overhead. Stuffing is data-dependent; thus, selection of different payload patterns will result in frames transmitted on the media that vary in length, even though the original frames may all be of the same length.
ハイレベルデータリンク制御（HDLC）を使用するリンク層技術 - フレーミングのようには、トラフィックの制御文字の各インスタンスの前に余分なビットまたはバイトを挿入することができます。これらの「詰め物」の挿入は、制御文字との混同を防ぐため、彼らはまた、かなりのオーバーヘッドを導入することができます。スタッフィングは、データ依存です。従って、異なるペイロード・パターンの選択は、元のフレームが全て同じ長さであっても、長さが変化する媒体上で送信フレームをもたらすであろう。
The overhead of these escape sequences is problematic for two reasons. First, explicitly calculating the amount of overhead can be non-trivial or even impossible for certain types of test traffic. In such cases, the best testers can do is to characterize the probability that an escape sequence will occur for a given pattern. This greatly complicates the requirement of declaring exactly how much traffic is offered to a DUT/SUT.
これらのエスケープシーケンスのオーバーヘッドは、2つの理由のために問題があります。まず、明示的にオーバーヘッドの量を算出することは、テスト用トラフィックの特定の種類の非自明な、あるいは不可能です。このような場合には、できる最善のテスターは、エスケープシーケンスが与えられたパターンに対して発生する確率を特徴づけることです。これは非常にDUT / SUTに提供されて正確にどのくらいのトラフィック宣言の要件を複雑にします。
Second, in the absence of characterization and compensation for this overhead, the tester may unwittingly congest the DUT/SUT. For example, if a tester intends to offer traffic to a DUT at 95 percent of line rate, but the link-layer protocol introduces an additional 1 percent of overhead to escape control characters, then the aggregate offered load will be 96 percent of line rate. If the DUT's actual channel capacity is only 95 percent, congestion will occur and the DUT will drop traffic even though the tester did not intend this outcome.
第二に、このオーバーヘッドのために特徴付け及び補償の非存在下で、テスタは、無意識のうちにDUT / SUTが輻輳してもよいです。テスタは、ライン速度の95％でDUTにトラフィックを提供しようとするが、リンク層プロトコルは、制御文字をエスケープするオーバーヘッドの追加の1パーセントを導入する場合、例えば、次に凝集提供された負荷は、ライン速度の96％になります。 DUTの実際のチャネル容量は唯一の95パーセントである場合には、輻輳が発生し、DUTは、テスタが、この結果を意図していなかったにもかかわらず、トラフィックをドロップします。
As described in [RFC1661] and [RFC1662], PPP and HDLC-like framing introduce two kinds of escape sequences: bit- and byte-stuffing. Bit-stuffing refers to the insertion of an escape bit on bit-synchronous links. Byte-stuffing refers to the insertion of an escape byte on byte-synchronous links. We discuss each in turn.
bit-およびバイトスタッフィング：[RFC1661]及び[RFC1662]に記載されているように、PPPとHDLCのようなフレーミングはエスケープシーケンスの二種類を導入します。ビットスタッフィングは、ビット同期リンクに逃がしビットの挿入を指します。バイトスタッフィングバイト同期リンクでエスケープバイトの挿入を指します。私たちは、順番に、それぞれについて説明します。
[RFC1662], section 5.2, specifies that any sequence of five contiguous "1" bits within a frame must be escaped by inserting a "0" bit prior to the sequence. This escaping is necessary to avoid confusion with the HDLC control character 0x7E, which contains six "1" bits.
[RFC1662]、セクション5.2は、フレーム内の5個の連続「1」ビットのいずれかの配列が前配列に「0」ビットを挿入することによってエスケープされなければならないことを指定します。このエスケープは、6つの「1」のビットが含まれているHDLC制御文字0x7Eに、との混同を避ける必要があります。
Consider the following PPP frame containing a TCP/IP packet. Not shown is the 1-byte flag sequence (0x7E), at least one of which must occur between frames.
TCP / IPパケットを含む以下のPPPフレームを考えてみましょう。図示されていないフレームの間で発生する必要があり、少なくとも一方は1バイトのフラグシーケンス（0x7Eを）、です。
The contents of the various frame fields can be described one of three ways:
種々のフレームフィールドの内容は、3つの方法のいずれかを説明することができます。
1. Field contents never change over the test duration. An example would be the IP version number.
1.フィールドの内容は、試験時間の経過とともに変化することはありません。例では、IPのバージョン番号になります。
2. Field contents change over the test duration. Some of these changes are known prior to the test duration. An example would be the use of incrementing IP addresses. Some of these changes are unknown. An example would be a dynamically calculated field such as the TCP checksum.
2.フィールドの内容は、試験期間にわたって変化します。これらの変化のいくつかは、試験期間前に知られています。例では、IPアドレスをインクリメントを使用することであろう。これらの変化のいくつかは不明です。例としては、TCPチェックサムとして動的に計算フィールドになります。
3. Field contents may not be known. An example would be proprietary payload fields in test packets.
3.フィールドの内容は知られていないかもしれません。例では、テストパケットに独自のペイロードフィールドであろう。
In the diagram below, 30 out of 48 total bytes in the packet headers are subject to change over the test duration. Additionally, the payload field could be subject to change both content and size. The fields containing the changeable bytes are given in ((double parentheses)).
以下の図では、パケットヘッダ内の48行の総バイト数のうち30は、試験期間にわたって変更される場合があります。また、ペイロードフィールドは、内容とサイズの両方を変更することができます。可変バイトを含むフィールドは、（（二重括弧））に記載されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | ((Header Checksum)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Source Address)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Destination Address)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Source Port)) | ((Destination Port)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Sequence Number)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Acknowledgment Number)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| ((Window)) |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Checksum)) | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ ((payload)) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((FCS (4 bytes) )) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
None of the other fields are known to contain sequences subject to bit-stuffing, at least not in their entirety. Note that there is no payload in this simple example; as noted in section 4.6, the payload contents of test traffic often will present additional opportunities for stuffing to occur, and MUST be taken into account when calculating stuff probability.
他のフィールドのいずれも、少なくともしないそれらの全体において、ビットスタッフィングの対象配列を含むことが知られていません。この簡単な例にはペイロードがないことに注意してください。セクション4.6で述べたように、テストトラフィックのペイロードの内容が頻繁に発生するスタッフィングのための追加の機会を提供し、スタッフ確率を計算する際に考慮しなければなりません。
Given the information at hand, and assuming static contents for the rest of the fields, the challenge is to determine the probability that bit-stuffing will occur.
手元に情報が与えられ、そして残りのフィールドのための静的な内容を想定し、課題は、ビットスタッフィングが発生する確率を決定することです。
In order to calculate bit-stuffing probabilities, we assume that for any string of length L, where b_n represents the "n"th bit of the string and 1 <= n <= L, the probability of b_n equalling "1" is 0.5, and the probability of b_n equalling "0" is 0.5. Additionally, the value of b_n is independent of any other bits.
ビットスタッフィング確率を計算するために、我々はB_Nが「N」番目の列のビットと1 <= N <= Lを表す長さL、の任意の文字列を、「1」に等しいB_Nの確率が0.5であると仮定する、および「0」に等しいB_Nの確率は0.5です。また、B_Nの値は、任意の他のビットとは無関係です。
We can calculate the probability of bit-stuffing for both infinite and finite strings of random bits. We begin with the infinite-string case. For an infinitely long string of uniformly random bits, we will need to insert a stuff bit if and only if state 5 is reached in the following state table.
私たちは、ランダムビットの無限と有限の文字列の両方のためのビットスタッフィングの確率を計算することができます。我々は無限の文字列のケースで始まります。一様ランダムビットの無限に長い文字列のために、私たちは、ステート5は、以下の状態テーブルに到達した場合だけスタッフビットを挿入する必要があります。
|--------------------<----------------------|
| |1
_______ __|__ _____ _____ _____ __|__
| | 1 | | 1 | | 1 | | 1 | | 1 | |
| start |--->| 1 |--->| 2 |--->| 3 |--->| 4 |--->| 5 |
|_______| |_____| |_____| |_____| |_____| |_____|
| | | | | | |
| |0 |0 |0 |0 |0 |0
|-<-|----<----|----<-----|----<-----|----<-----|----<-----|
Initially, we begin in the "start" state. A "1" bit moves us into the next highest state, and a "0" bit returns us to the start state. From state 5, a "1" bit takes us back to the 1 state and a "0" bit returns us to "start".
当初、私たちは、「スタート」状態で始まります。 「1」のビットは、次の最高の状態に私たちを移動し、「0」ビットは、開始状態に私たちを返します。状態5からは、「1」のビットが戻って1つの状態に私たちを取り、「0」のビットが「開始」にお戻ります。
From this state diagram we can build the following transition matrix:
この状態図から、我々は、次の遷移行列を構築することができます。
\ To |
\ |
\ |
From \ | start 1 2 3 4 5
______\|_________________________________________________
start | 0.5 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0
1 | 0.5 | 0.0 | 0.5 | 0.0 | 0.0 | 0.0
2 | 0.5 | 0.0 | 0.0 | 0.5 | 0.0 | 0.0
3 | 0.5 | 0.0 | 0.0 | 0.0 | 0.5 | 0.0
4 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0 | 0.5
5 | 0.5 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0
With this transition matrix we can build the following system of equations. If P(x) represents the probability of reaching state x, then:
この遷移行列で、私たちは以下の式のシステムを構築することができます。 P（x）は、次に、状態xに到達する確率を表す場合：
P(start) = 0.5 * P(start) + 0.5 * P(1) + 0.5 * P(2) + 0.5 * P(3) + 0.5 * P(4) + 0.5 * P(5)
P（開始）= 0.5 * P（開始）+ 0.5 * P（1）+ 0.5 * P（2）+ 0.5 * P（3）+ 0.5 * P（4）+ 0.5 * P（5）
P(1) = 0.5 * P(start) + 0.5 * P(5) P(2) = 0.5 * P(1) P(3) = 0.5 * P(2) P(4) = 0.5 * P(3) P(5) = 0.5 * P(4)
P（1）= 0.5 * P（開始）+ 0.5 * P（5）P（2）= 0.5×P（1）、P（3）= 0.5×P（2）、P（4）= 0.5×P（3 ）P（5）= 0.5 * P（4）
P(start) + P(1) + P(2) + P(3) + P(4) + P(5) = 1
P（開始）+ P（1）+ P（2）+ P（3）+ P（4）+ P（5）= 1
Solving this system of equations yields:
方程式の収量のこのシステムを解きます：
P(start) = 0.5 P(1) = 8/31 P(2) = 4/31 P(3) = 2/31 P(4) = 1/31 P(5) = 1/62
P（開始）= 0.5 P（1）= 8/31 P（2）= 4/31 P（3）= 2/31 P（4）= 1/31 P（5）= 62分の1
Thus, for an infinitely long string of uniformly random bits, the probability of any individual bit causing a transition to state 5, and thus causing a stuff, is 1/62.
したがって、一様ランダムビットの無限に長い文字列を、任意の個々のビットの確率状態5への遷移を引き起こし、従ってものを引き起こすが、62分の1です。
For a uniformly random finite bit string of length L, we can explicitly count the number of bit-stuffs in the set of all possible strings of length L. This count can then be used to calculate the expected number of stuffs for the string.
長さLの一様ランダム有限ビット列については、我々は明示的にこのカウントは、その文字列のために詰め込む数の期待値を計算するために使用することができる長さLのすべての可能な文字列の集合で、ビット詰め込むの数をカウントすることができます。
Let f(L) represent the number of bit-stuffs in the set of all possible strings of length L. Clearly, for 0 <= L <= 4, f(L) = 0 as there are no strings of length 5. For L >= 5, f(L) = 2^(L-5) + (L-5) * 2^(L-6) + f(L-5).
F（L）長さ5のない文字列のが存在しないように0 <=ため、明らかに、長さLのすべての可能な文字列の集合でL <= 4、F（L）= 0、ビット詰め込むの数を表してみましょうL> = 5、F（L）= 2 ^（L-5）+（L-5）* 2 ^（L-6）+ F（L-5）。
A proof of this formula can be found in Appendix B.
この式の証明は付録Bに見出すことができます
Now, the expected number of stuffing events, E[stuffs], can be found by dividing the total number of stuffs in all possible strings by the total number of strings. Thus for any L, E[stuffs] = f(L) / 2^L.
今、スタッフィングイベントの予想される数、E [詰め込む]は、文字列の総数ですべての可能な文字列に詰め込むの合計数を割ることによって求めることができます。したがって、任意のLのために、E [詰め込む] = F（L）/ 2 ^ L。
Similarly, the probability that any particular bit is the cause of a bit-stuff can be calculated by dividing the total number of stuffs in the set of all strings of length L by the total number of bits in the set of all strings of length L. Hence for any L, the probability that L_n, where 5 <= n <= L, caused a stuff is f(L) / (L * 2^L).
同様に、任意の特定のビットは、ビットものの原因である確率は、長さLの全ての文字列のセット内のビットの総数で、長さLの全ての文字列のセットに詰め込むの合計数を割ることによって計算することができます。 。したがって、任意の1,5 <= N <= Lは、ものを引き起こしL_nは、F（L）/（L※2 ^ L）である確率のために。
The amount of overhead attributable to bit-stuffing may be calculated explicitly as long as the expected number of stuff bits per frame, E[bit-stuffs] is known. For long uniformly random bit-strings, E[bit-stuffs] may be approximated by multiplying the length of the string by 1/62.
ビットスタッフィングに起因するオーバーヘッドの量であれば、フレームあたりスタッフビットの予想数、E [ビット詰め込む]が知られているように、明示的に計算することができます。長い一様にランダムなビット列に対して、E [ビット詰め込む]は62分の1によって文字列の長さを乗算することによって近似することができます。
% overhead = E[bit-stuffs] / framesize (in bits)
％のオーバーヘッド= EBIT-詰め込む] /（ビット）のフレームサイズ
Given that the overhead added by bit-stuffing is approximately 1 in 62, or 1.6 percent, it is RECOMMENDED that testers reduce the maximum intended load by 1.6 percent to avoid introducing congestion when testing devices using bit-synchronous interfaces (such as T1/E1, DS-3, and the like).
ビットスタッフィングによって追加のオーバーヘッドが約1 62、または1.6％で、そのようなT1 / E1としてビット同期インターフェースを（使用してデバイスをテストする場合テスターは、輻輳の導入を回避するために1.6％によって最大意図負荷を低減することが推奨されていることを考えると、DS-3、など）。
The percentage given above is an approximation. For greatest precision, the actual intended load SHOULD be explicitly calculated from the test traffic.
上記の割合が近似値です。最大精度のために、実際の意図された荷重は、明示的にテストトラフィックから計算されるべきです。
Note that the DUT/SUT may be able to forward intended loads higher than the calculated theoretical maximum rate without packet loss. This results from queuing on the part of the DUT/SUT. While a device's throughput may be above this level, delay-related measurements may be affected. Accordingly, it is RECOMMENDED to reduce offered levels by the amount of bit-stuffing overhead when testing devices using bit-synchronous links. This recommendation applies for all measurements, including throughput.
DUT / SUTは、パケット損失なしに計算された理論最大速度よりも高いことを意図し負荷を転送することができることに留意されたいです。これは、DUT / SUTの一部にキューイングに起因します。デバイスのスループットがこのレベルを上回るかもしれないが、遅延に関連する測定値が影響を受ける可能性があります。したがって、ビット同期リンクを使用してデバイスをテストする場合、ビットスタッフィングオーバーヘッドの量によって提供されるレベルを低減することが推奨されます。この勧告は、スループットを含むすべての測定のために適用されます。
[RFC1662] requires that "Each Flag Sequence, Control Escape octet, and any octet which is flagged in the sending Async-Control-Character-Map (ACCM), is replaced by a two octet sequence consisting of the Control Escape octet followed by the original octet exclusive-or'd with hexadecimal 0x20". The practical effect of this is to insert a stuff byte for instances of up to 34 characters: 0x7E, 0x7D, or any of 32 ACCM values.
[RFC1662]「は各フラグシーケンス、コントロールエスケープオクテット、及び送信非同期制御文字・マップ（ACCM）にフラグが立てられている任意のオクテットは、続いてコントロールエスケープオクテットから成る2つのオクテット配列によって置換されることが必要オリジナルのオクテットは進の0x20" で排他的論理和。 0x7Eを、0x7D、または32のACCM値のいずれか：この実用的な効果は、最大34文字のインスタンスのためのスタッフバイトを挿入することです。
A common implementation of PPP in HDLC-like framing is in PPP over SONET/SDH (POS), as defined in [RFC2615].
HDLC様のフレーミングにおけるPPPの一般的な実装は、[RFC2615]で定義されるように、SONET / SDH（POS）上にPPPです。
As with the bit-stuffing case, the requirement in characterizing POS test traffic is to determine the probability that byte-stuffing will occur for a given sequence. This is much simpler to do than with bit-synchronous links, since there is no possibility of overlap across byte boundaries.
ビットスタッフィングの場合と同様に、POSテストトラフィックを特徴付けるにおける要件は、バイトスタッフィングは、所定の配列のために発生する確率を決定することです。バイトの境界を越えて重複の可能性がないので、これは、ビット同期のリンクがより行うことがはるかに簡単です。
Testers can greatly reduce the probability of byte-stuffing by configuring link partners to negotiate an ACCM value of 0x00. It is RECOMMENDED that testers configure the test instrument(s) and DUT/SUT to negotiate an ACCM value of 0x00 unless specific ACCM values are required.
テスターは大幅には0x00のACCM値を交渉するリンクパートナーを設定することによって、バイトスタッフィングの確率を減らすことができます。テスターは、特定のACCM値が必要とされない限りは0x00のACCM値を交渉する試験装置（S）とDUT / SUTを設定することが推奨されます。
One instance where nonzero ACCM values are used is in the Layer 2 Tunneling Protocol (L2TP), as defined in [RFC2661], section 4.4.6. When the default ACCM values are used, the probability of stuffing for any given random byte is 34 in 256, or approximately 13.3 percent.
非ゼロACCM値が使用される1つのインスタンスは、[RFC2661]で定義されるように、レイヤ2トンネリングプロトコル（L2TP）であり、セクション4.4.6。デフォルトACCM値が使用される場合、任意のランダムバイトのための詰めの確率は256 34、または約13.3パーセントです。
If an ACCM value of 0x00 is negotiated, the only characters subject to stuffing are the flag and control escape characters. Thus, we can say that without ACCM the probability of stuffing for any given random byte is 2 in 256, or approximately 0.8 percent.
$ 00のACCM値がネゴシエートされる場合、スタッフィング対象文字のみ、フラグや制御エスケープ文字です。したがって、我々はACCMせずに任意のランダムなバイトのための詰めの確率は256で2、または約0.8パーセントであると言うことができます。
The amount of overhead attributable to byte-stuffing may be calculated explicitly as long as the expected number of stuff bytes per frame, E[byte-stuffs], is known. For long uniformly random byte-strings, E[byte-stuffs] may be approximated by multiplying the length of the string by the probability that any single byte is a stuff byte.
バイトスタッフィングに起因するオーバーヘッドの量E [バイト詰め込む]限りスタッフの期待数は、フレームあたりのバイトとして明示的に計算することができるが、知られています。長い一様にランダムなバイト列に対して、E [バイト詰め込む]は、任意の単一のバイトがスタッフバイトである確率によって、文字列の長さを乗算することによって近似することができます。
% overhead = E[byte-stuffs] / framesize (in bytes)
（バイト）％のオーバーヘッド= E [バイト詰め込む] /フレームサイズ
When testing a DUT/SUT that implements PPP in HDLC-like framing and L2TP (or any other technology that uses nonzero ACCM values), it is RECOMMENDED that testers reduce the maximum intended load by 13.3 percent to avoid introducing congestion.
HDLC様のフレーミングおよびL2TP（または非ゼロACCM値を使用する他の技術）にPPPを実装DUT / SUTをテストする場合には、テスターが輻輳を導入回避13.3パーセント最大意図負荷を低減することが推奨されます。
When testing a DUT/SUT that implements PPP in HDLC-like framing and an ACCM value of 0x00, it is RECOMMENDED that testers reduce the maximum intended load by 0.8 percent to avoid introducing congestion.
HDLC様のフレーミングおよび0x00でのACCM値にPPPを実装DUT / SUTをテストする場合には、テスターは、輻輳の導入を回避するために0.8パーセントによって最大意図負荷を低減することが推奨されます。
Note that the percentages given above are approximations. For greatest precision, the actual intended load SHOULD be explicitly calculated from the test traffic
上記のパーセンテージは近似値であることに留意されたいです。最大の精度のために、実際に意図された負荷は、明示的にテストトラフィックから計算されるべきです
Note also that the DUT/SUT may be able to forward intended loads higher than the calculated theoretical maximum rate without packet loss. This results from queuing on the part of the DUT/SUT. While a device's throughput may be above this level, delay-related measurements may be affected. Accordingly, it is RECOMMENDED to reduce offered levels by the amount of byte-stuffing overhead when testing devices using byte-synchronous links. This recommendation applies for all measurements, including throughput.
ノートはまた、DUT / SUTは、パケット損失なしに計算された理論最大速度よりも高いことを意図し負荷を転送することができるかもしれません。これは、DUT / SUTの一部にキューイングに起因します。デバイスのスループットがこのレベルを上回るかもしれないが、遅延に関連する測定値が影響を受ける可能性があります。従って、バイトスタッフィングバイト同期リンクを使用してデバイスをテストする際のオーバーヘッドの量によって提供されるレベルを低減することが推奨されます。この勧告は、スループットを含むすべての測定のために適用されます。
This document recommends the use of pseudorandom patterns in test traffic. This usage requires a uniform distribution, but does not have strict predictability requirements. Although it is not sufficient for security applications, the rand() function of many programming languages may provide a uniform distribution that is usable for testing purposes in lab conditions. Implementations of rand() may vary and provide different properties so test designers SHOULD understand the distribution created by the underlying function and how seeding the initial state affects its behavior.
このドキュメントでは、テストトラフィックの擬似ランダムパターンを使用することを推奨しています。この使用法は、均一な分布が必要ですが、厳格な予測可能性の要件はありません。それはセキュリティアプリケーションのために十分ではないが、多くのプログラミング言語の関数rand（）関数は、実験室条件でテスト目的のために使用可能である均一な分布を提供することができます。テスト設計者は、基礎となる機能とどのように初期状態を播種すると、その動作に影響を与えることによって作成した分布を理解する必要がありますので、ランドの実装（）は異なる特性を変化させると提供することができます。
[RFC2615], section 6, discusses a denial-of-service attack involving the intentional transmission of characters that require stuffing. This attack could consume up to 100 percent of available bandwidth. However, the test networks described in BMWG documents generally SHOULD NOT be reachable by anyone other than the tester(s).
[RFC2615]、セクション6は、詰め物を必要とする文字の意図的な伝送を含むサービス拒否攻撃を論じています。この攻撃は、利用可能な帯域幅の100％まで消費できます。しかし、BMWG書に記載の試験ネットワークは、一般に、テスタ（S）以外の者によって到達されるべきではありません。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
"HDLC様のフレーミングにおけるPPP" [RFC1662]シンプソン、W.、STD 51、RFC 1662、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
、RFC 2544、1999年3月 "ネットワーク相互接続デバイスのためのベンチマーキング方法論" [RFC2544]ブラドナー、S.とJ. McQuaid、。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615] Malis、A.とW.シンプソン、 "SONET / SDH上のPPP"、RFC 2615、1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
"LANスイッチングデバイスのベンチマーク方法論" [RFC2889]マンデヴィル、R.とJ. Perser、RFC 2889、2000年8月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
Appendix A. Acknowledgements
付録A.謝辞
The authors gratefully acknowledge reviews and contributions by Tom Alexander, Len Ciavattone, Robert Craig, John Dawson, Neil Carter, Glenn Chagnot, Kevin Dubray, Diego Dugatkin, Rafael Francis, Paul Hoffman, David Joyner, Al Morton, Joe Perches, Jerry Perser, Scott Poretsky, Dan Romascanu, and Kris Rousey.
作者は感謝トム・アレクサンダー、レンCiavattone、ロバート・クレイグ、ジョン・ドーソン、ニール・カーター、グレンChagnot、ケビンDubray、ディエゴ・Dugatkin、ラファエル・フランシス、ポール・ホフマン、デビッド・ジョイナー、アル・モートン、ジョー・パーチ、ジェリーPerserによるレビューと貢献を認め、スコットPoretsky、ダンRomascanu、およびクリスRousey。
Appendix B. Proof of Formula for Finite Bit-Stuffing
有限ビットスタッフィングのための式の付録B.証明
We would like to construct a function, f(L), that allows us to explicitly count the total number of bit-stuffs in the set of all strings of length L. Let S represent a bit string of length L. Additionally, let b_n be the nth bit of string S where 1 <= n <= L.
L. Sは、さらに、長さLのビット列を表すB_Nせてみましょう私たちは、私たちは、明示的に長さのすべての文字列の集合で、ビット詰め込むの合計数をカウントすることを可能にする関数f（L）を、構築したいと思います1 <= N <= L.ストリングSのn番目のビットであります
Clearly, when 0 <= L <= 4, f(L) = 0, as there can be no possible bit-stuff if there are < 5 bits.
明らかに、0 <= L <5ビットがある場合は何も可能なビット・スタッフが存在しないことができるように、<= 4、F（L）= 0、。
Suppose L >= 5, then there is some number of strings that will cause stuffing events. Let us count them.
仮定L> = 5、そしてスタッフィングイベントが発生します文字列の一部の数があります。私たちはそれらをカウントしてみましょう。
We begin by counting the number of strings that will cause at least one bit-stuff. Let us suppose that the first 5 bits, b_1,...,b_5, cause a stuffing event. Then, there are (L-5) bits that could have any value, i.e., the bits in position b_6 to b_L. So, there must be 2^(L-5) strings where the first 5 bits cause a stuff.
私たちは、少なくとも1つのビット-ものが発生します文字列の数をカウントすることから始めます。私たちは最初の5ビット、B_1、...、B_5、スタッフィングイベントを引き起こすこととしましょう。次いで、任意の値を有することができる（L-5）ビットがある、すなわち、位置のビットはB_LにB_6。だから、最初の5ビットがものを引き起こす2 ^（L-5）文字列が存在しなければなりません。
Now suppose that some other sequence of bits causes a stuff, b_n to b_(n+4) for some 1 < n <= L-4. In order to guarantee that b_n starts a stuff sequence, b_(n-1) must be 0, otherwise a stuff could occur at b_(n+3). Thus, there are a total of 6 bits which must have fixed values in the string, S, and a total of L-6 bits which do not have fixed values. Hence, for each value of n, there are 2^(L-6) possible strings with at least one bit-stuff for a total of (L-5) * 2^(L-6).
現在、いくつか1 <N <= L-4のビットいくつかの他の配列がB_NはB_する、ものを引き起こす（N + 4）と仮定する。そのB_Nを保証するために、さもなければものがB_（N + 3）で起こり得る、スタッフシーケンスを開始し、B_（n-1）は0でなければなりません。このように、文字列Sの値を固定しておく必要があり、6ビットの総数、及び固定値を持っていないL-6ビットの合計があります。したがって、Nの各値に対して、（L-5）* 2 ^（L-6）の合計は、少なくとも1つのビット・スタッフとの2 ^（L-6）の可能な文字列が存在します。
So, given a string of length L, where L >= 5, we know that there are 2^(L-5) + (L-5) * 2^(L-6) strings which will be transmitted with at least one stuffed bit. However, if L >= 10, then there could be more than one bit-stuff within the string S. Let Z represent a sequence of 5 sequential "1" bits. Consider the bit string ..., b_n, b_(n+1), b_(n+2), Z, b_(n+8), b_(n+9), ... where 1 <= n <= L-9. For the above sequence of bits to generate two stuffing events, there must be at least one run of five sequential one's bits in ..., b_n, b_(n+1), b_(n+2), b_(n+8), b_(n+9), ... Note that the position of Z in the above sequence is irrelevant when looking for bit-stuffs. Additionally, we've already determined that the number of strings with at least one stuff in a bit string of length L is 2^(L-5) + (L-5) * 2^(L-6). Thus, the total number of stuffing events in the set of all bit strings of length L can be represented as f(L) = 2^(L-5) + (L-5) * 2^(L-6) + f(L-5) for all L >= 5.
だから、L> = 5は、我々は、少なくとも一つで送信される2 ^（L-5）+（L-5）* 2 ^（L-6）の文字列が存在することを知っている長さLの文字列を、指定されました詰めビット。 L> = 10の場合は、その文字列S.レッツZ内の複数のビットのものがあるかもしれない5シーケンシャル「1」ビットのシーケンスを表します。ビット列...、B_N、B_（N + 1）、B_（N + 2）、Z、B_（N + 8）、B_（N + 9）を考える、... 1 <= N <= L-9。 2スタッフィングイベントを生成するためのビットの上記のシーケンスのために、内...、B_N 5シーケンシャル人のビット、B_（N + 1）、B_（N + 2）の少なくとも1つのラン、B_（N + 8が存在しなければなりません）、B_（N + 9）···ビット詰め込むを探している時には、上記配列中のZの位置は無関係であることに留意されたいです。さらに、我々はすでに、長さLのビット列の少なくとも一つのものを含む文字列の数は2 ^であると判断しました（L-5）+（L-5）* 2 ^（L-6）。従って、長さLの全てのビットストリングの集合におけるスタッフィングイベントの合計数をf（L）= 2 ^（L-5）+（L-5）* 2 ^（L-6）+ Fとして表すことができます。 （L-5）すべてのL> = 5のために。
Appendix C. Explicit Calculation of Bit-Stuffing Overhead for IPv4
IPv4のビットスタッフィングオーバーヘッドの付録C.明示的な計算
Consider a scenario where a tester is transmitting IPv4 test packets across a bit synchronous link. The test traffic has the following parameters (values are in decimal):
テスターは、ビット同期リンクを介したIPv4テストパケットを送信しているシナリオを考えます。テストトラフィックは、次のパラメータ（値は10進数である）を持ちます：
+-----------------------+---------------------------+
| Field | Value |
+-----------------------+---------------------------+
| IP Version | 4 |
| IP Header Length | 5 |
| Type of service (TOS) | 0 |
| Datagram Length | 1028 |
| ID | 0 |
| Flags/Fragments | 0 |
| Time to live (TTL) | 64 |
| Protocol | 17 |
| Source IP | 192.18.13.1-192.18.13.254 |
| Destination IP | 192.18.1.10 |
| Source UDP Port | pseudorandom port |
| Destination UDP Port | pseudorandom port |
| UDP Length | 1008 |
| Payload | 1000 pseudorandom bytes |
+-----------------------+---------------------------+
We want to calculate the expected number of stuffs per packet, or E[packet stuffs].
私たちは、パケットあたり詰め込む数の期待値を計算したい、またはE [パケット詰め込みます]。
First, we observe that we have 254 different IP headers to consider, and secondly, that the changing 4th octet in the IP source addresses will produce occasional bit-stuffing events, so we must enumerate these occurrences. Additionally, we must take into account that the 3rd octet of the source IP and the first octet of the destination IP will affect stuffing occurrences.
まず、我々は考慮すべき254の異なるIPヘッダを持っていることを観察し、そして第二に、IP送信元アドレスでの変更第4オクテットは時折、ビットスタッフィングイベントが生成されますことを、私たちはこれらの発生を列挙しなければなりません。さらに、我々は元IPと宛先IPの最初のオクテットの第三オクテットは詰め物の発生に影響を与えることを考慮に入れる必要があります。
An exhaustive search shows that cycling through all 254 headers produces 51 bit-stuffs for the destination IP address. This gives us an expectation of 51/254 stuffs per packet due to the changing source IP address.
全数探索は、すべての254個のヘッダを循環する宛先IPアドレスの51ビット詰め込むを産生することを示しています。これは、私たちに変化による送信元IPアドレスへのパケットあたり254分の51詰め込むの期待を与えます。
For the IP CRC, we observe that the value will decrement as the source IP is incremented. A little calculation shows that the CRC values for these headers will fall in the range of 0xE790 to 0xE88F.
IP CRCのために、我々はソースIPがインクリメントされる値がデクリメントされますことを確認します。ほとんどの計算は、これらのヘッダのCRC値が0xE88Fに0xE790の範囲内に入ることを示しています。
Additionally, both the protocol and source IP address must be considered, as they provide a source of extra leading and trailing "1" bits.
彼らは余分先頭と「1」ビットを後続のソースを提供するように、さらに、プロトコルおよびソースIPアドレスの両方を考慮しなければなりません。
An exhaustive search shows that cycling through all 254 headers will produce 102 bit-stuffs for the CRC. This gives us an expectation of 102/254 stuffs per packet due to the CRC.
全数探索は、すべての254個のヘッダを循環するCRCの102ビット詰め込むを生成することを示しています。これは、私たちにCRCによるパケットあたり254分の102詰め込むの期待を与えます。
Since our destination IP address is even and the UDP length is less than 32768, the random source and destination ports provide 32 bits of sequential random data without forcing us to consider the boundary bits. Additionally, we will assume that since our payload is pseudorandom, our UDP CRC will be too. The even UDP length field again allows us to only consider the bits explicitly contained within the CRC and data fields. So, using the formula for the expected number of stuffs in a finite string from section 5.2.2, we determine that E[UDP stuffs] = f(32)/2^32 + f(8000+16)/2^(8000+16). Now, f(32)/2^32 is calculable without too much difficulty and is approximately 0.465. However, f(8016)/2^8016 is a little large to calculate easily, so we will approximate this value by using the probability value obtained in section 5.2.1. Thus, E[UDP] ~ 0.465 + 8016/62 ~ 129.755.
当社の宛先IPアドレスが偶数とUDPの長さ未満32768、であるので、ランダムな送信元ポートおよび宛先ポートは、境界ビットを考慮することが私たちを強制することなく、シーケンシャル、ランダムなデータの32ビットを提供します。また、我々は我々のペイロードが擬似ランダムであるため、私たちのUDP CRCがあまりにもなりますと仮定します。でも、UDP長フィールドは、再び私たちは唯一の明示的CRCとデータフィールド内に含まれるビットを考慮することができます。だから、セクション5.2.2から有限の文字列内の詰め込むの予想される数の数式を使用して、我々は、E [UDP詰め込む] = F（32）/ 2 ^ 32 + F（+ 16 8000）/ 2 ^（8000いることを決定します16）。さて、F（32）/ 2 ^ 32は、あまりにも多くの困難なく計算可能であり、約0.465です。しかし、F（8016）/ 2 ^ 8016を簡単計算するために少し大きいので、我々は、セクション5.2.1で得られた確率値を使用して、この値を近似します。したがって、E [UDP]〜0.465 + 62分の8016〜129.755。
Hence, E[packet stuffs] = 51/254 + 102/254 + 129.755 = 130.357. However, since we cannot have a fractional stuff, we round down to 130. Thus, we expect 130 stuffs per packet.
従って、E [パケット詰め込む] = 254分の51 + 254分の102 + 129.755 = 130.357。私たちは小数のものを持つことができないので、しかし、我々は、パケットあたり130詰め込むを期待して、このように130に切り捨て。
Finally, we can calculate bit-stuffing overhead by dividing the expected number of stuff bits by the total number of bits in the IP datagram. So, this example traffic would generate 1.58% overhead. If our payload had consisted exclusively of zero bits, our overhead would have been 0.012%. An all-ones payload would produce 19.47% overhead.
最後に、我々は、IPデータグラム内のビットの総数でスタッフビットの期待数を割ることによって、ビットスタッフィングオーバーヘッドを計算することができます。したがって、この例のトラフィックは、1.58パーセントのオーバーヘッドを生成します。私たちのペイロードが独占的にゼロのビットから構成されていた場合は、私たちのオーバーヘッドは0.012パーセントであったであろう。すべてのもののペイロードは、19.47パーセントのオーバーヘッドを生成します。
Appendix D. Explicit Calculation of Bit-Stuffing Overhead for IPv6
IPv6のためのビットスタッフィングオーバーヘッドの付録D.明示的な計算
Consider a scenario where a tester is transmitting IPv6 test packets across a bit-synchronous link. The test traffic has the following parameters (values are in decimal except for IPv6 addresses, which are in hexadecimal):
テスタは、ビット同期リンクを介したIPv6テストパケットを送信しているシナリオを考えます。テストトラフィックは、次のパラメータ（値は16進数であるIPv6アドレスを除いて小数である）を有します。
+----------------------+----------------------------------+
| Field | Value |
+----------------------+----------------------------------+
| IP Version | 6 |
| Traffic Class | 0 |
| Flow Label | pseudorandom label |
| Payload Length | 1008 |
| Next Header | 17 |
| Hop Limit | 64 |
| Source IP | 2001:DB8:0:1::1-2001:DB8:0:1::FF |
| Destination IP | 2001:DB8:0:2::10 |
| Source UDP Port | pseudorandom port |
| Destination UDP Port | pseudorandom port |
| UDP Length | 1008 |
| Payload | 1000 pseudorandom bytes |
+----------------------+----------------------------------+
We want to calculate the expected number of stuffs per packet, or E[packet stuffs].
私たちは、パケットあたり詰め込む数の期待値を計算したい、またはE [パケット詰め込みます]。
First, we observe that we have 255 different IP headers to consider, and secondly, that the changing 4th quad in the IP source addresses will produce occasional bit-stuffing events, so we must enumerate these occurrences. Additionally, we also note that since the first quad of the destination address has a leading zero bit, we do no have to consider these adjacent bits when calculating the number of bit-stuffs in the source IP address.
まず、我々は考慮すべき255の異なるIPヘッダを持っていることを観察し、そして第二に、IP送信元アドレスでの変更第四のクワッドは時折、ビットスタッフィングイベントが生成されますことを、私たちはこれらの発生を列挙しなければなりません。さらに、我々はまた、宛先アドレスの最初のクワッドが先行ゼロビットを持っているので、私たちは何のソースIPアドレスにビット詰め込むの数を計算するときに、これらの隣接ビットを考慮しなければならないことに注意していません。
An exhaustive search shows that cycling through all 255 headers produces 20 bit-stuffs for the source IP address. This gives us an expectation of 20/255 stuffs per packet due to the changing source IP address.
徹底的な検索は、すべての255個のヘッダを循環する送信元IPアドレスの20ビット詰め込むを生成することを示しています。これは、私たちに変化による送信元IPアドレスへのパケットあたり255分の20詰め込むの期待を与えます。
We also have to consider our pseudorandomly generated flow label. However, since our Traffic Class field is 0 and our Payload Length field is less than 32768 (and thus the leading bit of the Payload Length field is 0), we may consider the flow label as 20 bits of random data. Thus the expectation of a stuff in the flow label is f(20)/2^20 ~ .272.
また、当社の擬似乱数生成フローラベルを考慮する必要があります。私たちのトラフィッククラスフィールドが0であると私たちのペイロード長フィールドが32768未満であるので、（したがって、ペイロード長フィールドの先頭ビットが0である）、私たちはランダムな20ビットのデータとして、フローラベルを考慮することができます。従ってフローラベルにおけるものの期待がF（20）/ 2 ^ 20〜0.272です。
Similar to the flow label case above, the fourth quad of our destination IP address is even and the UDP length field is less than 32768, so the random source and destination ports provide 32 bits of sequential random data without forcing us to consider the boundary bits. Additionally, we will assume that since our payload is pseudorandom, our UDP CRC will be too. The even UDP length field again allows us to only consider the bits explicitly contained within the CRC and data fields. So, using the formula for the expected number of stuffs in a finite string from section 5.2.2, we determine that E[UDP stuffs] = f(32)/2^32 + f(8000+16)/2^(8000+16). Now, f(32)/2^32 is calculable without too much difficulty and is approximately 0.465. However, f(8016)/2^8016 is a little large to calculate easily, so we will approximate this value by using the probability value obtained in section 5.2.1. Thus, E[UDP stuffs] ~ 0.465 + 8016/62 ~ 129.755.
上記フローラベルの場合と同様に、私たちの送信先IPアドレスの第四のクワッドが偶数で、UDP長フィールドは32768未満であるので、ランダムな送信元ポートと宛先ポートは、境界ビットを考慮することが私たちを強制することなく、シーケンシャル、ランダムなデータの32ビットを提供します。また、我々は我々のペイロードが擬似ランダムであるため、私たちのUDP CRCがあまりにもなりますと仮定します。でも、UDP長フィールドは、再び私たちは唯一の明示的CRCとデータフィールド内に含まれるビットを考慮することができます。だから、セクション5.2.2から有限の文字列内の詰め込むの予想される数の数式を使用して、我々は、E [UDP詰め込む] = F（32）/ 2 ^ 32 + F（+ 16 8000）/ 2 ^（8000いることを決定します16）。さて、F（32）/ 2 ^ 32は、あまりにも多くの困難なく計算可能であり、約0.465です。しかし、F（8016）/ 2 ^ 8016を簡単計算するために少し大きいので、我々は、セクション5.2.1で得られた確率値を使用して、この値を近似します。したがって、E [UDP詰め込む]〜0.465 + 62分の8016〜129.755。
Now we may explicitly calculate that E[packet stuffs] = 20/255 + 0.272 + 129.755 = 130.105. However, since we cannot have a fractional stuff, we round down to 130. Thus, we expect 130 stuffs per packet.
今、私たちは、明示的にそのE [パケット詰め込む]は= 255分の20 + 0.272 + 129.755 = 130.105を計算することができます。私たちは小数のものを持つことができないので、しかし、我々は、パケットあたり130詰め込むを期待して、このように130に切り捨て。
Finally, we can calculate bit-stuffing overhead by dividing the expected number of stuff bits by the total number of bits in the IP datagram. So, this example traffic would generate 1.55% overhead. If our payload had consisted exclusively of zero bits, our overhead would have been 0.010%. An all-ones payload would produce 19.09% overhead.
最後に、我々は、IPデータグラム内のビットの総数でスタッフビットの期待数を割ることによって、ビットスタッフィングオーバーヘッドを計算することができます。したがって、この例のトラフィックは、1.55パーセントのオーバーヘッドを生成します。私たちのペイロードが独占的にゼロのビットから構成されていた場合は、私たちのオーバーヘッドは0.010％であったであろう。すべてのもののペイロードは、19.09パーセントのオーバーヘッドを生成します。
Appendix E. Terminology
付録E.用語
Hashing
ハッシング
Also known as a hash function. In the context of this document, an algorithm for transforming data for use in path selection by a networking device. For example, an Ethernet switch with multiple processing elements might use the source and destination MAC addresses of an incoming frame as input for a hash function. The hash function produces numeric output that tells the switch which processing element to use in forwarding the frame.
また、ハッシュ関数として知られています。この文書の文脈では、ネットワークデバイスによって経路選択に使用するためのデータを変換するためのアルゴリズムです。例えば、複数の処理要素を有するイーサネットスイッチは、ハッシュ関数の入力として受信フレームの送信元および宛先MACアドレスを使用するかもしれません。ハッシュ関数は、処理要素は、フレームの転送に使用するようにスイッチに指示数値出力を生成します。
Randomness
ランダム性
In the context of this document, the quality of having an equal probability of any possible outcome for a given pattern space. For example, if an experiment has N randomly distributed outcomes, then any individual outcome has a 1 in N probability of occurrence.
本文書の文脈において、所定のパターン空間の任意の可能な結果の等しい確率を有するの品質。実験は、Nがランダムな結果を配布した場合、例えば、その後、任意の個々の結果は、発生の1 Nにおける確率を有します。
Repeatability
再現
The precision of test results obtained on a single test bed, but from trial to trial. See also "reproducibility".
試験結果の精度は、単一のテストベッド上で得られたが、試験から試験まで。また、「再現性」を参照してください。
Reproducibility
再現性
The precision of test results between different setups, possibly at different locations. See also "repeatability".
試験の精度は、恐らくは異なる場所で、異なる設定間の結果。また、「再現性」を参照してください。
Stuffing
詰め物
The insertion of a bit or byte within a frame to avoid confusion with control characters. For example, RFC 1662 requires the insertion of a "0" bit prior to any sequence of five contiguous "1" bits within a frame to avoid confusion with the HDLC control character 0x7E.
制御文字との混同を避けるために、フレーム内のビットまたはバイトの挿入。例えば、RFC 1662 HDLC制御文字0x7Eをとの混同を避けるために、前のフレーム内の5個の連続「1」ビットのいずれかの配列に「0」ビットの挿入を必要とします。
Authors' Addresses
著者のアドレス
David Newman Network Test
デヴィッド・ニューマンネットワークテスト
EMail: dnewman@networktest.com
メールアドレス：dnewman@networktest.com
Timmons C. Player Spirent Communications
ティモンズC.プレーヤーのSpirentコミュニケーションズ
EMail: timmons.player@spirent.com
メールアドレス：timmons.player@spirent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。