RFC4814 日本語訳
4814 Hash and Stuffing: Overlooked Factors in Network DeviceBenchmarking. D. Newman, T. Player. March 2007. (Format: TXT=59272 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Newman
Request for Comments: 4814 Network Test
Category: Informational T. Player
Spirent Communications
March 2007
コメントを求めるワーキンググループD.ニューマン要求をネットワークでつないでください: 4814年のネットワークテストカテゴリ: 2007年の情報のT.プレーヤーSpirentコミュニケーション行進
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).
IETFが信じる著作権(C)(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つの要素を見落とします。 まず最初に、既存の方法論はアドレスか他のテスト交通コンテンツの報告を必要としません、これらの分野が試験の成績に影響できますが。 2番目に、「もの」ビットといくつかのリンクレイヤ技術でテスト交通に挿入されたバイトは重要で可変なオーバーヘッドを加えます。(順番に、それは、試験の成績に影響します)。 このドキュメントはこれらの要素の効果について説明します。 テスト交通コンテンツのためのガイドラインを推薦します。 そして、ビットの確率を測定するために定石を提供して、テスト交通でバイト詰めること。
Newman & Player Informational [Page 1] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[1ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 一般問題. . . . . . . . . . . . . . . . . . . . 4 3.1。 再現可能性. . . . . . . . . . . . . . . . . . . . . . 4 3.2。 偶発性. . . . . . . . . . . . . . . . . . . . . . . . 4 4。 パケット内容変化. . . . . . . . . . . . . . . . . . 5 4.1。 問題声明. . . . . . . . . . . . . . . . . . . . 5 4.2。 IEEE802MACは.1に.74.2を記述します。 MACのランダマイズされたセットは.84.3を記述します。 MPLSアドレシング. . . . . . . . . . . . . . . . . . . . . 9 4.4。 ネットワーク層アドレシング. . . . . . . . . . . . . . . . . 9 4.5。 トランスポート層アドレシング. . . . . . . . . . . . . . . . 10 4.6。 応用層は.105を型に基づいて作ります。 制御文字詰め物. . . . . . . . . . . . . . . . . . 11 5.1。 問題声明. . . . . . . . . . . . . . . . . . . . 11 5.2。 pppビット・スタッフィング. . . . . . . . . . . . . . . . . . . . . 12 5.2.1。 ビット・スタッフィング確率. . . . . . . . . 14 5.2.2について計算します。 有限ストリング. . . . . . . . . . . 15 5.2のためのビット・スタッフィング.3。 適用されたビット・スタッフィング. . . . . . . . . . . . . . . . . 16 5.3。 POSバイトを詰める. . . . . . . . . . . . . . . . . . . . 16 5.3.1。 ACCM. . . . . . . . . . . . . . . . . . . 17 5.3.2を無効にします。 他の詰められたキャラクター. . . . . . . . . . . . . . . 17 5.3.3。 バイトを詰める.176を適用しました。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 18 7。 IPv6. . . . . . . . . . . . . . . . . . . . . . . . 23付録E.用語. . . . . . . . . . . . . . . . . . . . . 24のためのビット・スタッフィングオーバーヘッドのIPv4. . . . . . . . . . . . . . . . . . . . . . . . 21の付録のD.の明白な計算のためのビット・スタッフィングオーバーヘッドの有限ビット・スタッフィング. . . . . . 20の付録のC.の明白な計算のための公式の引用規格. . . . . . . . . . . . . . . . . . . . . 19付録A.承認. . . . . . . . . . . . . . . . . . 20付録B.証拠
Newman & Player Informational [Page 2] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[2ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
1. Introduction
1. 序論
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.
関連する問題はHigh-レベルのData Link Controlの(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つの領域をカバーしています。 私たちは、テスト交通で偶発性と非ランダムに対処するために戦略を検討します。 2番目に、私たちは、Sonet(POS)サーキットの上にPointからポイントへのプロトコル(PPP)のビットとバイト詰め物とPacketの確率を測定するために定石を提示します。 両方の領域では、私たちが、より良い再現可能性を得るための推薦を試験の成績に提供します。
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交通をテストマネジメント・ネットワークに送るかもしれない装置に接続されてはいけません。
2. Requirements
2. 要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Newman & Player Informational [Page 3] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[3ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
3. General Considerations
3. 一般問題
3.1. Repeatability
3.1. 再現可能性
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.
再現可能性に関連する別の問題はテスト交通で、偶発性の回避です。 例えば、複数のトライアルの向こう側に非ランダムメディアアクセスが制御する802.11台の装置が示すいくらかのIEEEのベンチマーキング経験(MAC)とIPアドレスを使用しなければなりません。 これは本書ではされたいくつかの推薦状に矛盾するように思えるでしょうが、事実上、テストセットアップによって、非ランダムか擬似ランダムパターンのどちらかが、より望ましいかもしれません。 2つのものの組み合わせ、例えば、擬似ランダム交通を発生させることによって、パターンが個人的にはトライアルをテストするのが、使用に望ましいかもしれない状況とも次に、同じパターンを再使用するのがすべてのトライアルのむこうにあります。 キーワードはMUSTsではなく、本書では擬似ランダムテストトラフィック・パターンの使用に関するRECOMMENDsです。
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.
また、この議論が再現可能性だけをカバーすることに注意してください。(同じテストベッドの上にトライアルからトライアルまで試験の成績の可変性に再現可能性に関します)。 別々の関心は再現性です。(その再現性は異なったテストベッドから得られた試験の成績の精度について言及します)。 明確に、複数のテストベッドの向こう側の再現性は単一のテストベッドの上に再現可能性を必要とします。
3.2. Randomness
3.2. 偶発性
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.
このドキュメントは制御研究室状態の下のテスト交通における擬似ランダムパターンの使用を推薦します。 多くのプログラミング言語で利用可能な底ならし革()機能は本当に、無作為であるよりむしろ擬似ランダムである出力を起こします。 擬似ランダムパターンは本書では与えられた推薦に十分です、パターンスペースの向こう側に一様に広げられる出力を起こすなら。
Newman & Player Informational [Page 4] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[4ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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のどんな無作為のビット・パターンのためのSHOULDが等しいその特定のパターンを作るという明確に確率、も1、2以上、Lthパワーに。
4. Packet Content Variations
4. パケット内容変化
4.1. Problem Statement
4.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
イングレス|| \/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ___ ___ ___ ___ ___ ___ ___ ___ | || | | | | | | | | | | | | | | | | ||NP0| |NP1| |NP2| |NP3| |NP4| |NP5| |NP6| |NP7| | ||___| |___| |___| |___| |___| |___| |___| |___| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || \/出口
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.)
入って来る交通を様々なNPsに割り当てるには、論じ尽くすアルゴリズムが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アドレスのランダム分布はすべての8NPsの向こう側に一様に広げられる交通をもたらすべきです。 (「無作為である」という用語の例は与えられたアドレス空間の向こう側に本書では無作為の一様分布を示します。 セクション3.2はさらに詳細に無作為の一定の配について説明します。) 実際には、テスト交通における、偶発性の学位によって、細切れ肉料理(その結果、どんなテストも結果として生じる)の実際の結果は非常に異なるようになるでしょう。
Newman & Player Informational [Page 5] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[5ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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です、インタフェース番号にかかわらず。 したがって、同じ3つの最下位ビットを考えて、XOR操作の結果はいつも0になるでしょう:
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.
したがって、7NPsにもう片方を活動していないままにして、スイッチはすべての交通をNP0に割り当てるでしょう。 十分重い負荷を考えて、他の7NPsが利用可能ですが、NP0とスイッチは混雑するようになるでしょう。 高々、この装置は総容積のおよそ12.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
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のソースインタフェース番号であるかは擬似ランダム番号です。 この場合、MACアドレスの最も重要でない3ビットでどんな000〜111までの値も包括的になるという等しい確率があるべきです。 したがって、XOR操作の結果は0〜7まで等しく分配されるべきです、そして、また、NPsの向こう側の分配も等しいはずです(少なくともこの特定の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 Benchmarking作業部会(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.
したがって、ベンチマーキング方法論が非ランダムの影響に打ち勝つトラフィック・パターンを選択するように、このメモは新しい考慮を加えます、使用中の論じ尽くすアルゴリズムにかかわらず。 このセクションのバランスはテストトラフィック・パターンがこれらの効果を避けるという推薦を提供します、リンクレイヤで始まって、応用層をあおって。
Newman & Player Informational [Page 6] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[6ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
4.2. IEEE 802 MAC Addresses
4.2. IEEE802MACアドレス
Test traffic SHOULD use pseudorandom patterns in IEEE 802 MAC addresses. The following source and destination MAC address pattern is RECOMMENDED:
テスト交通SHOULDはIEEE802MACアドレスで擬似ランダムパターンを使用します。 以下のソースと目的地MACアドレスパターンはRECOMMENDEDです:
(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)が擬似ランダム番号であるところでは、PP: 0xFCとbitwise ANDed、PPはRR: 試験計器とRRの1で索引をつけられたインタフェース番号です: 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アドレスの高位バイトのbitwise ANDingはそのバイトの下位の2ビットを0に設定します、非マルチキャストアドレスと非局所的に管理されたアドレスを保証して。 結果として起こるアドレスが組織的でユニークな識別子(OUIs)を使用するのによる802の規格がテストポートメーカーに配属しなかったIEEEに違反するかもしれないことに注意してください。 しかしながら、これらのアドレスが孤立しているテストネットワークだけで使用されるので、間違われたアイデンティティの可能性が全くあるべきではありません。
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.
テスト交通SHOULDは、試験計器のソースインタフェース番号を特定するのにPP: PPを使用します。 そのような識別はトラブルシューティングで役に立つ場合があります。 MACのバイトがインタフェース識別のために記述する割り当て2は最大6万5536のインタフェースのテストを考慮します。 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.
テスト(DUT/SUT)でのテスト/システムでの装置ではなく、試験計器のソースのインタフェースに名称が参照するその「pp: pp」に注意してください。 状況がDUT/SUTインタフェース番号がテストの間に変化するかもしれないところにあります。 1つの例は無線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.
さらに、ソースインタフェース数のSHOULDが1によって索引をつけられる、SHOULD NOT、無索引をつけられます。 これはオールゼロ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バイトに擬似ランダムパターンを使用するRECOMMENDEDです。 下位の3バイトに擬似ランダム値を使用するのは、1670万のユニークなアドレスの1つを選ぶことを意味します。 このアドレス空間が現在研究室ベンチマーキングで必要とされるより広大に大きい間、それは、より現実的なテスト交通を保証します。
Newman & Player Informational [Page 7] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[7ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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には擬似ランダム値があるので偶然に放送かマルチキャスト値を手当たりしだいに発生させる可能性が全くないことに注意してください。
4.2.1. Randomized Sets of MAC Addresses
4.2.1. ランダマイズされたセットのMACアドレス
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アドレスをエミュレートするかもしれません。 これは上で「アドレスパターン変化」(論じ尽くすアルゴリズムはnonoptimal結果を作り出す)で説明されるように状況に通じます。
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:
アドレスのセットが擬似ランダム番号で始まっても、結果はnonoptimalであるかもしれません。 例えば、以下のソース/目的地組は以下の上で議論した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
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
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だけが達成されることに注意してください。 これは実際に最も良いそうです。 擬似ランダムアドレスの他の組み合わせから組を増加すると、1か8つの可能な結果のうちの2だけが生産されます。
Newman & Player Informational [Page 8] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[8ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
Every MAC address SHOULD be pseudorandom, not just the starting one.
あらゆるMACがSHOULDを記述します。始めのものだけではなく、擬似ランダムになってください。
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.
複数のアドレスで交通を発生させるとき、すべてのアドレスが擬似ランダム値を使用するのは、RECOMMENDEDです。 擬似乱数のセットを使用する複数の方法があります。 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だけではなくIEEE802MACとIPアドレスを使用するどんな装置のためにも)、テスターは、MACとIPアドレスの擬似ランダムセットを一度発生させるか、またはMACとIPアドレスの非ランダムセットを一度発生させるかもしれません。 どちらの場合ではも、すべてのトライアルに同じMACとIPアドレスを使用しなければなりません。
4.3. MPLS Addressing
4.3. MPLSアドレシング
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と104万8575の間の一様に無作為の値がテスト設備で割り当てられたすべてのラベルに使用されるのは、RECOMMENDEDです。 [RFC3032]に従って、これは、0-15の範囲で包括的に予約されたMPLSラベルを使用するのを避けます。
4.4. Network-layer Addressing
4.4. ネットワーク層アドレシング
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.
ルータが推進を唯一目的地ネットワーク・アドレスに基づく決定にするとき、ソースと送付先アドレスの衝突を論じ尽くす可能性が全くないかもしれません、より早く議論したイーサネットの切り換えに関するケースのように。 しかしながら、可能性はネットワーク層で衝突を論じ尽くすためにまだ存在しています、そして、テスト交通のネットワーク層コンテンツを作るとき、テスターSHOULDはこの可能性を考慮に入れます。
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
同じくらいが定義上複数のECMPルートでメートル法になるので、ルータはそれぞれリンクするために交通を割り当てるのにある他の「タイブレーク」メカニズムを使用します。 作者が意識している限り、ECMPリンク課題のためのどんな標準のアルゴリズムもありません。 いくつかの実現がIPがこれのために演説するソースと目的地のすべてのビットの細切れ肉料理を実行します。
Newman & Player Informational [Page 9] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[9ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
purpose. Others may perform a hash on one or more bytes in the source and destination IP addresses.
目的。 他のものは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アドレスに関するケースのように、ECMPの結果への悪影響は非ランダムIPアドレスで課題決定をリンクできます。
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かいかなる他のフォームのLayer3集合も実行するベンチマーキング装置であるときに、それは手当たりしだいに分配された範囲のIPアドレスを使用するRECOMMENDEDです。 特に、テスターSHOULD NOTはアドレス処理の望まれない効果を生むアドレスを使用します。 例えば、ソースと目的地ネットワーク・アドレスがx.x.R.x/24の形を取るときx.1.x/24、および比較的低いパケット損失をフォームx.に取るIPv4ネットワーク・アドレスを提供するとき(Rが0と9の間の何らかの無作為の値であるところ)、高いパケット損失を示すのをDUTを観測できるなら、テスト技術者SHOULDはランダム・パターンを使用します。
4.5. Transport-Layer Addressing
4.5. トランスポート層アドレシング
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ソース、および目的地ポートナンバーでパケットを発生させる能力があります。 知られている目的地ポートナンバーが、アプリケーション層の装置を検査するのにしばしば必要です。 しかしながら、知られているポートナンバーはテストに明確に必要でない場合、それがソースと目的地ポートナンバーの両方に擬似ランダムと一様に分散している値を使用するRECOMMENDEDです。
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の予約された目的地ポートナンバーの使用で包括的に自分たちを特定します。 特定のポートナンバーは必要でない場合、それがこれらの下側の、そして、上側の境界の間の手当たりしだいに分散している目的地ポートナンバーを選ぶRECOMMENDEDです。
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のスペースでソースに包括的にポートナンバーを通常選びます。 特定のポートナンバーは必要でない場合、それがこれらの下側の、そして、上側の境界の間の手当たりしだいに分散しているソースポートナンバーを選ぶRECOMMENDEDです。
4.6. Application-Layer Patterns
4.6. 応用層パターン
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-
多くの測定値が応用層ヘッダーとペイロードの挿入をテスト交通に必要とします。 応用層パケット含有量は、詰め物が現れる追加の機会を提供して、また、アプリケーションで食べさせられると、非ランダム結果を提示するかもしれません。
Newman & Player Informational [Page 10] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[10ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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.
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. Control Character Stuffing
5. Control Character Stuffing
5.1. Problem Statement
5.1. Problem Statement
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.
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.
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.
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.
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.
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.
Newman & Player Informational [Page 11] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 11] RFC 4814 Hash and Stuffing March 2007
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.
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.
5.2. PPP Bit-Stuffing
5.2. PPP Bit-Stuffing
[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], 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.
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.
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.
The contents of the various frame fields can be described one of three ways:
The contents of the various frame fields can be described one of three ways:
1. Field contents never change over the test duration. An example
would be the IP version number.
1. Field contents never change over the test duration. An example would be the IP version number.
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. 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.
3. Field contents may not be known. An example would be proprietary
payload fields in test packets.
3. Field contents may not be known. An example would be proprietary payload fields in test packets.
Newman & Player Informational [Page 12] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 12] RFC 4814 Hash and Stuffing March 2007
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)).
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)).
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) )) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
Newman & Player Informational [Page 13] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 13] RFC 4814 Hash and Stuffing March 2007
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.
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.
5.2.1. Calculating Bit-Stuffing Probability
5.2.1. Calculating Bit-Stuffing Probability
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.
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.
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.
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.
|--------------------<----------------------|
| |1
_______ __|__ _____ _____ _____ __|__
| | 1 | | 1 | | 1 | | 1 | | 1 | |
| start |--->| 1 |--->| 2 |--->| 3 |--->| 4 |--->| 5 |
|_______| |_____| |_____| |_____| |_____| |_____|
| | | | | | |
| |0 |0 |0 |0 |0 |0
|-<-|----<----|----<-----|----<-----|----<-----|----<-----|
|--------------------<----------------------| | |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".
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".
From this state diagram we can build the following transition matrix:
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
\ 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
Newman & Player Informational [Page 14] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 14] RFC 4814 Hash and Stuffing March 2007
With this transition matrix we can build the following system of equations. If P(x) represents the probability of reaching state x, then:
With this transition matrix we can build the following system of equations. If P(x) represents the probability of reaching state x, then:
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(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(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
P(start) + P(1) + P(2) + P(3) + P(4) + P(5) = 1
Solving this system of equations yields:
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(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.
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.2.2. Bit-Stuffing for Finite Strings
5.2.2. Bit-Stuffing for Finite Strings
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.
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.
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).
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).
A proof of this formula can be found in Appendix B.
A proof of this formula can be found in Appendix 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.
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.
Newman & Player Informational [Page 15] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 15] RFC 4814 Hash and Stuffing March 2007
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).
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).
5.2.3. Applied Bit-Stuffing
5.2.3. Applied Bit-Stuffing
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.
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.
% overhead = E[bit-stuffs] / framesize (in bits)
% overhead = E[bit-stuffs] / framesize (in bits)
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).
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).
The percentage given above is an approximation. For greatest precision, the actual intended load SHOULD be explicitly calculated from the test traffic.
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.
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.
5.3. POS Byte-Stuffing
5.3. POS Byte-Stuffing
[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] 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.
A common implementation of PPP in HDLC-like framing is in PPP over SONET/SDH (POS), as defined in [RFC2615].
A common implementation of PPP in HDLC-like framing is in PPP over SONET/SDH (POS), as defined in [RFC2615].
Newman & Player Informational [Page 16] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 16] RFC 4814 Hash and Stuffing March 2007
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.
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.
5.3.1. Nullifying ACCM
5.3.1. Nullifying ACCM
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.
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.
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.
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.
5.3.2. Other Stuffed Characters
5.3.2. Other Stuffed Characters
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.
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.
5.3.3. Applied Byte-Stuffing
5.3.3. Applied Byte-Stuffing
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.
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.
% overhead = E[byte-stuffs] / framesize (in bytes)
% overhead = E[byte-stuffs] / framesize (in bytes)
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.
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.
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.
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.
Newman & Player Informational [Page 17] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 17] RFC 4814 Hash and Stuffing March 2007
Note that the percentages given above are approximations. For greatest precision, the actual intended load SHOULD be explicitly calculated from the test traffic
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.
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.
6. Security Considerations
6. Security Considerations
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.
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.
[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], 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).
Newman & Player Informational [Page 18] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 18] RFC 4814 Hash and Stuffing March 2007
7. Normative References
7. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[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., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology
for LAN Switching Devices", RFC 2889, August 2000.
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
[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., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
Newman & Player Informational [Page 19] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 19] RFC 4814 Hash and Stuffing March 2007
Appendix A. Acknowledgements
Appendix A. Acknowledgements
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.
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.
Appendix B. Proof of Formula for Finite Bit-Stuffing
Appendix B. Proof of Formula for Finite Bit-Stuffing
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.
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.
Clearly, when 0 <= L <= 4, f(L) = 0, as there can be no possible bit- stuff if there are < 5 bits.
Clearly, when 0 <= L <= 4, f(L) = 0, as there can be no possible bit- stuff if there are < 5 bits.
Suppose L >= 5, then there is some number of strings that will cause stuffing events. Let us count them.
Suppose L >= 5, then there is some number of strings that will cause stuffing events. Let us count them.
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.
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.
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).
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).
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
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
Newman & Player Informational [Page 20] RFC 4814 Hash and Stuffing March 2007
Newman & Player Informational [Page 20] RFC 4814 Hash and Stuffing March 2007
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.
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.
Appendix C. Explicit Calculation of Bit-Stuffing Overhead for IPv4
Appendix C. Explicit Calculation of Bit-Stuffing Overhead for IPv4
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):
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):
+-----------------------+---------------------------+
| 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 |
+-----------------------+---------------------------+
+-----------------------+---------------------------+ | 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].
We want to calculate the expected number of stuffs per packet, or E[packet stuffs].
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.
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.
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.
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.
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に下落するのを示します。
Newman & Player Informational [Page 21] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[21ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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のため1パケットあたり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で得られた確率値を使用することによって、私たちはこの値に近似するつもりです。 その結果、[UDP]~0.465+8016/62Eの~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を四捨五入します。 したがって、私たちは1パケットあたり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%のオーバーヘッドを生産するでしょう。
Newman & Player Informational [Page 22] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[22ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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 |
+----------------------+----------------------------------+
+----------------------+----------------------------------+ | 分野| 値| +----------------------+----------------------------------+ | IPバージョン| 6 | | 交通のクラス| 0 | | 流れラベル| 擬似ランダムラベル| | ペイロード長| 1008 | | 次のヘッダー| 17 | | ホップ限界| 64 | | ソースIP| 2001: DB8: 0:1:、:1-2001: DB8: 0:1:、:ff| | 目的地IP| 2001: DB8: 0:2:、:10 | | ソースUDP港| 擬似ランダムポート| | 目的地UDP港| 擬似ランダムポート| | UDPの長さ| 1008 | | 有効搭載量| 1000擬似ランダムバイト| +----------------------+----------------------------------+
We want to calculate the expected number of stuffs per packet, or E[packet stuffs].
1パケットあたりのものの予想された数、または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アドレスのため1パケットあたり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.
また、私たちは擬似ランダムに発生している流れラベルを考えなければなりません。 しかしながら、私たちのTraffic Class分野が0であり、私たちの有効搭載量Length分野が32768(その結果、有効搭載量Length分野の主なビットは0である)未満であるので、私たちは、流れラベルが20ビットの無作為のデータであるとみなすかもしれません。 したがって、流れラベルのものへの期待はf(20)/2^20~.272です。
Newman & Player Informational [Page 23] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[23ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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.
UDP長さの分野が32768未満である、上の流れラベルケースと同様です、私たちの送付先IPアドレスの4番目の回路が同等であるので、私たちに境界ビットを考えさせないで、無作為のソースと仕向港は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を四捨五入します。 したがって、私たちは1パケットあたり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手当たりしだいに分散している結果があるなら、N発生可能性における1がどんな個々の結果にもあります。
Newman & Player Informational [Page 24] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[24ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
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.
制御文字への混乱を避けるフレームの中のしばらくかバイトの挿入。 例えば、RFC1662がaの挿入を必要とする、「5隣接の「HDLC制御文字0x7Eへの混乱を避けるフレームの中の1インチのビット」のどんな系列の前にも噛み付かれた0インチ
Authors' Addresses
作者のアドレス
David Newman Network Test
デヴィッドニューマンネットワークTest
EMail: dnewman@networktest.com
メール: dnewman@networktest.com
Timmons C. Player Spirent Communications
ティモンズC.プレーヤーSpirentコミュニケーション
EMail: timmons.player@spirent.com
メール: timmons.player@spirent.com
Newman & Player Informational [Page 25] RFC 4814 Hash and Stuffing March 2007
ニューマンとプレーヤーの情報[25ページ]のRFC4814細切れ肉料理と2007年3月を詰めること。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Newman & Player Informational [Page 26]
ニューマンとプレーヤー情報です。[26ページ]
一覧
スポンサーリンク
