[要約] 要約：RFC 4814は、ネットワークデバイスのベンチマークテストにおいて、ハッシュとスタッフィングという重要な要素が見落とされていることを指摘しています。目的：このRFCの目的は、ネットワークデバイスのベンチマークテストにおいて、ハッシュとスタッフィングの重要性を認識し、適切な評価基準を確立することです。
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）The IETF Trust（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つの要因を見落としています。まず、既存の方法論では、これらのフィールドがテスト結果に影響を与える可能性がある場合でも、アドレスまたはその他のテストトラフィックコンテンツのレポートを必要としません。第二に、いくつかのリンク層テクノロジーによってテストトラフィックに挿入された「スタッフ」ビットとバイトは、重要で可変のオーバーヘッドを追加し、テスト結果に影響します。このドキュメントは、これらの要因の効果について説明しています。テストトラフィックコンテンツのガイドラインを推奨します。また、テストトラフィックでビットおよびバイトストーフの確率を決定するための式を提供します。
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]などの方法論には、パケットコンテンツの宣言は必要ありません。これらの方法論では、トラフィックの分布や交通志向などのテストパラメーターの宣言が必要ですが、パケットコンテンツは、少なくとも他の要因と同じくらいテスト結果に大きな影響を与える可能性があります。パケットコンテンツのバリエーションは、テスト結果の非繰り返し性にもつながる可能性があります。2人の個人は、文字の方法論的手順に従い、それでも非常に異なる結果を得ることができます。
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.
このドキュメントでは、2つの領域をカバーしています。まず、テストトラフィックにおけるランダム性と非ランダム性に対処するための戦略について説明します。第二に、ポイントツーポイントプロトコル（PPP）でビットおよびバイトストーフの確率を決定し、SONET（POS）回路上のパケットを決定するための式を提示します。両方の分野で、テスト結果でより良い再現性を得るための推奨事項を提供します。
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.
ベンチマークネットワークトポロジは、独立したテストセットアップとなり、テストトラフィックを生産ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤って転送するデバイスに接続してはなりません。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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アドレスを複数の試行で使用する必要があることを示唆しています。これは、このドキュメントで行われたいくつかの推奨事項と矛盾するように思われますが、実際、非ランダムまたは擬似ランダムパターンのいずれかが、テストのセットアップに応じてより望ましい場合があります。また、たとえば、1つのテスト試験で擬似ランダムトラフィックパターンを生成し、すべての試行で同じパターンを再利用するなど、2つの組み合わせを使用することが望ましい場合もあります。このドキュメントのキーワードは、擬似ランダムテストトラフィックパターンの使用に関しては推奨されておらず、必須ではありません。
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.
このドキュメントでは、制御されたラボ条件下でのテストトラフィックにおける疑似ランダムパターンの使用を推奨しています。多くのプログラミング言語で利用可能なRAND（）関数は、真にランダムではなく擬似ランダムである出力を生成します。擬似ランダムパターンは、パターン空間全体に均一に分布する出力を生成する場合、このドキュメントに記載されている推奨事項に十分です。
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のランダムなビットパターンの場合、その特定のパターンを生成する確率は、LTH電力に2以上に等しいはずです。
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つのネットワークプロセッサ（NP）を備えたイーサネットスイッチの単純なケースを考えてみましょう。
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ビットおよび宛先MACアドレスのハッシュアルゴリズムが排他的または（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
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操作の結果は常に0になり、同じ3つの最も有意なビットが与えられます。
001 ^ 001 = 000
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.
したがって、スイッチはすべてのトラフィックをNP0に割り当て、他の7つのNPSアイドルを残します。十分に重い負荷を考えると、NP0とスイッチは混雑しますが、他の7つのNPが利用可能です。せいぜい、このデバイスは総容量の約12.5％を利用できるようになり、残りの容量の87.5％が未使用の87.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
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.
したがって、このメモは、使用中のハッシュアルゴリズムに関係なく、非ランダム性の効果を克服するトラフィックパターンを選択するためのベンチマーク方法に関する新しい考慮事項を追加します。このセクションのバランスは、これらの効果を回避するために、テストトラフィックパターンに関する推奨事項を提供します。リンクレイヤーから始まり、アプリケーションレイヤーまで作業します。
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
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：pp：ppはテスト機器の1つのインターフェイス番号であり、RR：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アドレスの高次バイトのビットワイズアンドングは、そのバイトの低次の2ビットを0に設定し、非マルチカストアドレスとローカルで管理されていないアドレスを保証します。結果のアドレスは、テストポートメーカーに割り当てられていない組織的に一意の識別子（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を使用して、テスト機器のソースインターフェイス番号を識別する必要があります。このような識別は、トラブルシューティングに役立ちます。インターフェイス識別に2バイトのMACアドレスを割り当てることで、最大65,536のインターフェイスのテストが可能になります。2バイトのスペースにより、デバイスベンチマークで現在使用されているテストよりもはるかに大きいテストが可能になります。ただし、256を超えるインターフェイスを含むテスト（1バイトスペースを完全に利用）はかなり一般的です。
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.
「PP：PP」の指定は、テスト/システム中のデバイス（DUT/SUT）ではなく、テスト機器のソースインターフェイスを指すことに注意してください。テスト中に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インデックス化され、ゼロインデックス化されてはなりません。これにより、All-Zeros Macアドレスの低いがゼロではない確率が回避されます。一部のデバイスでは、All-Zeros 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.
また、MACアドレスの48ビットのうち30ビットのみが擬似ランダム値を持っているため、偶然に放送またはマルチキャスト値をランダムに生成する可能性はないことに注意してください。
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
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.
アドレスを増やすときに、可能な8つの可能な結果のうち3つだけが達成されることに注意してください。これは実際には最良のケースです。擬似ランダムアドレスペアの他の組み合わせから増加すると、8つの可能な結果のうち1つまたは2つだけが生成されます。
Every MAC address SHOULD be pseudorandom, not just the starting one.
すべてのMacアドレスは、開始のアドレスだけでなく、擬似ランダムである必要があります。
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アドレスの擬似ランダムセットを1回生成するか、MacおよびIPアドレスの非ランダムセットを1回生成する場合があります。どちらの場合でも、すべての試行で同じ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アドレスの範囲を使用することをお勧めします。特に、テスターは、住所処理の望ましくない効果を生み出すアドレスを使用してはなりません。たとえば、フォームX.X.1.x/24を取得するIPv4ネットワークアドレスを提供すると、DUTが高いパケット損失を示すことが観察され、ソースおよび宛先ネットワークアドレスがX.X.R.X/24の形をとると、比較的低いパケット損失を示すことができます。（ここで、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.
輸送またはアプリケーションレイヤーの意識を持つ一部のデバイスは、転送決定を行う際に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.
[RFC1661]および[RFC1662]で説明されているように、PPPとHDLCのようなフレーミングは、ビットとバイトの積み上げの2種類のエスケープシーケンスを導入します。ビットスタッフとは、ビット同期リンクへのエスケープビットの挿入を指します。バイトスタッフとは、バイト同期リンクにエスケープバイトの挿入を指します。順番にそれぞれについて説明します。
[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は、シーケンスの前に「0」ビットを挿入することにより、フレーム内の5つの連続した「1」ビットのシーケンスを逃れる必要があることを指定します。この脱出は、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）は示されていません。少なくとも1つはフレーム間で発生する必要があります。
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の任意の文字列について、b_nが「1」に等しくなる確率は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」ビットが「Start」に戻ります。
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(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(start) + 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
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に移行し、したがってものを引き起こす可能性は1/62です。
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のすべての可能な文字列のセットのビット額の数を明示的にカウントできます。このカウントを使用して、文字列の予想されるもの数を計算できます。
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).
長さ5の文字列がないため、f（l）が長さLのすべての可能な文字列のセットのセットの数を表します。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のすべての文字列のセットのビットの総数で分割することによって計算できます。。したがって、任意のLの場合、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 [ビットスタッチ]は、文字列の長さに1/62を掛けることで近似できます。
% overhead = E[bit-stuffs] / framesize (in bits)
％オーバーヘッド= e [ビットスタッチ] /フレームズ（ビット）
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).
ビットスタッフによって追加されたオーバーヘッドが62分の1または1.6％で約1であることを考えると、ビット同期インターフェイスを使用してデバイスをテストするときに混雑の導入を避けるために、テスターが最大意図の負荷を1.6％減らすことをお勧めします（T1/E1など、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）にフラグが付けられたオクテットが、コントロールエスケープオクテットとそれに続くコントロールエスケットシーケンスに置き換えられることが必要です。オリジナルのOctet Exclusive-OR hexadecimal 0x20 "。これの実際的な効果は、最大34文字（0x7e、0x7d）、または32のACCM値のいずれかの場合のために、スタッフバイトを挿入することです。
A common implementation of PPP in HDLC-like framing is in PPP over SONET/SDH (POS), as defined in [RFC2615].
[RFC2615]で定義されているように、HDLC様フレーミングにおけるPPPの一般的な実装は、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値が必要な場合を除き、テスターはテスト機器とDUT/SUTを構成して0x00のACCM値をネゴシエートすることをお勧めします。
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.
[RFC2661]で定義されているように、非ゼロACCM値が使用される1つの例は、レイヤー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.
0x00の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（）関数は、ラボ条件でのテスト目的で使用可能な均一な分布を提供する場合があります。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ドキュメントで説明されているテストネットワークは、一般に、テスター以外の人が到達できるべきではありません。
[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.
[RFC1662]シンプソン、W。、「HDLCのようなフレーミングのPPP」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615] Malis、A。およびW. Simpson、「PPP Over Sonet/SDH」、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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
[RFC2889] Mandeville、R。およびJ. Perser、「LANスイッチングデバイスのベンチマーク方法論」、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
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.
著者は、トム・アレクサンダー、レン・シアヴァットン、ロバート・クレイグ、ジョン・ドーソン、ニール・カーター、グレン・チャニョット、ケビン・ドブレイ、ディエゴ・デュガン、ラファエル・フランシス、ポール・ホフマン、デビッド・ジョイナー、アル・モートン、ジョー・パーシェス、ジェリー・ペルセ、スコット・ポレツキー、ダン・ロマスカヌ、クリス・ラウジー。
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のすべての文字列のセットのセットのビット荷重の総数を明示的にカウントできる関数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 <= 4、f（l）= 0の場合、5ビット未満がある場合、ビット積み立ちはありません。
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_6からb_lの位置のビットがあります。したがって、最初の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-1）は0でなければなりません。そうしないと、B_（n 3）で材料が発生する可能性があります。したがって、文字列、S、および固定値を持たない合計L-6ビットに固定値を持つ必要がある合計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で長さlの文字列を考えると、少なくとも1つの詰め物を送信する2^（l-5）（l-5） * 2^（l-6）文字列があることがわかります。少し。ただし、l> = 10の場合、文字列Sには複数のビット荷重が発生する可能性があります。ビット文字列...、b_n、b_（n 1）、b_（n 2）、z、b_（n 8）、b_（n 9）、...ここで1 <= n <= l-9。上記のビットのシーケンスで2つの詰め物イベントを生成するには、少なくとも5つのシーケンシャルワンのビットが1つの実行が必要です。（n 9）、...上記のシーケンスにおけるzの位置は、ビット荷物を探すときは無関係であることに注意してください。さらに、長さlの少し文字列に少なくとも1つのものがある文字列の数は2^（l-5）（l-5） * 2^（l-6）であるとすでに判断しました。したがって、長さlのすべてのビット文字列のセットの詰めイベントの総数は、f（l）= 2^（l-5）（l-5） * 2^（l-6）f（lとして表すことができます。-5）すべてのl> = 5について。
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テストパケットを少し同期リンクに送信しているシナリオを考えてみましょう。テストトラフィックには、次のパラメーターがあります（値は小数です）。
+-----------------------+---------------------------+
| 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の3番目のオクテットと宛先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アドレスの変化により、パケットごとに51/254のスタッフが期待されます。
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値が0xE790〜0XE88Fの範囲に分類されることが示されています。
Additionally, both the protocol and source IP address must be considered, as they provide a source of extra leading and trailing "1" bits.
さらに、プロトコルとソースのIPアドレスの両方を考慮する必要があります。これは、追加のリーディングおよびトレーリングの「1」ビットのソースを提供するためです。
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によるパケットごとに102/254のスタッフが期待されます。
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（8000 16）/2^（8000 16）であると判断します。。現在、F（32）/2^32は、あまりにも困難なく計算可能であり、約0.465です。ただし、F（8016）/2^8016は簡単に計算するのに少し大きいため、セクション5.2.1で得られた確率値を使用してこの値を概算します。したがって、e [udp] 〜0.465 8016/62〜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 [パケットスタッフ] = 51/254 102/254 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％のオーバーヘッドを生成します。
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ソースアドレスの変化する4番目のクワッドが時折ビットスタッフイベントを作成するため、これらの発生を列挙する必要があります。さらに、宛先アドレスの最初のクワッドにはゼロビットが先頭にあるため、ソース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アドレスの変化により、パケットごとに20/255のスタッフが期待されます。
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〜.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アドレスの4番目のクワッドは均等であり、UDP長さフィールドは32768未満であるため、ランダムソースと宛先ポートは、境界ビットを考慮せずに32ビットのシーケンシャルランダムデータを提供します。。さらに、ペイロードは疑似ランダムであるため、UDP CRCもそうなると仮定します。均等なUDP長さフィールドにより、CRCおよびデータフィールド内に明示的に含まれるビットのみを考慮することができます。したがって、セクション5.2.2の有限文字列で予想されるものの式を使用して、E [UDPスタッフ] = F（32）/2^32 F（8000 16）/2^（8000 16）であると判断します。。現在、F（32）/2^32は、あまりにも困難なく計算可能であり、約0.465です。ただし、F（8016）/2^8016は簡単に計算するのに少し大きいため、セクション5.2.1で得られた確率値を使用してこの値を概算します。したがって、E [UDPスタッフ] 〜0.465 8016/62〜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 [パケットスタッフ] = 20/255 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％のオーバーヘッドを生成します。
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がランダムに分布した結果がある場合、個々の結果はn in n n n 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
David Newmanネットワークテスト
EMail: dnewman@networktest.com
Timmons C. Player Spirent Communications
ティモンズC.プレーヤースパイレントコミュニケーション
EMail: timmons.player@spirent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。