Network Working Group D. Newman
Request for Comments: 4814 Network Test
Category: Informational T. Player
Spirent Communications
March 2007
Network Working Group D. Newman
Request for Comments: 4814 Network Test
Category: Informational T. Player
Spirent Communications
March 2007
Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
散列和填充：网络设备基准测试中被忽视的因素
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic.
测试工程师努力声明影响给定测量的所有因素，包括预期负载、数据包长度、测试持续时间和流量方向。然而，当前的基准测试实践忽略了对测试结果有深远影响的两个因素。首先，现有的方法不需要报告地址或其他测试流量内容，即使这些字段会影响测试结果。其次，一些链路层技术在测试流量中插入的“填充”位和字节增加了显著的可变开销，这反过来会影响测试结果。本文件描述了这些因素的影响；建议测试流量内容的指南；并提供了确定测试流量中位和字节填充概率的公式。
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Considerations . . . . . . . . . . . . . . . . . . . . 4
3.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Randomness . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Content Variations . . . . . . . . . . . . . . . . . . 5
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
4.2. IEEE 802 MAC Addresses . . . . . . . . . . . . . . . . . . 7
4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 8
4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 9
4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 9
4.5. Transport-Layer Addressing . . . . . . . . . . . . . . . . 10
4.6. Application-Layer Patterns . . . . . . . . . . . . . . . . 10
5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 11
5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 11
5.2. PPP Bit-Stuffing . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 14
5.2.2. Bit-Stuffing for Finite Strings . . . . . . . . . . . 15
5.2.3. Applied Bit-Stuffing . . . . . . . . . . . . . . . . . 16
5.3. POS Byte-Stuffing . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 17
5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 17
5.3.3. Applied Byte-Stuffing . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Appendix B. Proof of Formula for Finite Bit-Stuffing . . . . . . 20
Appendix C. Explicit Calculation of Bit-Stuffing Overhead for
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix D. Explicit Calculation of Bit-Stuffing Overhead for
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix E. Terminology . . . . . . . . . . . . . . . . . . . . . 24
Experience in benchmarking networking devices suggests that the contents of test traffic can have a profound impact on test results. For example, some devices may forward randomly addressed traffic without loss, but drop significant numbers of packets when offered packets containing nonrandom addresses.
对网络设备进行基准测试的经验表明，测试流量的内容会对测试结果产生深远的影响。例如，一些设备可以转发随机寻址的流量而不丢失，但是当提供的数据包包含非随机地址时，会丢弃大量数据包。
Methodologies such as [RFC2544] and [RFC2889] do not require any declaration of packet contents. These methodologies do require the declaration of test parameters such as traffic distribution and traffic orientation, and yet packet contents can have at least as great an impact on test results as the other factors. Variations in packet contents also can lead to non-repeatability of test results: Two individuals may follow methodology procedures to the letter, and still obtain very different results.
[RFC2544]和[RFC2889]等方法不需要任何数据包内容声明。这些方法确实需要声明测试参数，如流量分布和流量方向，但是数据包内容对测试结果的影响至少与其他因素一样大。数据包内容的变化也可能导致测试结果的不可重复性：两个人可能严格遵循方法程序，但仍然获得非常不同的结果。
A related issue is the insertion of stuff bits or bytes by link-layer technologies using PPP with High-Level Data Link Control (HDLC)-like framing. This stuffing is done to ensure sequences in test traffic will not be confused with control characters.
一个相关的问题是使用PPP和类似于HDLC的帧结构，通过链路层技术插入填充位或字节。这种填充是为了确保测试流量中的序列不会与控制字符混淆。
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.
本文件涵盖两个领域。首先，我们讨论了在测试流量中处理随机性和非随机性的策略。其次，我们给出了确定点对点协议（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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Repeatability is a desirable trait in benchmarking, but it can be an elusive goal. It is a common but mistaken belief that test results can always be recreated provided the device under test and test instrument are configured identically for each test iteration. In fact, even identical configurations may introduce some variations in test traffic, such as changes in timestamps, TCP sequence numbers, or other common phenomena.
重复性在基准测试中是一个可取的特性，但它可能是一个难以实现的目标。人们普遍错误地认为，只要被测设备和测试仪器在每次测试迭代中配置相同，测试结果总是可以重新创建的。事实上，即使相同的配置也可能在测试流量中引入一些变化，例如时间戳、TCP序列号或其他常见现象的变化。
While this variability does not necessarily invalidate test results, it is important to recognize the existing variation. Exact bit-for-bit repeatability of test traffic is a hard problem. A simpler approach is to acknowledge that some variation exists, characterize that variation, and describe it when analyzing test results.
虽然这种变化不一定会使测试结果无效，但重要的是要识别现有的变化。测试流量的精确逐位重复性是一个难题。一种更简单的方法是承认存在某些变化，描述该变化，并在分析测试结果时对其进行描述。
Another issue related to repeatability is the avoidance of randomness in test traffic. For example, benchmarking experience with some IEEE 802.11 devices suggests that nonrandom media access control (MAC) and IP addresses must be used across multiple trials. Although this would seem to contradict some recommendations made in this document, in fact either nonrandom or pseudorandom patterns may be more desirable depending on the test setup. There are also situations where it may be desirable to use combinations of the two, for example by generating pseudorandom traffic patterns for one test trial and then re-using the same pattern across all trials. The keywords in this document are RECOMMENDs and not MUSTs with regard to the use of pseudorandom test traffic patterns.
与重复性相关的另一个问题是避免测试流量中的随机性。例如，一些IEEE 802.11设备的基准测试经验表明，必须在多次试验中使用非随机媒体访问控制（MAC）和IP地址。尽管这似乎与本文中提出的一些建议相矛盾，但实际上，根据测试设置，非随机或伪随机模式可能更可取。还有一些情况下，可能需要使用这两种模式的组合，例如，通过为一次试验生成伪随机交通模式，然后在所有试验中重新使用相同的模式。本文档中的关键字是关于伪随机测试流量模式使用的推荐关键字，而非必须关键字。
Note also that this discussion covers only repeatability, which is concerned with variability of test results from trial to trial on the same test bed. A separate concern is reproducibility, which refers to the precision of test results obtained from different test beds. Clearly, reproducibility across multiple test beds requires repeatability on a single test bed.
还应注意，本讨论仅涉及重复性，即在同一试验台上进行的不同试验的试验结果的可变性。另一个问题是再现性，它是指从不同试验台获得的试验结果的精度。显然，多个试验台的再现性要求在单个试验台上具有重复性。
This document recommends the use of pseudorandom patterns in test traffic under controlled lab conditions. The rand() functions available in many programming languages produce output that is pseudorandom rather than truly random. Pseudorandom patterns are sufficient for the recommendations given in this document, provided they produce output that is uniformly distributed across the pattern space.
本文档建议在受控实验室条件下的测试流量中使用伪随机模式。许多编程语言中可用的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的任何随机比特模式，生成该特定模式的概率应等于1乘以2的Lth次方。
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:
考虑在交换机结构中具有八个网络处理器（NPS）的以太网交换机的简单情况：
ingress
||
\/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ___ ___ ___ ___ ___ ___ ___ ___ |
|| | | | | | | | | | | | | | | | |
||NP0| |NP1| |NP2| |NP3| |NP4| |NP5| |NP6| |NP7| |
||___| |___| |___| |___| |___| |___| |___| |___| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||
\/
egress
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.)
为了将传入流量分配给各种NPs，假设散列算法对每个帧中源MAC地址和目标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地址和目标MAC地址的随机分布应导致流量均匀分布在所有八个NPs上。（本文档中术语“随机”的实例是指在给定地址空间中的随机均匀分布。第3.2节更详细地描述了随机均匀分布。）在实践中，散列的实际结果（以及因此产生的任何测试结果）将因测试流量的随机程度而大不相同。
Suppose the traffic is nonrandom so that every interface of the test instrument uses this pattern in its source MAC addresses:
假设通信量是非随机的，因此测试仪器的每个接口在其源MAC地址中使用此模式：
00:00:PP:00:00:01
00:00:PP:00:00:01
where PP is the source interface number of the test instrument.
式中，PP是测试仪器的源接口号。
In this case, the least significant 3 bits of every source and destination MAC address are 001, regardless of interface number. Thus, the outcome of the XOR operation will always be 0, given the same three least significant bits:
在这种情况下，不管接口号如何，每个源和目标MAC地址的最低有效3位都是001。因此，给定相同的三个最低有效位，异或操作的结果将始终为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.
因此，交换机将所有通信量分配给NP0，使其他七个NPs处于空闲状态。如果负载足够重，NP0和交换机将变得拥挤，即使有七个其他NPs可用。该设备最多可利用其总容量的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（包括000到111）的任何值的概率应该相等。因此，异或运算的结果应该平均分布在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基准工作组（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
(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 and，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.
MAC地址中高阶字节与0xFC的按位ANDing将该字节的低阶两位设置为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地址用于接口标识，允许测试多达65536个接口。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接口号可能发生变化的情况；一个例子是无线局域网漫游测试。通过参考测试仪器的（可能是静态的）源接口号，测试工程师可以跟踪测试流量，而不考虑任何可能的DUT/SUT变化。
Further, source interface numbers SHOULD be 1-indexed and SHOULD NOT be zero-indexed. This avoids the low but nonzero probability of an all-zeros MAC address. Some devices will drop frames with all-zeros MAC addresses.
此外，源接口号应为1索引，而不应为零索引。这避免了全零MAC地址的低概率但非零概率。有些设备会丢弃MAC地址为全零的帧。
It is RECOMMENDED to use pseudorandom patterns in the least significant 3 bytes of the MAC address. Using pseudorandom values for the low-order 3 bytes means choosing one of 16.7 million unique addresses. While this address space is vastly larger than is currently required in lab benchmarking, it does assure more realistic test traffic.
建议在MAC地址的最低有效3字节中使用伪随机模式。对低阶3字节使用伪随机值意味着从1670万个唯一地址中选择一个。虽然这个地址空间远远大于目前实验室基准测试所需的空间，但它确实确保了更现实的测试流量。
Note also that since only 30 of 48 bits in the MAC address have pseudorandom values, there is no possibility of randomly generating a broadcast or multicast value by accident.
还要注意，由于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
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.
请注意，在递增地址时，八种可能的结果中只有三种是可以实现的。这实际上是最好的情况。从其他伪随机地址对组合中递增只能产生八个可能结果中的一个或两个。
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.
使用多个地址生成流量时，建议所有地址使用伪随机值。使用伪随机数集有多种方法。一种策略是测试工具迭代伪随机值数组，而不是从起始地址递增/递减。实际方法是一个实现细节；最后，任何使用带有伪随机模式的多个地址的方法都足够了。
Experience with benchmarking of IEEE 802.11 devices suggests suboptimal test outcomes may result if different pseudorandom MAC and IP addresses are used from trial to trial. In such cases (not just for 802.11 but for any device using IEEE 802 MAC and IP addresses), testers MAY generate a pseudorandom set of MAC and IP addresses once, or MAY generate a nonrandom set of MAC and IP addresses once. In either case, the same MAC and IP addresses MUST be used in all trials.
IEEE 802.11设备的基准测试经验表明，如果在不同的试验中使用不同的伪随机MAC和IP地址，可能会导致次优的测试结果。在这种情况下（不仅对于802.11，而且对于使用IEEE 802 MAC和IP地址的任何设备），测试人员可以生成一次MAC和IP地址的伪随机集，或者可以生成一次MAC和IP地址的非随机集。无论哪种情况，在所有试验中都必须使用相同的MAC和IP地址。
Similar to L2 switches, multiprotocol label switching (MPLS) devices make forwarding decisions based on a 20-bit MPLS label. Unless specific labels are required, it is RECOMMENDED that uniformly random values between 16 and 1,048,575 be used for all labels assigned by test equipment. As per [RFC3032], this avoids using reserved MPLS labels in the range of 0-15 inclusive.
与L2交换机类似，多协议标签交换（MPLS）设备根据20位MPLS标签做出转发决策。除非需要特定标签，否则建议对试验设备指定的所有标签使用16到1048575之间的统一随机值。根据[RFC3032]，这避免了使用0-15（含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
由于根据定义，多个ECMP路由具有相同的度量，路由器使用其他一些“平局断路器”机制将流量分配给每个链路。据作者所知，ECMP链路分配没有标准算法。一些实现对源IP地址和目标IP地址的所有位执行哈希
purpose. Others may perform a hash on one or more bytes in the source and destination IP addresses.
意图其他人可能会对源和目标IP地址中的一个或多个字节执行哈希。
Just as in the case of MAC addresses, nonrandom IP addresses can have an adverse effect on the outcome of ECMP link assignment decisions.
与MAC地址的情况一样，非随机IP地址可能会对ECMP链路分配决策的结果产生不利影响。
When benchmarking devices that implement ECMP or any other form of Layer 3 aggregation, it is RECOMMENDED to use a randomly distributed range of IP addresses. In particular, testers SHOULD NOT use addresses that produce the undesired effects of address processing. If, for example, a DUT can be observed to exhibit high packet loss when offered IPv4 network addresses that take the form x.x.1.x/24, and relatively low packet loss when the source and destination network addresses take the form of x.x.R.x/24 (where R is some random value between 0 and 9), test engineers SHOULD use the random pattern.
当对实现ECMP或任何其他形式的第3层聚合的设备进行基准测试时，建议使用随机分布的IP地址范围。特别是，测试人员不应该使用产生地址处理不良效果的地址。例如，如果可以观察到DUT在提供形式为x.x.1.x/24的IPv4网络地址时表现出较高的丢包率，而在源和目标网络地址形式为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（含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的高级数据链路控制（High Level Data Link Control，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.
这些转义序列的开销有两个原因。首先，对于某些类型的测试流量，显式地计算开销量可能非常重要，甚至是不可能的。在这种情况下，测试人员所能做的最好的事情就是描述给定模式发生逃逸序列的概率。这使得准确声明向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帧引入两种转义序列：位和字节填充。位填充是指在位同步链路上插入转义位。字节填充是指在字节同步链接上插入转义字节。我们依次讨论每一个问题。
[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”位来转义帧内五个连续“1”位的任何序列。此转义是必要的，以避免与包含六个“1”位的HDLC控制字符0x7E混淆。
Consider the following PPP frame containing a TCP/IP packet. Not shown is the 1-byte flag sequence (0x7E), at least one of which must occur between frames.
考虑下面的包含TCP/IP包的PPP帧。未显示1字节标志序列（0x7E），其中至少一个必须出现在帧之间。
The contents of the various frame fields can be described one of three ways:
各种帧字段的内容可以通过以下三种方式之一进行描述：
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) )) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
为了计算位填充概率，我们假设对于长度为L的任何字符串，其中b_n表示该字符串的第n位，且1<=n<=L，b_n等于“1”的概率为0.5，b_n等于“0”的概率为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
|-<-|----<----|----<-----|----<-----|----<-----|----<-----|
|--------------------<----------------------|
| |1
_______ __|__ _____ _____ _____ __|__
| | 1 | | 1 | | 1 | | 1 | | 1 | |
| start |--->| 1 |--->| 2 |--->| 3 |--->| 4 |--->| 5 |
|_______| |_____| |_____| |_____| |_____| |_____|
| | | | | | |
| |0 |0 |0 |0 |0 |0
|-<-|----<----|----<-----|----<-----|----<-----|----<-----|
Initially, we begin in the "start" state. A "1" bit moves us into the next highest state, and a "0" bit returns us to the start state. From state 5, a "1" bit takes us back to the 1 state and a "0" bit returns us to "start".
最初，我们从“开始”状态开始。“1”位将我们移动到下一个最高状态，“0”位将我们返回到开始状态。从状态5开始，“1”位将我们带回1状态，“0”位将我们返回“开始”。
From this state diagram we can build the following transition matrix:
根据该状态图，我们可以构建以下转换矩阵：
\ To |
\ |
\ |
From \ | start 1 2 3 4 5
______\|_________________________________________________
start | 0.5 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0
1 | 0.5 | 0.0 | 0.5 | 0.0 | 0.0 | 0.0
2 | 0.5 | 0.0 | 0.0 | 0.5 | 0.0 | 0.0
3 | 0.5 | 0.0 | 0.0 | 0.0 | 0.5 | 0.0
4 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0 | 0.5
5 | 0.5 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0
\ 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(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:
求解该方程组可得出：
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.
因此，对于一个无限长的均匀随机比特串，任何单个比特导致转换到状态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的均匀随机有限位字符串，我们可以显式计算长度为L的所有可能字符串集合中的位填充数。然后可以使用此计数计算字符串的预期填充数。
Let f(L) represent the number of bit-stuffs in the set of all possible strings of length L. Clearly, for 0 <= L <= 4, f(L) = 0 as there are no strings of length 5. For L >= 5, f(L) = 2^(L-5) + (L-5) * 2^(L-6) + f(L-5).
设f（L）表示长度为L的所有可能字符串集合中的位填充数。显然，对于0<=L<=4，f（L）=0，因为没有长度为5的字符串。对于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[Stuff]。因此，对于任何L，E[stuff]=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，L n（其中5<=n<=L）导致填充的概率为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来近似E[比特填充]。
% 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).
鉴于位填充增加的开销约为1/62或1.6%，建议测试人员将最大预期负载减少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）中标记的任何八位字节替换为两个八位字节序列，该序列由控制转义八位字节和原始八位字节（十六进制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].
HDLC类帧中PPP的常见实现是SONET/SDH（POS）上的PPP，如[RFC2615]中所定义。
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.
测试人员可以通过配置链接伙伴协商ACCM值0x00，大大降低字节填充的可能性。建议测试人员将测试仪器和DUT/SUT配置为协商ACCM值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.
使用非零ACCM值的一个实例是第2层隧道协议（L2TP），如[RFC2661]第4.4.6节所定义。使用默认ACCM值时，任意给定随机字节的填充概率为34/256，约为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.
如果协商的ACCM值为0x00，则唯一需要填充的字符是标志和控件转义字符。因此，我们可以说，在没有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）中实现PPP的DUT/SUT（或使用非零ACCM值的任何其他技术）时，建议测试人员将最大预期负载降低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类帧中实现PPP且ACCM值为0x00的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）”，标准51，RFC1661，1994年7月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]辛普森，W，“HDLC类框架中的PPP”，标准51，RFC1662，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，“SONET/SDH上的PPP”，RFC 26151999年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]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
[RFC2889]Mandeville，R.和J.Perser，“局域网交换设备的基准测试方法”，RFC 2889，2000年8月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，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.
作者衷心感谢Tom Alexander、Len Ciavattone、Robert Craig、John Dawson、Neil Carter、Glen Chagnot、Kevin Dubrey、Diego Dugatkin、Rafael Francis、Paul Hoffman、David Joyner、Al Morton、Joe Perches、Jerry Perser、Scott Poretsky、Dan Romascanu和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.
我们想要构造一个函数f（L），它允许我们显式地计算长度为L的所有字符串集合中位填充的总数。让我们表示长度为L的位字符串。此外，让b_n为字符串S的第n位，其中1<=n<=L。
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.
我们首先计算将导致至少一位内容的字符串的数量。让我们假设前5位b_1，…，b_5导致填充事件。然后，有（L-5）位可以有任何值，即，位置b_6到b_L的位。因此，必须有2^（L-5）个字符串，其中前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）处。因此，总共有6位必须在字符串S中具有固定值，并且总共有L-6位没有固定值。因此，对于n的每个值，总共有2^（L-6）个可能的字符串，其中至少有一个位填充（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
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的所有位串的集合可以表示为f（L）=2^（L-5）+（L-5）*2^（L-6）+f（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 |
+-----------------------+---------------------------+
+-----------------------+---------------------------+
| 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源地址中第四个八位字节的改变会产生偶尔的比特填充事件，所以我们必须枚举这些事件。此外，我们必须考虑到源IP的第三个八位组和目标IP的第一个八位组将影响填充的发生。
An exhaustive search shows that cycling through all 254 headers produces 51 bit-stuffs for the destination IP address. This gives us an expectation of 51/254 stuffs per packet due to the changing source IP address.
彻底搜索显示，在所有254个报头之间循环会为目标IP地址生成51位的填充。由于源IP地址的变化，我们期望每个数据包有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）。现在，^46f/32的计算难度太大了。然而，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测试包。测试流量具有以下参数（除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 |
+----------------------+----------------------------------+
+----------------------+----------------------------------+
| Field | Value |
+----------------------+----------------------------------+
| IP Version | 6 |
| Traffic Class | 0 |
| Flow Label | pseudorandom label |
| Payload Length | 1008 |
| Next Header | 17 |
| Hop Limit | 64 |
| Source IP | 2001:DB8:0:1::1-2001:DB8:0:1::FF |
| Destination IP | 2001:DB8:0:2::10 |
| Source UDP Port | pseudorandom port |
| Destination UDP Port | pseudorandom port |
| UDP Length | 1008 |
| Payload | 1000 pseudorandom bytes |
+----------------------+----------------------------------+
We want to calculate the expected number of stuffs per packet, or E[packet stuffs].
我们要计算每个数据包的预期填充数，或E[数据包填充]。
First, we observe that we have 255 different IP headers to consider, and secondly, that the changing 4th quad in the IP source addresses will produce occasional bit-stuffing events, so we must enumerate these occurrences. Additionally, we also note that since the first quad of the destination address has a leading zero bit, we do no have to consider these adjacent bits when calculating the number of bit-stuffs in the source IP address.
首先，我们观察到我们有255个不同的IP报头要考虑，第二，IP源地址中第四个四元组的改变会产生偶尔的比特填充事件，所以我们必须枚举这些事件。此外，我们还注意到，由于目的地地址的第一个四元组具有领先的零位，所以当计算源IP地址中的比特数时，我们不必考虑这些相邻位。
An exhaustive search shows that cycling through all 255 headers produces 20 bit-stuffs for the source IP address. This gives us an expectation of 20/255 stuffs per packet due to the changing source IP address.
彻底搜索显示，循环遍历所有255个标头会为源IP地址生成20位的填充。由于源IP地址的变化，我们期望每个数据包有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地址的第四个偶数是偶数，并且UDP长度字段小于32768，因此随机源和目的端口提供32位顺序随机数据，而不强迫我们考虑边界位。此外，我们将假设由于我们的有效负载是伪随机的，因此我们的UDP CRC也将是伪随机的。偶数UDP长度字段再次允许我们只考虑在CRC和数据字段中显式包含的位。因此，使用第5.2.2节中有限字符串中的预期填充数公式，我们确定E[UDP填充]=f（32）/2^32+f（8000+16）/2^（8000+16）。现在，^46f/32的计算难度太大了。然而，f（8016）/2^8016有点大，易于计算，因此我们将使用第5.2.1节中获得的概率值来近似该值。因此，E[UDP stuff]~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地址和目标MAC地址作为哈希函数的输入。哈希函数生成数字输出，告诉交换机在转发帧时使用哪个处理元素。
Randomness
随机性
In the context of this document, the quality of having an equal probability of any possible outcome for a given pattern space. For example, if an experiment has N randomly distributed outcomes, then any individual outcome has a 1 in N probability of occurrence.
在本文件的上下文中，给定模式空间中任何可能结果的概率相等的质量。例如，如果一个实验有N个随机分布的结果，那么任何单个结果都有1/N的发生概率。
Repeatability
重复性
The precision of test results obtained on a single test bed, but from trial to trial. See also "reproducibility".
在单个试验台上获得的试验结果的精度，但从一个试验到另一个试验。另见“再现性”。
Reproducibility
再现性
The precision of test results between different setups, possibly at different locations. See also "repeatability".
不同设置（可能在不同位置）之间测试结果的精度。另见“重复性”。
Stuffing
填料
The insertion of a bit or byte within a frame to avoid confusion with control characters. For example, RFC 1662 requires the insertion of a "0" bit prior to any sequence of five contiguous "1" bits within a frame to avoid confusion with the HDLC control character 0x7E.
在帧内插入位或字节以避免与控制字符混淆。例如，RFC 1662要求在帧内五个连续“1”位的任何序列之前插入“0”位，以避免与HDLC控制字符0x7E混淆。
Authors' Addresses
作者地址
David Newman Network Test
大卫纽曼网络测试
EMail: dnewman@networktest.com
EMail: dnewman@networktest.com
Timmons C. Player Spirent Communications
Timmons C.Player Spirent Communications
EMail: timmons.player@spirent.com
EMail: timmons.player@spirent.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。