draft-ietf-bmwg-hash-stuffing-07.txt   draft-ietf-bmwg-hash-stuffing-08.txt 
Network Working Group D. Newman Network Working Group D. Newman
Internet-Draft Network Test Internet-Draft Network Test
Expires: May 24, 2007 T. Player Expires: July 4, 2007 T. Player
Spirent Communications Spirent Communications
November 20, 2006 December 31, 2006
Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
draft-ietf-bmwg-hash-stuffing-07.txt draft-ietf-bmwg-hash-stuffing-08.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 May 24, 2007. This Internet-Draft will expire on July 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 . . . . . . . . . . . . . . . . . . 8 4. Packet Content Variations . . . . . . . . . . . . . . . . . . 8
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8
4.2. IEEE 802 MAC Addresses . . . . . . . . . . . . . . . . . . 9 4.2. IEEE 802 MAC Addresses . . . . . . . . . . . . . . . . . . 9
4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 10 4.2.1. Randomized Sets of MAC Addresses . . . . . . . . . . . 11
4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 12 4.3. MPLS Addressing . . . . . . . . . . . . . . . . . . . . . 12
4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 12 4.4. Network-layer Addressing . . . . . . . . . . . . . . . . . 12
4.5. Transport-layer Addressing . . . . . . . . . . . . . . . . 13 4.5. Transport-layer Addressing . . . . . . . . . . . . . . . . 13
4.6. Application-layer Patterns . . . . . . . . . . . . . . . . 13 4.6. Application-layer Patterns . . . . . . . . . . . . . . . . 13
5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 15 5. Control Character Stuffing . . . . . . . . . . . . . . . . . . 15
5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 15 5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 15
5.2. PPP Bit Stuffing . . . . . . . . . . . . . . . . . . . . . 15 5.2. PPP Bit Stuffing . . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 18 5.2.1. Calculating Bit-Stuffing Probability . . . . . . . . . 18
5.2.2. Bit Stuffing for Finite Strings . . . . . . . . . . . 20 5.2.2. Bit Stuffing for Finite Strings . . . . . . . . . . . 20
5.2.3. Applied Bit Stuffing . . . . . . . . . . . . . . . . . 20 5.2.3. Applied Bit Stuffing . . . . . . . . . . . . . . . . . 20
5.3. POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 21 5.3. POS Byte Stuffing . . . . . . . . . . . . . . . . . . . . 21
5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 21 5.3.1. Nullifying ACCM . . . . . . . . . . . . . . . . . . . 21
5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 21 5.3.2. Other Stuffed Characters . . . . . . . . . . . . . . . 21
5.3.3. Applied Byte Stuffing . . . . . . . . . . . . . . . . 22 5.3.3. Applied Byte Stuffing . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Normative References . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix B. Proof of Formula for Finite Bit Stuffing . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . . 28 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix D. Explicit Calculation of Bit Stuffing Overhead for Appendix D. Explicit Calculation of Bit Stuffing Overhead for
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 30 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix E. Terminology . . . . . . . . . . . . . . . . . . . . . 32 Appendix E. Terminology . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 34
skipping to change at page 10, line 13 skipping to change at page 10, line 13
addresses. The following source and destination MAC address pattern addresses. The following source and destination MAC address pattern
is RECOMMENDED: 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 low-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. Note
that the resulting addresses may violate IEEE 802 standards by using
organizationally unique identifiers (OUIs) not assigned to the test
port manufacturer. However, since these addresses will be used only
on isolated test networks there should be no possibility of mistaken
identity.
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
skipping to change at page 12, line 25 skipping to change at page 12, line 30
testers MAY generate a pseudorandom set of MAC and IP addresses once, 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 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 either case, the same MAC and IP addresses MUST be used in all
trials. trials.
4.3. MPLS Addressing 4.3. MPLS Addressing
Similar to L2 switches, multiprotocol label switching (MPLS) devices Similar to L2 switches, multiprotocol label switching (MPLS) devices
make forwarding decisions based on a 20 bit MPLS label. Unless make forwarding decisions based on a 20 bit MPLS label. Unless
specific labels are required, it is RECOMMENDED that uniformly random specific labels are required, it is RECOMMENDED that uniformly random
values between 0 and 1,048,575 be used for all labels assigned by values between 16 and 1,048,575 be used for all labels assigned by
test equipment. test equipment. As per [RFC3032], this avoids using reserved MPLS
labels in the range of 0-15 inclusive.
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 31 skipping to change at page 13, line 36
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 pseudorandom and required for a test, it is RECOMMENDED to use pseudorandom and
uniformly distributed values for both source and destination port uniformly distributed values for both source and destination port
numbers. numbers.
In addition, it may be desirable to pick pseudorandom values from a In addition, it may be desirable to pick pseudorandom values from a
selected pool of numbers. Many services identify themselves through selected pool of numbers. Many services identify themselves through
use of reserved destination port numbers between 1 and 1023 use of reserved destination port numbers between 1 and 49151
inclusive. Unless specific port numbers are required, it is inclusive. Unless specific port numbers are required, it is
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.
4.6. Application-layer Patterns 4.6. Application-layer Patterns
skipping to change at page 17, line 39 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 25, line 5 skipping to change at page 25, line 5
[RFC2615], section 6, discusses a denial-of-service attack involving [RFC2615], section 6, discusses a denial-of-service attack involving
the intentional transmission of characters that require stuffing. the intentional transmission of characters that require stuffing.
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. 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 25, line 31 skipping to change at page 25, line 29
[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 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
[Ca63] Campbell, D. and J. Stanley, "Experimental and Quasi- Encoding", RFC 3032, January 2001.
Experimental Designs for Research", 1963.
[Go97] Goralski, W., "SONET: A Guide to Synchronous Optical
Networks", 1997.
[Kn97] Knuth, D., "The Art of Computer Programming, Volume 2,
Third Edition", 1997.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors gratefully acknowledge reviews and contributions by Tom The authors gratefully acknowledge reviews and contributions by Tom
Alexander, Len Ciavattone, Robert Craig, John Dawson, Neil Carter, Alexander, Len Ciavattone, Robert Craig, John Dawson, Neil Carter,
Glenn Chagnot, Kevin Dubray, Diego Dugatkin, Rafael Francis, Paul Glenn Chagnot, Kevin Dubray, Diego Dugatkin, Rafael Francis, Paul
Hoffman, David Joyner, Al Morton, Joe Perches, Jerry Perser, Scott Hoffman, David Joyner, Al Morton, Joe Perches, Jerry Perser, Scott
Poretsky, Dan Romanescu, and Kris Rousey. Poretsky, Dan Romascanu, and Kris Rousey.
Appendix B. Proof of Formula for Finite Bit Stuffing Appendix B. Proof of Formula for Finite Bit Stuffing
We would like to construct a function, f(L), that allows us to We would like to construct a function, f(L), that allows us to
explicitly count the total number of bit-stuffs in the set of all 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.
skipping to change at page 28, line 11 skipping to change at page 28, line 11
(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 |
| | | | | |
| Type of service (TOS) | 0 | | Type of service (TOS) | 0 |
| | | | | |
| Datagram Length | 1028 | | Datagram Length | 1028 |
| | | | | |
| ID | 0 | | ID | 0 |
| | | | | |
| Flags/Fragments | 0 | | Flags/Fragments | 0 |
| | | | | |
| Time to live (TTL) | 64 | | Time to live (TTL) | 64 |
| | | | | |
| Protocol | 17 | | Protocol | 17 |
| | | | | |
| Source IP | 192.168.13.1-192.168.13.254 | | Source IP | 192.18.13.1-192.18.13.254 |
| | | | | |
| Destination IP | 192.168.1.10 | | Destination IP | 192.18.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 occurrences. 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 occurrences. will affect stuffing occurrences.
skipping to change at page 30, line 12 skipping to change at page 30, line 12
would have been 0.012%. An all ones payload would produce 19.47% would have been 0.012%. An all ones payload would produce 19.47%
overhead. overhead.
Appendix D. Explicit Calculation of Bit Stuffing Overhead for IPv6 Appendix D. Explicit Calculation of Bit Stuffing Overhead for IPv6
Consider a scenario where a tester is transmitting IPv6 test packets Consider a scenario where a tester is transmitting IPv6 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 except for IPv6 addresses, which parameters (values are in decimal except for IPv6 addresses, which
are in hexadecimal): are in hexadecimal):
+----------------------+------------------------------+ +----------------------+----------------------------------+
| Field | Value | | Field | Value |
+----------------------+------------------------------+ +----------------------+----------------------------------+
| IP Version | 6 | | IP Version | 6 |
| | | | | |
| Traffic Class | 0 | | Traffic Class | 0 |
| | | | | |
| Flow Label | pseudorandom label | | Flow Label | pseudorandom label |
| | | | | |
| Payload Length | 1008 | | Payload Length | 1008 |
| | | | | |
| Next Header | 17 | | Next Header | 17 |
| | | | | |
| Hop Limit | 64 | | Hop Limit | 64 |
| | | | | |
| Source IP | DEAD:0:0:1::1-DEAD:0:0:1::FF | | Source IP | 2001:DB8:0:1::1-2001:DB8:0:1::FF |
| | | | | |
| Destination IP | DEAD:0:0:2::10 | | Destination IP | 2001:DB8:0:2::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 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 occurrences. Additionally, we must take into account that the these occurrences. Additionally, we also note that since the first
first quad of the destination IP address will affect stuffing quad of the destination address has a leading zero bit, we do no have
occurrences, since binary representation of the address provides to consider these adjacent bits when calculating the number of bit
leading 1's bits. stuffs in the source IP address.
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 20 bit stuffs for the source IP address. This gives us an
an expectation of 36/255 stuffs per packet due to the changing source expectation of 20/255 stuffs per packet due to the changing source IP
IP address. address.
We also have to consider our pseudorandomly 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.
Similar 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
skipping to change at page 31, line 30 skipping to change at page 31, line 30
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 formula 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 calculable 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 explicitly calculate that E[packet stuffs] = 36/255 + Now we may explicitly calculate that E[packet stuffs] = 20/255 +
0.272 + 129.755 = 130.168. However, since we cannot have a 0.272 + 129.755 = 130.105. However, since we cannot have a
fractional stuff, we round down to 130. Thus, we expect 130 stuffs fractional stuff, we round down to 130. Thus, we expect 130 stuffs
per packet. 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.
 End of changes. 26 change blocks. 
47 lines changed or deleted 42 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/