draft-ietf-bmwg-hash-stuffing-03.txt   draft-ietf-bmwg-hash-stuffing-04.txt 
Network Working Group D. Newman Network Working Group D. Newman
Internet-Draft Network Test Internet-Draft Network Test
Expires: December 23, 2005 T. Player Expires: April 11, 2006 T. Player
Spirent Communications Spirent Communications
June 21, 2005 October 8, 2005
Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
draft-ietf-bmwg-hash-stuffing-03.txt draft-ietf-bmwg-hash-stuffing-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2005. This Internet-Draft will expire on April 11, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Test engineers take pains to declare all factors that affect a given Test engineers take pains to declare all factors that affect a given
measurement, including offered load, packet length, test duration, measurement, including offered load, packet length, test duration,
and traffic orientation. However, current benchmarking practice and traffic orientation. However, current benchmarking practice
skipping to change at page 2, line 15 skipping to change at page 2, line 15
variable overhead, which in turn affects test results. This document variable overhead, which in turn affects test results. This document
describes the effects of these factors; recommends guidelines for describes the effects of these factors; recommends guidelines for
test traffic contents; and offers formulas for determining the test traffic contents; and offers formulas for determining the
probability of bit- and byte-stuffing in test traffic. probability of bit- and byte-stuffing in test traffic.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General considerations . . . . . . . . . . . . . . . . . . . . 5 3. General considerations . . . . . . . . . . . . . . . . . . . . 5
3.1 Repeatability . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Randomness . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Address Pattern Variations . . . . . . . . . . . . . . . . . . 6 4. Address Pattern Variations . . . . . . . . . . . . . . . . . . 6
4.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 6 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6
4.2 Ethernet MAC Addresses . . . . . . . . . . . . . . . . . . 7 4.2. Ethernet MAC Addresses . . . . . . . . . . . . . . . . . . 7
4.2.1 Randomized Sets of MAC Addresses . . . . . . . . . . . 8 4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 8
4.3 MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 10 4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 10
4.4 Network-layer Addressing . . . . . . . . . . . . . . . . . 10 4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 10
4.5 Transport-layer Addressing . . . . . . . . . . . . . . . . 10 4.5. Transport-layer Addressing . . . . . . . . . . . . . . . . 10
5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 12 5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 12
5.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 12 5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 12
5.2 PPP Bit Stuffing . . . . . . . . . . . . . . . . . . . . . 12 5.2. PPP Bit Stuffing . . . . . . . . . . . . . . . . . . . . . 12
5.2.1 Calculating Bit-Stuffing Probability . . . . . . . . . 14 5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 14
5.2.2 Bit Stuffing for Finite Strings . . . . . . . . . . . 15 5.2.2. Bit Stuffing for Finite Strings . . . . . . . . . . . 15
5.2.3 Applied Bit Stuffing . . . . . . . . . . . . . . . . . 15 5.2.3. Applied Bit Stuffing . . . . . . . . . . . . . . . . . 15
5.3 POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 16 5.3. POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 16
5.3.1 Nullifying ACCM . . . . . . . . . . . . . . . . . . . 16 5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 16
5.3.2 Other Stuffed Characters . . . . . . . . . . . . . . . 17 5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 17
5.3.3 Applied Byte Stuffing . . . . . . . . . . . . . . . . 17 5.3.3. Applied Byte Stuffing . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2 Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
Experience in benchmarking networking devices suggests that the Experience in benchmarking networking devices suggests that the
contents of test traffic can have a profound impact on test results. contents of test traffic can have a profound impact on test results.
For example, some devices may forward randomly addressed traffic For example, some devices may forward randomly addressed traffic
without loss, but drop significant numbers of packets when offered without loss, but drop significant numbers of packets when offered
packets containing nonrandom addresses. packets containing nonrandom addresses.
Methodologies such as [RFC2544] and [RFC2889] do not require any Methodologies such as [RFC2544] and [RFC2889] do not require any
skipping to change at page 5, line 7 skipping to change at page 5, line 7
recommendations for obtaining more repeatability in test results. recommendations for obtaining more repeatability in test results.
2. Requirements 2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. General considerations 3. General considerations
3.1 Repeatability 3.1. Repeatability
Repeatability is a desirable trait in benchmarking, but it can be an Repeatability is a desirable trait in benchmarking, but it can be an
elusive goal. It is a common but mistaken belief that test results elusive goal. It is a common but mistaken belief that test results
can always be reproduced provided the device under test and test can always be reproduced provided the device under test and test
instrument are configured identically for each test iteration. In instrument are configured identically for each test iteration. In
fact, even identical configurations may introduce some variations in fact, even identical configurations may introduce some variations in
test traffic, such as changes in timestamps, TCP sequence numbers, or test traffic, such as changes in timestamps, TCP sequence numbers, or
other naturally occurring phenomena. other naturally occurring phenomena.
While this variability does not necessarily invalidate test results, While this variability does not necessarily invalidate test results,
it is important to recognize such variation exists. Exact bit-for- it is important to recognize such variation exists. Exact bit-for-
bit reproduction of test traffic in all cases is a hard problem. A bit reproduction of test traffic in all cases is a hard problem. A
simpler approach is to acknowledge that some variation exists, simpler approach is to acknowledge that some variation exists,
characterize that variation, and describe it when analyzing test characterize that variation, and describe it when analyzing test
results. results.
3.2 Randomness 3.2. Randomness
This document recommends the use of pseudorandom patterns in test This document recommends the use of pseudorandom patterns in test
traffic under controlled lab conditions. The rand() functions traffic under controlled lab conditions. The rand() functions
available in many programming languages produce output that is available in many programming languages produce output that is
pseudorandom rather than truly random. Pseudorandom patterns are pseudorandom rather than truly random. Pseudorandom patterns are
sufficient for the recommendations given in this document, provided sufficient for the recommendations given in this document, provided
they produce output that is uniformly distributed across the pattern they produce output that is uniformly distributed across the pattern
space. space.
Specifically, for any random bit pattern of length L, the probability Specifically, for any random bit pattern of length L, the probability
of generating that specific pattern SHOULD equal 1 over 2 to the Lth of generating that specific pattern SHOULD equal 1 over 2 to the Lth
power. power.
4. Address Pattern Variations 4. Address Pattern Variations
4.1 Problem Statement 4.1. Problem Statement
The addresses and port numbers used in a test can have a significant The addresses and port numbers used in a test can have a significant
impact on metrics such as throughput, jitter, latency, and loss. impact on metrics such as throughput, jitter, latency, and loss.
This is because many network devices feed such addresses into hashing This is because many network devices feed such addresses into hashing
algorithms to determine which path upon which to forward a given algorithms to determine which path upon which to forward a given
packet. packet.
Consider the simple example of an Ethernet switch with eight network Consider the simple example of an Ethernet switch with eight network
processors (NPs) in its switching fabric: processors (NPs) in its switching fabric:
skipping to change at page 7, line 46 skipping to change at page 7, line 46
hashing algorithm used by the device under test. Knowledge of such hashing algorithm used by the device under test. Knowledge of such
algorithms is not always possible beforehand, and in any event algorithms is not always possible beforehand, and in any event
violates the "black box" spirit of many documents produced by the violates the "black box" spirit of many documents produced by the
IETF BMWG. IETF BMWG.
The balance of this section offers recommendations for test traffic The balance of this section offers recommendations for test traffic
patterns, starting at the link layer and working up to the transport patterns, starting at the link layer and working up to the transport
layer. These patterns should overcome the effects of nonrandomness layer. These patterns should overcome the effects of nonrandomness
regardless of the hashing algorithms in use. regardless of the hashing algorithms in use.
4.2 Ethernet MAC Addresses 4.2. Ethernet MAC Addresses
Test traffic SHOULD use pseudorandom patterns in Ethernet addresses.
The following source and destination Ethernet address pattern is The following source and destination Ethernet address pattern is
RECOMMENDED for use when benchmarking Ethernet devices: RECOMMENDED for use when benchmarking Ethernet devices:
(RR & 0xFE):PP:PP:RR:RR:RR (RR & 0xFE):PP:PP:RR:RR:RR
where (RR & 0xFE) is a pseudorandom number bitwise ANDed with 0xFE, where (RR & 0xFE) is a pseudorandom number bitwise ANDed with 0xFE,
PP:PP is the interface number of the test instrument and RR:RR:RR is PP:PP is the 1-indexed interface number of the test instrument and
a pseudorandom number. RR:RR:RR is a pseudorandom number.
The bitwise ANDing of the high-order byte in the MAC address with The bitwise ANDing of the high-order byte in the MAC address with
0xFE guarantees a non multicast address. 0xFE guarantees a non multicast address.
It is RECOMMENDED to use PP:PP to identify the source interface Test traffic SHOULD use PP:PP to identify the source interface number
number of the test instrument. Such identification can be useful in of the test instrument. Such identification can be useful in
troubleshooting. Allocating 2 bytes of the MAC address for interface troubleshooting. Allocating 2 bytes of the MAC address for interface
identification allows for tests of up to 65,536 interfaces. A 2-byte identification allows for tests of up to 65,536 interfaces. A 2-byte
space allows for tests much larger than those currently used in space allows for tests much larger than those currently used in
device benchmarking; however, tests involving more than 256 device benchmarking; however, tests involving more than 256
interfaces (fully utilizing a 1-byte space) are fairly common. interfaces (fully utilizing a 1-byte space) are fairly common.
Further, source interface numbers SHOULD be 1-indexed and SHOULD NOT
be 0-indexed. This avoids the low but nonzero probability of an
all-0s Ethernet address. Some devices will drop frames with all-0s
Ethernet addresses.
It is RECOMMENDED to use pseudorandom patterns in the least It is RECOMMENDED to use pseudorandom patterns in the least
significant 3 bytes of the MAC address. Using pseudorandom values significant 3 bytes of the MAC address. Using pseudorandom values
for the low-order 3 bytes means choosing one of 16.7 million unique for the low-order 3 bytes means choosing one of 16.7 million unique
addresses. While this address space is vastly larger than is addresses. While this address space is vastly larger than is
currently required in lab benchmarking, it does assure more realistic currently required in lab benchmarking, it does assure more realistic
test traffic. test traffic.
Note also that since only 31 of 48 bits in the MAC address have Note also that since only 31 of 48 bits in the MAC address have
pseudorandom values, there is no possibility of randomly generating a pseudorandom values, there is no possibility of randomly generating a
broadcast or multicast value by accident. broadcast or multicast value by accident.
4.2.1 Randomized Sets of MAC Addresses 4.2.1. Randomized Sets of MAC Addresses
It is common benchmarking practice for a test instrument to emulate It is common benchmarking practice for a test instrument to emulate
multiple hosts, even on a single interface. This is desirable in multiple hosts, even on a single interface. This is desirable in
assessing DUT/SUT scalability. assessing DUT/SUT scalability.
However, test instruments may emulate multiple MAC addresses by However, test instruments may emulate multiple MAC addresses by
incrementing and/or decrementing addresses from a fixed starting incrementing and/or decrementing addresses from a fixed starting
point. This leads to situations as described above in "Address point. This leads to situations as described above in "Address
Pattern Variations" where hashing algorithms produce nonoptimal Pattern Variations" where hashing algorithms produce nonoptimal
outcomes. outcomes.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
When generating traffic with multiple addresses, it is RECOMMENDED When generating traffic with multiple addresses, it is RECOMMENDED
that all addresses use pseudorandom values. There are multiple ways that all addresses use pseudorandom values. There are multiple ways
to use sets of pseudorandom numbers. One strategy would be for the to use sets of pseudorandom numbers. One strategy would be for the
test instrument to iterate over an array of pseudorandom values test instrument to iterate over an array of pseudorandom values
rather than incrementing/decrementing from a starting address. The rather than incrementing/decrementing from a starting address. The
actual method is an implementation detail; in the end, any method actual method is an implementation detail; in the end, any method
that uses multiple addresses and avoids hash table collisions will be that uses multiple addresses and avoids hash table collisions will be
sufficient. sufficient.
4.3 MPLS Addressing 4.3. MPLS Addressing
Similiar to L2 switches, MPLS routers make forwarding decisions based Similiar to L2 switches, MPLS routers make forwarding decisions based
on a 20 bit MPLS label. Unless specific labels are required, it is on a 20 bit MPLS label. Unless specific labels are required, it is
RECOMMENDED that uniformly random values between 0 and 1,048,575 be RECOMMENDED that uniformly random values between 0 and 1,048,575 be
used for all labels assigned by test equipment. used for all labels assigned by test equipment.
4.4 Network-layer Addressing 4.4. Network-layer Addressing
Routers make forwarding decisions based on destination network Routers make forwarding decisions based on destination network
address. Since there is no hashing of source and destination address. Since there is no hashing of source and destination
addresses, the requirement for pseudorandom patterns at the network addresses, the requirement for pseudorandom patterns at the network
layer is far less critical than in the Ethernet MAC address case. layer is far less critical than in the Ethernet MAC address case.
However, there are cases where randomly distributed IPv4 and/or IPv6 However, there are cases where randomly distributed IPv4 and/or IPv6
addresses are desirable. For example, the equal cost multipath addresses are desirable. For example, the equal cost multipath
(ECMP) feature performs load-sharing across multiple links. Routers (ECMP) feature performs load-sharing across multiple links. Routers
implementing ECMP may perform a hash of source and destination IP implementing ECMP may perform a hash of source and destination IP
skipping to change at page 10, line 39 skipping to change at page 10, line 39
hash of all bits of the source and destination IP addresses for this hash of all bits of the source and destination IP addresses for this
purpose. purpose.
Just as in the case of MAC addresses, nonrandom IP addresses can have Just as in the case of MAC addresses, nonrandom IP addresses can have
an adverse effect on the outcome of ECMP link assignment decisions. an adverse effect on the outcome of ECMP link assignment decisions.
When benchmarking devices that implement ECMP or any other form of When benchmarking devices that implement ECMP or any other form of
Layer 3 aggregation, it is RECOMMENDED to use a randomly distributed Layer 3 aggregation, it is RECOMMENDED to use a randomly distributed
range of IP addresses. range of IP addresses.
4.5 Transport-layer Addressing 4.5. Transport-layer Addressing
Some devices with transport- or application-layer awareness use TCP Some devices with transport- or application-layer awareness use TCP
or UDP port numbers in making forwarding decisions. Examples of such or UDP port numbers in making forwarding decisions. Examples of such
devices include load balancers and application-layer firewalls. devices include load balancers and application-layer firewalls.
Test instruments have the capability of generating packets with Test instruments have the capability of generating packets with
random TCP and UDP source and destination port numbers. Known random TCP and UDP source and destination port numbers. Known
destination port numbers are often required for testing application- destination port numbers are often required for testing application-
layer devices. However, unless known port numbers are specifically layer devices. However, unless known port numbers are specifically
required for a test, it is RECOMMENDED to use randomly distributed required for a test, it is RECOMMENDED to use randomly distributed
skipping to change at page 12, line 7 skipping to change at page 12, line 7
RECOMMENDED to pick randomly distributed destination port numbers RECOMMENDED to pick randomly distributed destination port numbers
between these lower and upper boundaries. between these lower and upper boundaries.
Similarly, clients typically choose source port numbers in the space Similarly, clients typically choose source port numbers in the space
between 1024 and 65535 inclusive. Unless specific port numbers are between 1024 and 65535 inclusive. Unless specific port numbers are
required, it is RECOMMENDED to pick randomly distributed source port required, it is RECOMMENDED to pick randomly distributed source port
numbers between these lower and upper boundaries. numbers between these lower and upper boundaries.
5. Control Character Stuffing 5. Control Character Stuffing
5.1 Problem Statement 5.1. Problem Statement
Link-layer technologies that use HDLC-like framing may insert an Link-layer technologies that use HDLC-like framing may insert an
extra bit or byte before each instance of a control character in extra bit or byte before each instance of a control character in
traffic. These insertions prevent confusion with control characters, traffic. These insertions prevent confusion with control characters,
but they may also introduce significant overhead. but they may also introduce significant overhead.
The overhead of these escape sequences is problematic for two The overhead of these escape sequences is problematic for two
reasons. First, the amount of overhead is non-deterministic. The reasons. First, the amount of overhead is non-deterministic. The
best testers can do is to characterize the probability that an escape best testers can do is to characterize the probability that an escape
sequence will occur for a given pattern. This greatly complicates sequence will occur for a given pattern. This greatly complicates
skipping to change at page 12, line 37 skipping to change at page 12, line 37
channel capacity is only 95 percent, congestion will occur and the channel capacity is only 95 percent, congestion will occur and the
DUT will drop traffic even though the tester did not intend this DUT will drop traffic even though the tester did not intend this
outcome. outcome.
As described in [RFC1661] and [RFC1662], PPP and HDLC-like framing As described in [RFC1661] and [RFC1662], PPP and HDLC-like framing
introduce two kinds of escape sequences: bit and byte stuffing. Bit introduce two kinds of escape sequences: bit and byte stuffing. Bit
stuffing refers to the insertion of an escape bit on bit-synchronous stuffing refers to the insertion of an escape bit on bit-synchronous
links. Byte stuffing refers to the insertion of an escape byte on links. Byte stuffing refers to the insertion of an escape byte on
byte-synchronous links. We discuss each in turn. 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 [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 "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 to the sequence. This escaping is necessary to avoid confusion with
the HDLC control character 0x7D, which contains six "1" bits. the HDLC control character 0x7D, which contains six "1" bits.
Consider the following PPP frame containing a TCP/IP packet. Not Consider the following PPP frame containing a TCP/IP packet. Not
shown is the 1-byte flag sequence (0x7D), at least one of which must shown is the 1-byte flag sequence (0x7D), at least one of which must
occur between frames. occur between frames.
skipping to change at page 14, line 9 skipping to change at page 14, line 9
| ((FCS (4 bytes) )) | | ((FCS (4 bytes) )) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
None of the other fields are known to contain sequences subject to None of the other fields are known to contain sequences subject to
bit-stuffing, at least not in their entirety. bit-stuffing, at least not in their entirety.
Given the information at hand, and assuming static contents for the Given the information at hand, and assuming static contents for the
rest of the fields, the challenge is to determine the probability rest of the fields, the challenge is to determine the probability
that bit-stuffing will occur. 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 In order to calculate bit-stuffing probabilities, we assume that for
any string of length L, the probability of the Lth + 1 bit equalling any string of length L, the probability of the Lth + 1 bit equalling
1 is 0.5 and the probability of the Lth + 1 bit equalling 0 is 0.5. 1 is 0.5 and the probability of the Lth + 1 bit equalling 0 is 0.5.
Additionally, the value of the Lth + 1 bit is independant of any Additionally, the value of the Lth + 1 bit is independant of any
previous bits. previous bits.
We can calculate the probability of bit stuffing for both infinite We can calculate the probability of bit stuffing for both infinite
and finite strings of random bits. We begin with the infinite-string and finite strings of random bits. We begin with the infinite-string
case, which is required to prove the finite-string case. For an case, which is required to prove the finite-string case. For an
skipping to change at page 15, line 31 skipping to change at page 15, line 31
P(1) = 8/31 P(1) = 8/31
P(2) = 4/31 P(2) = 4/31
P(3) = 2/31 P(3) = 2/31
P(4) = 1/31 P(4) = 1/31
P(5) = 1/62 P(5) = 1/62
Thus, for an infinitely long string of random bits, the probability Thus, for an infinitely long string of random bits, the probability
of 5 sequential 1 bits is 1/62. Put another way, we expect to add of 5 sequential 1 bits is 1/62. Put another way, we expect to add
one stuff bit for every 62 bits of random uniform data. one stuff bit for every 62 bits of random uniform data.
5.2.2 Bit Stuffing for Finite Strings 5.2.2. Bit Stuffing for Finite Strings
The above result indicates that for any string of uniformly The above result indicates that for any string of uniformly
distributed random bits, we expect a stuffing event to occur every 62 distributed random bits, we expect a stuffing event to occur every 62
bits. So, given a string of some finite length L, where L >= 5, the bits. So, given a string of some finite length L, where L >= 5, the
expected number of stuffs is simply L * 1/62. expected number of stuffs is simply L * 1/62.
5.2.3 Applied Bit Stuffing 5.2.3. Applied Bit Stuffing
The amount of overhead attributable to bit stuffing may be calculated The amount of overhead attributable to bit stuffing may be calculated
explicitly as long as the total number of random bits per frame, explicitly as long as the total number of random bits per frame,
L_rand-bits, and the probability of stuffing, P(stuff), is known. L_rand-bits, and the probability of stuffing, P(stuff), is known.
% overhead = ( P(stuff) * L_rand-bits ) / framesize (in bits) % overhead = ( P(stuff) * L_rand-bits ) / framesize (in bits)
Note that if the entire frame contains random bits, then the Note that if the entire frame contains random bits, then the
percentage overhead is simply the probability of stuffing expressed percentage overhead is simply the probability of stuffing expressed
as a percentage. as a percentage.
skipping to change at page 16, line 26 skipping to change at page 16, line 26
Note that the DUT/SUT may be able to forward offered loads higher Note that the DUT/SUT may be able to forward offered loads higher
than the calculated theoretical maximum rate without packet loss. than the calculated theoretical maximum rate without packet loss.
Such results are the result of queuing on the part of the DUT/SUT. Such results are the result of queuing on the part of the DUT/SUT.
While a device's throughput may be above this level, delay-related While a device's throughput may be above this level, delay-related
measurements may be affected. Accordingly, it is RECOMMENDED to measurements may be affected. Accordingly, it is RECOMMENDED to
reduce offered levels by the amount of bit-stuffing overhead when reduce offered levels by the amount of bit-stuffing overhead when
testing devices using bit-synchronous links. This recommendation testing devices using bit-synchronous links. This recommendation
applies for all measurements, including throughput. 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, [RFC1662] requires that "Each Flag Sequence, Control Escape octet,
and any octet which is flagged in the sending Async-Control- and any octet which is flagged in the sending Async-Control-
Character-Map (ACCM), is replaced by a two octet sequence consisting Character-Map (ACCM), is replaced by a two octet sequence consisting
of the Control Escape octet followed by the original octet exclusive- of the Control Escape octet followed by the original octet exclusive-
or'd with hexadecimal 0x20." The practical effect of this is to 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, insert a stuff byte for instances of up to 34 characters: 0x7E, 0x7D,
or any of 32 ACCM values. or any of 32 ACCM values.
A common implementation of PPP in HDLC-like framing is in PPP over A common implementation of PPP in HDLC-like framing is in PPP over
Sonet/SDH (POS), as defined in [RFC2615]. Sonet/SDH (POS), as defined in [RFC2615].
As with the bit-stuffing case, the requirement in characterizing POS As with the bit-stuffing case, the requirement in characterizing POS
test traffic is to determine the probability that byte-stuffing will test traffic is to determine the probability that byte-stuffing will
occur for a given sequence. This is much simpler to do than with occur for a given sequence. This is much simpler to do than with
bit-synchronous links, since there is no possibility of overlap bit-synchronous links, since there is no possibility of overlap
across byte boundaries. across byte boundaries.
5.3.1 Nullifying ACCM 5.3.1. Nullifying ACCM
Testers can greatly reduce the probability of byte-stuffing by Testers can greatly reduce the probability of byte-stuffing by
configuring link partners to negotiate an ACCM value of 0x00. It is configuring link partners to negotiate an ACCM value of 0x00. It is
RECOMMENDED that testers configure the test instrument(s) and DUT/SUT RECOMMENDED that testers configure the test instrument(s) and DUT/SUT
to negotiate an ACCM value of 0x00 unless specific ACCM values are to negotiate an ACCM value of 0x00 unless specific ACCM values are
required. required.
One instance where nonzero ACCM values are used is in the layer 2 One instance where nonzero ACCM values are used is in the layer 2
tunneling protocol (L2TP), as defined in [RFC2661], section 4.4.6. tunneling protocol (L2TP), as defined in [RFC2661], section 4.4.6.
When the default ACCM values are used, the probability of stuffing When the default ACCM values are used, the probability of stuffing
for any given random byte is 34 in 256, or approximately 13.3 for any given random byte is 34 in 256, or approximately 13.3
percent. 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 If an ACCM value of 0x00 is negotiated, the only characters subject
to stuffing are the flag and control escape characters. Thus, we can to stuffing are the flag and control escape characters. Thus, we can
say that without ACCM the probability of stuffing for any given say that without ACCM the probability of stuffing for any given
random byte is 2 in 256, or approximately 0.8 percent. 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 bit or byte stuffing may be The amount of overhead attributable to bit or byte stuffing may be
calculated explicitly as long as the total number of random bytes per calculated explicitly as long as the total number of random bytes per
frame, L_rand-bytes, and the probability of stuffing, P(stuff), is frame, L_rand-bytes, and the probability of stuffing, P(stuff), is
known. known.
% overhead = ( P(stuff) * L_rand-bytes ) / framesize (in bytes) % overhead = ( P(stuff) * L_rand-bytes ) / framesize (in bytes)
Note that if the entire frame contains random bytes, then the Note that if the entire frame contains random bytes, then the
percentage overhead is simply the probability of stuffing expressed percentage overhead is simply the probability of stuffing expressed
skipping to change at page 20, line 7 skipping to change at page 20, line 7
This attack could consume up to 100 percent of available bandwidth. This attack could consume up to 100 percent of available bandwidth.
However, the test networks described in BMWG documents generally However, the test networks described in BMWG documents generally
SHOULD NOT be reachable by anyone other than the tester(s). SHOULD NOT be reachable by anyone other than the tester(s).
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. References 8. References
8.1 Normative References 8.1. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994. July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 20, line 31 skipping to change at page 20, line 31
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999. June 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology
for LAN Switching Devices", RFC 2889, August 2000. for LAN Switching Devices", RFC 2889, August 2000.
8.2 Informative References 8.2. Informative References
[Ca63] Campbell, D. and J. Stanley, "Experimental and Quasi- [Ca63] Campbell, D. and J. Stanley, "Experimental and Quasi-
Experimental Designs for Research", 1963. Experimental Designs for Research", 1963.
[Go97] Goralski, W., "SONET: A Guide to Synchronous Optical [Go97] Goralski, W., "SONET: A Guide to Synchronous Optical
Networks", 1997. Networks", 1997.
[Kn97] Knuth, D., "The Art of Computer Programming, Volume 2, Third [Kn97] Knuth, D., "The Art of Computer Programming, Volume 2, Third
Edition", 1997. Edition", 1997.
Appendix A. Acknowledgements
The authors gratefully acknowledge reviews and contributions by Neil
Carter, Glenn Chagnot, Rafael Francis, Paul Hoffman, David Joyner,
Joe Perches, and Scott Poretsky.
Authors' Addresses Authors' Addresses
David Newman David Newman
Network Test Network Test
Email: dnewman@networktest.com Email: dnewman@networktest.com
Timmons C. Player Timmons C. Player
Spirent Communications Spirent Communications
Email: timmons.player@spirentcom.com Email: timmons.player@spirentcom.com
Appendix A. Acknowledgements
The authors gratefully acknowledge reviews and contributions by Neil
Carter, Glenn Chagnot, Rafael Francis, Paul Hoffman, David Joyner,
Joe Perches, and Scott Poretsky.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 23, line 29 skipping to change at page 23, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 36 change blocks. 
60 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/