draft-ietf-bmwg-hash-stuffing-06.txt   draft-ietf-bmwg-hash-stuffing-07.txt 
Network Working Group D. Newman Network Working Group D. Newman
Internet-Draft Network Test Internet-Draft Network Test
Intended status: Informational T. Player Expires: May 24, 2007 T. Player
Expires: April 1, 2007 Spirent Communications Spirent Communications
September 28, 2006 November 20, 2006
Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
draft-ietf-bmwg-hash-stuffing-06.txt draft-ietf-bmwg-hash-stuffing-07.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 April 1, 2007. This Internet-Draft will expire on May 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
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 intended load, packet length, test duration, measurement, including intended load, packet length, test duration,
and traffic orientation. However, current benchmarking practice and traffic orientation. However, current benchmarking practice
overlooks two factors that have a profound impact on test results. overlooks two factors that have a profound impact on test results.
First, existing methodologies do not require the reporting of First, existing methodologies do not require the reporting of
addresses or other test traffic contents, even though these fields addresses or other test traffic contents, even though these fields
can affect test results. Second, "stuff" bits and bytes inserted in can affect test results. Second, "stuff" bits and bytes inserted in
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General considerations . . . . . . . . . . . . . . . . . . . . 6 3. General considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Repeatability . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Randomness . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Randomness . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Packet Content Variations . . . . . . . . . . . . . . . . . . 7 4. Packet Content Variations . . . . . . . . . . . . . . . . . . 8
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8
4.2. Ethernet MAC Addresses . . . . . . . . . . . . . . . . . . 8 4.2. IEEE 802 MAC Addresses . . . . . . . . . . . . . . . . . . 9
4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 9 4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 10
4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 11 4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 12
4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 11 4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 12
4.5. Transport-layer Addressing . . . . . . . . . . . . . . . . 12 4.5. Transport-layer Addressing . . . . . . . . . . . . . . . . 13
4.6. Application-layer Patterns . . . . . . . . . . . . . . . . 12 4.6. Application-layer Patterns . . . . . . . . . . . . . . . . 13
5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 13 5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 15
5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 13 5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 15
5.2. PPP Bit Stuffing . . . . . . . . . . . . . . . . . . . . . 13 5.2. PPP Bit Stuffing . . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 16 5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 18
5.2.2. Bit Stuffing for Finite Strings . . . . . . . . . . . 17 5.2.2. Bit Stuffing for Finite Strings . . . . . . . . . . . 20
5.2.3. Applied Bit Stuffing . . . . . . . . . . . . . . . . . 18 5.2.3. Applied Bit Stuffing . . . . . . . . . . . . . . . . . 20
5.3. POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 18 5.3. POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 21
5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 19 5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 21
5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 19 5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 21
5.3.3. Applied Byte Stuffing . . . . . . . . . . . . . . . . 19 5.3.3. Applied Byte Stuffing . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix B. Proof of Formula for Finite Bit Stuffing . . . . . . 25 Appendix B. Proof of Formula for Finite Bit Stuffing . . . . . . 27
Appendix C. Explicit Calculation of Bit Stuffing Overhead for Appendix C. Explicit Calculation of Bit Stuffing Overhead for
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 26 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix D. Explicit Calculation of Bit Stuffing Overhead for Appendix D. Explicit Calculation of Bit Stuffing Overhead for
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix E. Terminology . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
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 4, line 35 skipping to change at page 4, line 35
characters. characters.
Stuffing adds significant and variable overhead. Currently there is Stuffing adds significant and variable overhead. Currently there is
no standard method for determining the probability that stuffing will no standard method for determining the probability that stuffing will
occur for a given pattern, and thus no way to determine what impact occur for a given pattern, and thus no way to determine what impact
stuffing will have on test results. stuffing will have on test results.
This document covers two areas. First, we discuss strategies for This document covers two areas. First, we discuss strategies for
dealing with randomness and nonrandomness in test traffic. Second, dealing with randomness and nonrandomness in test traffic. Second,
we present formulas to determine the probability of bit- and byte- we present formulas to determine the probability of bit- and byte-
stuffing on PPP and POS circuits. In both areas, we provide stuffing on point-to-point protocol (PPP) and packet over Sonet (POS)
recommendations for obtaining better repeatability in test results. circuits. In both areas, we provide recommendations for obtaining
better repeatability in test results.
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.
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 recreated 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 common phenomena. other common phenomena.
While this variability does not necessarily invalidate test results, While this variability does not necessarily invalidate test results,
it is important to recognize the existing variation. Exact bit-for- it is important to recognize the existing variation. Exact bit-for-
bit reproduction of test traffic is a hard problem. A simpler bit repeatability of test traffic is a hard problem. A simpler
approach is to acknowledge that some variation exists, characterize approach is to acknowledge that some variation exists, characterize
that variation, and describe it when analyzing test results. 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.
Note also that this discussion covers only repeatability, which is
concerned with variability of test results from trial to trial on the
same test bed. A separate concern is reproducibility, which refers
to the precision of test results obtained from different test beds.
Clearly, reproducibility across multiple test beds requires
repeatability on a single test bed.
3.2. Randomness 3.2. 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.
skipping to change at page 8, line 39 skipping to change at page 9, line 39
any value from 000 to 111 inclusive. Thus, the outcome of XOR any value from 000 to 111 inclusive. Thus, the outcome of XOR
operations should be equally distributed from 0 to 7, and operations should be equally distributed from 0 to 7, and
distribution across NPs should also be equal (at least for this distribution across NPs should also be equal (at least for this
particular 3-bit hashing algorithm). Absent other impediments, the particular 3-bit hashing algorithm). Absent other impediments, the
device should be able to utilize 100 percent of available capacity. device should be able to utilize 100 percent of available capacity.
This simple example presumes knowledge on the tester's part of the This simple example presumes knowledge on the tester's part of the
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 Benchmarking Working Group (BMWG).
Therefore, this memo adds a new consideration for benchmarking Therefore, this memo adds a new consideration for benchmarking
methodologies, to select traffic patterns that overcome the effects methodologies, to select traffic patterns that overcome the effects
of non-randomness regardless of the hashing algorithms in use. The of non-randomness regardless of the hashing algorithms in use. The
balance of this section offers recommendations for test traffic balance of this section offers recommendations for test traffic
patterns to avoid these effects, starting at the link layer and patterns to avoid these effects, starting at the link layer and
working up to the application layer. working up to the application layer.
4.2. Ethernet MAC Addresses 4.2. IEEE 802 MAC Addresses
Test traffic SHOULD use pseudorandom patterns in Ethernet addresses. Test traffic SHOULD use pseudorandom patterns in IEEE 802 MAC
The following source and destination Ethernet address pattern is addresses. The following source and destination MAC address pattern
RECOMMENDED for use when benchmarking Ethernet devices: is RECOMMENDED:
(RR & 0xFC):PP:PP:RR:RR:RR (RR & 0xFC):PP:PP:RR:RR:RR
where (RR & 0xFC) is a pseudorandom number bitwise ANDed with 0xFC, where (RR & 0xFC) is a pseudorandom number bitwise ANDed with 0xFC,
PP:PP is the 1-indexed interface number of the test instrument and PP:PP is the 1-indexed interface number of the test instrument and
RR:RR:RR is 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
0xFC sets the high-order two bits of that byte to 0, guaranteeing a 0xFC sets the high-order two bits of that byte to 0, guaranteeing a
non multicast address and a non locally administered address. non multicast address and a non locally administered address.
Test traffic SHOULD use PP:PP to identify the source interface number Test traffic SHOULD use PP:PP to identify the source interface 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.
Note that the "PP:PP" designation refers to the source interface of Note that the "PP:PP" designation refers to the source interface of
the test instrument, not the DUT/SUT. There are situations where the the test instrument, not the device under test/system under test
DUT/SUT interface number may change during the test; one example (DUT/SUT). There are situations where the DUT/SUT interface number
would be a test of wireless LAN roaming. By referring to the may change during the test; one example would be a test of wireless
(presumably static) source interface number of the test instrument, LAN roaming. By referring to the (presumably static) source
test engineers can keep track of test traffic regardless of any interface number of the test instrument, test engineers can keep
possible DUT/SUT changes. track of test traffic regardless of any possible DUT/SUT changes.
Further, source interface numbers SHOULD be 1-indexed and SHOULD NOT Further, source interface numbers SHOULD be 1-indexed and SHOULD NOT
be 0-indexed. This avoids the low but nonzero probability of an be 0-indexed. This avoids the low but nonzero probability of an
all-0s Ethernet address. Some devices will drop frames with all-0s all-0s MAC address. Some devices will drop frames with all-0s MAC
Ethernet addresses. 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 30 of 48 bits in the MAC address have Note also that since only 30 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
skipping to change at page 11, line 9 skipping to change at page 12, line 9
Every MAC address SHOULD be pseudorandom, not just the starting one. Every MAC address SHOULD be pseudorandom, not just the starting one.
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 with pseudorandom patterns will be that uses multiple addresses with pseudorandom patterns will be
sufficient 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.
4.3. MPLS Addressing 4.3. MPLS Addressing
Similiar to L2 switches, MPLS routers make forwarding decisions based Similar to L2 switches, multiprotocol label switching (MPLS) devices
on a 20 bit MPLS label. Unless specific labels are required, it is make forwarding decisions based on a 20 bit MPLS label. Unless
RECOMMENDED that uniformly random values between 0 and 1,048,575 be specific labels are required, it is RECOMMENDED that uniformly random
used for all labels assigned by test equipment. values between 0 and 1,048,575 be used for all labels assigned by
test equipment.
4.4. Network-layer Addressing 4.4. Network-layer Addressing
When routers make forwarding decisions based solely on destination When routers make forwarding decisions based solely on destination
network address, there may be no potential for hashing collision of network address, there may be no potential for hashing collision of
source and destination addresses, as in the case of Ethernet source and destination addresses, as in the case of Ethernet
switching discussed earlier. However, the potential still exists for switching discussed earlier. However, the potential still exists for
hashing collisions to exist at the network layer, and testers SHOULD hashing collisions to exist at the network layer, and testers SHOULD
take this potential into consideration when crafting the network- take this potential into consideration when crafting the network-
layer contents of test traffic. layer contents of test traffic.
skipping to change at page 13, line 9 skipping to change at page 15, line 9
insert fields into packet payloads to distinguish test traffic. insert fields into packet payloads to distinguish test traffic.
These fields may contain a transmission timestamp; sequence number; These fields may contain a transmission timestamp; sequence number;
test equipment interface identifier and/or "stream" number; and a CRC test equipment interface identifier and/or "stream" number; and a CRC
over the contents of the test payload or test packet. All these over the contents of the test payload or test packet. All these
fields are potential candidates for stuffing. fields are potential candidates for stuffing.
5. Control Character Stuffing 5. Control Character Stuffing
5.1. Problem Statement 5.1. Problem Statement
Link-layer technologies that use HDLC-like framing may insert an Link-layer technologies that use high-level data link control (HDLC)-
extra bit or byte before each instance of a control character in like framing may insert an extra bit or byte before each instance of
traffic. These insertions prevent confusion with control characters, a control character in traffic. These "stuffing" insertions prevent
but they may also introduce significant overhead. confusion with control characters, but they may also introduce
significant overhead. Stuffing is data-dependent; thus selection of
different payload patterns will result in frames transmitted on the
media that vary in length, even though the original frames may all be
of the same length.
The overhead of these escape sequences is problematic for two The overhead of these escape sequences is problematic for two
reasons. First, explictly calculating the amount of overhead can be reasons. First, explicitly calculating the amount of overhead can be
non-trivial or even impossible for certain types of test traffic. In non-trivial or even impossible for certain types of test traffic. In
such cases, the best testers can do is to characterize the such cases, the best testers can do is to characterize the
probability that an escape sequence will occur for a given pattern. probability that an escape sequence will occur for a given pattern.
This greatly complicates the requirement of declaring exactly how This greatly complicates the requirement of declaring exactly how
much traffic is offered to a DUT/SUT. much traffic is offered to a DUT/SUT.
Second, in the absence of characterization and compensation for this Second, in the absence of characterization and compensation for this
overhead, the tester may unwittingly congest the DUT/SUT. For overhead, the tester may unwittingly congest the DUT/SUT. For
example, if a tester intends to offer traffic to a DUT at 95 percent 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 of line rate, but the link-layer protocol introduces an additional 1
skipping to change at page 15, line 33 skipping to change at page 17, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Acknowledgment Number)) | | ((Acknowledgment Number)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| | | Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| ((Window)) | | Offset| Reserved |R|C|S|S|Y|I| ((Window)) |
| | |G|K|H|T|N|N| | | | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((Checksum)) | Urgent Pointer | | ((Checksum)) | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ ((payload)) / | ((payload)) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ((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. Note that there is no 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 payload in this simple example; as noted in section 4.6, the payload
contents of test traffic often will present additional opportunities contents of test traffic often will present additional opportunities
for stuffing to occur, and MUST be taken into account when for stuffing to occur, and MUST be taken into account when
skipping to change at page 16, line 32 skipping to change at page 18, line 37
| | 1 | | 1 | | 1 | | 1 | | 1 | | | | 1 | | 1 | | 1 | | 1 | | 1 | |
| start |--->| 1 |--->| 2 |--->| 3 |--->| 4 |--->| 5 | | start |--->| 1 |--->| 2 |--->| 3 |--->| 4 |--->| 5 |
|_______| |_____| |_____| |_____| |_____| |_____| |_______| |_____| |_____| |_____| |_____| |_____|
| | | | | | | | | | | | | |
| |0 |0 |0 |0 |0 |0 | |0 |0 |0 |0 |0 |0
|-<-|----<----|----<-----|----<-----|----<-----|----<-----| |-<-|----<----|----<-----|----<-----|----<-----|----<-----|
Initially, we begin in the "start" state. A "1" bit moves us into 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. 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 From state 5, a "1" bit takes us back to the 1 state and a "0" bit
returns us to "start." From this state table we can build the returns us to "start."
following transition matrix: From this state diagram we can build the following transition matrix:
\ To | \ To |
\ | \ |
\ | \ |
From \ | start 1 2 3 4 5 From \ | start 1 2 3 4 5
______\|_________________________________________________ ______\|_________________________________________________
start | 0.5 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0 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 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 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 3 | 0.5 | 0.0 | 0.0 | 0.0 | 0.5 | 0.0
skipping to change at page 17, line 47 skipping to change at page 20, line 23
possible strings of length L. Clearly, for 0 <= L <= 4, f(L) = 0 as 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) there are no strings of length 5. For L >= 5, f(L) = 2^(L-5) + (L-5)
* 2^(L-6) + f(L-5). * 2^(L-6) + f(L-5).
A proof of this formula can be found in Appendix B. A proof of this formula can be found in Appendix B.
Now, the expected number of stuffing events, E[stuffs], can be found 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 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. total number of strings. Thus for any L, E[stuffs] = f(L) / 2^L.
Similiarly, the probability that any particular bit is the cause of a 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 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 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 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_n, where 5 <= n <= L, caused a stuff is f(L) / (L * 2^L).
5.2.3. Applied Bit Stuffing 5.2.3. Applied Bit Stuffing
The amount of overhead attributable to bit-stuffing may be calculated The amount of overhead attributable to bit-stuffing may be calculated
explicitly as long as the expected number of stuff bits per frame, 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] is known. For long uniformly random bit-strings,
skipping to change at page 19, line 50 skipping to change at page 22, line 26
When testing a DUT/SUT that implements PPP in HDLC-like framing and 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 L2TP (or any other technology that uses nonzero ACCM values), it is
RECOMMENDED that testers reduce the maximum intended load by 13.3 RECOMMENDED that testers reduce the maximum intended load by 13.3
percent to avoid introducing congestion. percent to avoid introducing congestion.
When testing a DUT/SUT that implements PPP in HDLC-like framing and 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 an ACCM value of 0x00, it is RECOMMENDED that testers reduce the
maximum intended load by 0.8 percent to avoid introducing congestion. maximum intended load by 0.8 percent to avoid introducing congestion.
Note that the percentages given above are approximations. For Note that the percentages given above are approximations. For
greatest precision, the actual intended load SHOULD be explictly greatest precision, the actual intended load SHOULD be explicitly
calculated from the test traffic calculated from the test traffic
Note also that the DUT/SUT may be able to forward intended loads Note also that the DUT/SUT may be able to forward intended loads
higher than the calculated theoretical maximum rate without packet higher than the calculated theoretical maximum rate without packet
loss. Such results are the result of queuing on the part of the DUT/ loss. 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- SUT. While a device's throughput may be above this level, delay-
related measurements may be affected. Accordingly, it is RECOMMENDED related measurements may be affected. Accordingly, it is RECOMMENDED
to reduce offered levels by the amount of byte-stuffing overhead when to reduce offered levels by the amount of byte-stuffing overhead when
testing devices using byte-synchronous links. This recommendation testing devices using byte-synchronous links. This recommendation
applies for all measurements, including throughput. applies for all measurements, including throughput.
6. Security Considerations 6. Security Considerations
skipping to change at page 23, line 39 skipping to change at page 25, line 39
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,
Edition", 1997. Third Edition", 1997.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors gratefully acknowledge reviews and contributions by Len The authors gratefully acknowledge reviews and contributions by Tom
Ciavattone, Robert Craig, John Dawson, Neil Carter, Glenn Chagnot, Alexander, Len Ciavattone, Robert Craig, John Dawson, Neil Carter,
Kevin Dubray, Diego Dugatkin, Rafael Francis, Paul Hoffman, David Glenn Chagnot, Kevin Dubray, Diego Dugatkin, Rafael Francis, Paul
Joyner, Al Morton, Joe Perches, Jerry Perser, Scott Poretsky, and Hoffman, David Joyner, Al Morton, Joe Perches, Jerry Perser, Scott
Kris Rousey. Poretsky, Dan Romanescu, and Kris Rousey.
Appendix B. Proof of Formula for Finite Bit Stuffing Appendix B. Proof of Formula for Finite Bit Stuffing
We would like to construct a function, f(L), that allows us to We would like to construct a function, f(L), that allows us to
explictly count the total number of bit-stuffs in the set of all 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. 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. Additionally, let b_n be the nth bit of string S where 1 <= n <= L.
Clearly, when 0 <= L <= 4, f(L) = 0, as there can be no possible bit- Clearly, when 0 <= L <= 4, f(L) = 0, as there can be no possible bit-
stuff if there are < 5 bits. stuff if there are < 5 bits.
Suppose L >= 5, then there are some number of strings that will cause Suppose L >= 5, then there are some number of strings that will cause
stuffing events. Let us count them. stuffing events. Let us count them.
We begin by counting the number of strings that will cause at least We begin by counting the number of strings that will cause at least
skipping to change at page 25, line 41 skipping to change at page 27, line 41
So, given a string of length L, where L >= 5, we know that there are 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 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 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 than one bit-stuff within the string S. Let Z represent a sequence of
5 sequential ones bits. Consider the bit string ..., b_n, b_(n+1), 5 sequential ones 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 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 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), 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 b_(n+2), b_(n+8), b_(n+9), ... Note that the position of Z in the
above squence is irrelevant when looking for bit-stuffs. above sequence is irrelevant when looking for bit-stuffs.
Additionally, we've already determined that the number of strings 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) + 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 (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) = 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. 2^(L-5) + (L-5) * 2^(L-6) + f(L-5) for all L >= 5.
Appendix C. Explicit Calculation of Bit Stuffing Overhead for IPv4 Appendix C. Explicit Calculation of Bit Stuffing Overhead for IPv4
Consider a scenario where a tester is transmitting IPv4 test packets Consider a scenario where a tester is transmitting IPv4 test packets
across a bit synchronous link. The test traffic has the following across a bit synchronous link. The test traffic has the following
parameters (values are in decimal): parameters (values are in decimal):
+----------------------+-----------------------------+ +-----------------------+-----------------------------+
| Field | Value | | Field | Value |
+----------------------+-----------------------------+ +-----------------------+-----------------------------+
| IP Version | 4 | | IP Version | 4 |
| | | | | |
| IP Header Length | 5 | | IP Header Length | 5 |
| | | | | |
| TOS | 0 | | Type of service (TOS) | 0 |
| | | | | |
| Datagram Length | 1028 | | Datagram Length | 1028 |
| | | | | |
| ID | 0 | | ID | 0 |
| | | | | |
| Flags/Fragments | 0 | | Flags/Fragments | 0 |
| | | | | |
| TTL | 64 | | Time to live (TTL) | 64 |
| | | | | |
| Protocol | 17 | | Protocol | 17 |
| | | | | |
| Source IP | 192.168.13.1-192.168.13.254 | | Source IP | 192.168.13.1-192.168.13.254 |
| | | | | |
| Destination IP | 192.168.1.10 | | Destination IP | 192.168.1.10 |
| | | | | |
| Source UDP Port | pseudorandom port | | Source UDP Port | pseudorandom port |
| | | | | |
| Destination UDP Port | pseudorandom port | | Destination UDP Port | pseudorandom port |
| | | | | |
| UDP Length | 1008 | | UDP Length | 1008 |
| | | | | |
| Payload | 1000 pseudorandom bytes | | Payload | 1000 pseudorandom bytes |
+----------------------+-----------------------------+ +-----------------------+-----------------------------+
We want to calculate the expected number of stuffs per packet, or We want to calculate the expected number of stuffs per packet, or
E[packet stuffs]. E[packet stuffs].
First, we observe that we have 254 different IP headers to consider, First, we observe that we have 254 different IP headers to consider,
and secondly, that the changing 4th octet in the IP source addresses and secondly, that the changing 4th octet in the IP source addresses
will produce occasional bit-stuffing events, so we must enumerate will produce occasional bit-stuffing events, so we must enumerate
these occurances. Additionally, we must take into account that the these occurrences. Additionally, we must take into account that the
3rd octet of the source IP and the first octet of the destination IP 3rd octet of the source IP and the first octet of the destination IP
will affect stuffing occurences. will affect stuffing occurrences.
An exhaustive search shows that cycling through all 254 headers An exhaustive search shows that cycling through all 254 headers
produces 51 bit stuffs for the destination IP address. This gives us 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 an expectation of 51/254 stuffs per packet due to the changing source
IP address. IP address.
For the IP CRC, we observe that the value will decrement as the For the IP CRC, we observe that the value will decrement as the
source IP is incremented. A little calculation shows that the CRC source IP is incremented. A little calculation shows that the CRC
values for these headers will fall in the range of 0xE790 to 0xE88F. values for these headers will fall in the range of 0xE790 to 0xE88F.
Additionally, both the protocol and source IP address must be Additionally, both the protocol and source IP address must be
considered, as they provide a source of extra leading and trailing considered, as they provide a source of extra leading and trailing
ones bits. ones bits.
An exhaustive search shows that cycling through all 254 headers will An exhaustive search shows that cycling through all 254 headers will
produce 102 bit stuffs for the CRC. This gives us an expectation of produce 102 bit stuffs for the CRC. This gives us an expectation of
102/254 stuffs per packet due to the CRC. 102/254 stuffs per packet due to the CRC.
Since our destination IP address is even and the UDP length is less Since our destination IP address is even and the UDP length is less
than 32768, the random source and destination ports provide 32 bits than 32768, the random source and destination ports provide 32 bits
of sequential random data without forcing us to consider the boundry of sequential random data without forcing us to consider the boundary
bits. Additionally, we will assume that since our payload is bits. Additionally, we will assume that since our payload is
pseudorandom, our UDP CRC will be too. The even UDP length field pseudorandom, our UDP CRC will be too. The even UDP length field
again allows us to only consider the bits explicitly contained within again allows us to only consider the bits explicitly contained within
the CRC and data fields. So, using the forumla for the expected 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 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, that E[UDP stuffs] = f(32)/2^32 + f(8000+16)/2^(8000+16). Now,
f(32)/2^32 is calculatable without too much difficulty and is 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 approximately 0.465. However, f(8016)/2^8016 is a little large to
calculate easily, so we will approximate this value by using the calculate easily, so we will approximate this value by using the
probability value obtained in section 5.2.1. Thus, E[UDP] ~ 0.465 + probability value obtained in section 5.2.1. Thus, E[UDP] ~ 0.465 +
8016/62 ~ 129.755. 8016/62 ~ 129.755.
Hence, E[packet stuffs] = 51/254 + 102/254 + 129.755 = 130.357. Hence, E[packet stuffs] = 51/254 + 102/254 + 129.755 = 130.357.
However, since we cannot have a fractional stuff, we round down to However, since we cannot have a fractional stuff, we round down to
130. Thus, we expect 130 stuffs per packet. 130. Thus, we expect 130 stuffs per packet.
Finally, we can calculate bit-stuffing overhead by dividing the Finally, we can calculate bit-stuffing overhead by dividing the
skipping to change at page 28, line 46 skipping to change at page 30, line 46
| | | | | |
| Payload | 1000 pseudorandom bytes | | Payload | 1000 pseudorandom bytes |
+----------------------+------------------------------+ +----------------------+------------------------------+
We want to calculate the expected number of stuffs per packet, or We want to calculate the expected number of stuffs per packet, or
E[packet stuffs]. E[packet stuffs].
First, we observe that we have 255 different IP headers to consider, First, we observe that we have 255 different IP headers to consider,
and secondly, that the changing 4th quad in the IP source addresses and secondly, that the changing 4th quad in the IP source addresses
will produce occasional bit-stuffing events, so we must enumerate will produce occasional bit-stuffing events, so we must enumerate
these occurances. Additionally, we must take into account that the these occurrences. Additionally, we must take into account that the
first quad of the destination IP address will affect stuffing first quad of the destination IP address will affect stuffing
occurences, since binary represenation of the address provides occurrences, since binary representation of the address provides
leading 1's bits. leading 1's bits.
An exhaustive search shows that cycling through all 255 headers An exhaustive search shows that cycling through all 255 headers
produces 36 bit stuffs for the destination IP address. This gives us produces 36 bit stuffs for the destination IP address. This gives us
an expectation of 36/255 stuffs per packet due to the changing source an expectation of 36/255 stuffs per packet due to the changing source
IP address. IP address.
We also have to consider our pseudorandomlly generated flow label. We also have to consider our pseudorandomly generated flow label.
However, since our Traffic Class field is 0 and our Payload Length 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 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 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 random data. Thus the expectation of a stuff in the flow label is
f(20)/2^20 ~ .272. f(20)/2^20 ~ .272.
Similiar to the flow label case above, the fourth quad of our 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 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 32768, so the random source and destination ports provide 32 bits of
sequential random data without forcing us to consider the boundry sequential random data without forcing us to consider the boundary
bits. Additionally, we will assume that since our payload is bits. Additionally, we will assume that since our payload is
pseudorandom, our UDP CRC will be too. The even UDP length field pseudorandom, our UDP CRC will be too. The even UDP length field
again allows us to only consider the bits explicitly contained within again allows us to only consider the bits explicitly contained within
the CRC and data fields. So, using the forumla for the expected 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 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, that E[UDP stuffs] = f(32)/2^32 + f(8000+16)/2^(8000+16). Now,
f(32)/2^32 is calculatable without too much difficulty and is 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 approximately 0.465. However, f(8016)/2^8016 is a little large to
calculate easily, so we will approximate this value by using the calculate easily, so we will approximate this value by using the
probability value obtained in section 5.2.1. Thus, E[UDP stuffs] ~ probability value obtained in section 5.2.1. Thus, E[UDP stuffs] ~
0.465 + 8016/62 ~ 129.755. 0.465 + 8016/62 ~ 129.755.
Now we may explicty calculate that E[packet stuffs] = 36/255 + 0.272 Now we may explicitly calculate that E[packet stuffs] = 36/255 +
+ 129.755 = 130.168. However, since we cannot have a fractional 0.272 + 129.755 = 130.168. However, since we cannot have a
stuff, we round down to 130. Thus, we expect 130 stuffs per packet. fractional stuff, we round down to 130. Thus, we expect 130 stuffs
per packet.
Finally, we can calculate bit-stuffing overhead by dividing the Finally, we can calculate bit-stuffing overhead by dividing the
expected number of stuff bits by the total number of bits in the IP expected number of stuff bits by the total number of bits in the IP
datagram. So, this example traffic would generate 1.55% overhead. datagram. So, this example traffic would generate 1.55% overhead.
If our payload had consisted exclusively of zero bits, our 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% would have been 0.010%. An all ones payload would produce 19.09%
overhead. overhead.
Appendix E. Terminology
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.
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.
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.
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@spirent.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
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
 End of changes. 51 change blocks. 
102 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/