draft-ietf-ippm-owdp-07.txt   draft-ietf-ippm-owdp-08.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: April 2004 Anatoly Karp Expiration Date: November 2004 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
October 2003 May 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-07.txt> <draft-ietf-ippm-owdp-08.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 21, line 16 skipping to change at page 21, line 16
+ The number of packet records that will follow represented as an + The number of packet records that will follow represented as an
unsigned 4-octet integer. This number might be less than the unsigned 4-octet integer. This number might be less than the
Number of Packets in the reproduction of the Request-Session Number of Packets in the reproduction of the Request-Session
command because of a session that ended prematurely; or it might command because of a session that ended prematurely; or it might
be greater because of duplicates. be greater because of duplicates.
+ 12 octets of Integrity Zero Padding. + 12 octets of Integrity Zero Padding.
+ Zero or more (as specified) packet records. + Zero or more (as specified) packet records.
Each packet record is 24 octets, and includes 4 octets of sequence Each packet record is 25 octets, and includes 4 octets of sequence
number, 8 octets of send timestamp, 2 octets of send timestamp error number, 8 octets of send timestamp, 2 octets of send timestamp error
estimate, 8 octets of receive timestamp, and 2 octets of receive estimate, 8 octets of receive timestamp, and 2 octets of receive
timestamp error estimate (in this order). Packet records are sent timestamp error estimate and 1 octet of TTL (in this order):
out in the same order they are made when the results of the session
are recorded. Therefore, the data is in arrival order. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Timestamp |
08| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12| Send Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16| Receive Timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20| | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+
Packet records are sent out in the same order they are made when the
results of the session are recorded. Therefore, the data is in
arrival order.
Note that lost packets (if any losses were detected during the OWAMP- Note that lost packets (if any losses were detected during the OWAMP-
Test session) MUST appear in the sequence of packets. They can Test session) MUST appear in the sequence of packets. They can
appear either at the point when the loss was detected or at any later appear either at the point when the loss was detected or at any later
point. Lost packet records are distinguished by the receive point. Lost packet records are distinguished by the receive
timestamp consisting of a string of zero bits and an error estimate timestamp consisting of a string of zero bits and an error estimate
with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for
definition of these quantities and explanation of timestamp format definition of these quantities and explanation of timestamp format
and error estimate format). and error estimate format).
skipping to change at page 22, line 9 skipping to change at page 22, line 28
authenticated, and encrypted. All OWAMP-Test sessions spawned by an authenticated, and encrypted. All OWAMP-Test sessions spawned by an
OWAMP-Control session inherit its mode. OWAMP-Control session inherit its mode.
OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and
OWAMP-Test receiver can potentially all be different machines. (In a OWAMP-Test receiver can potentially all be different machines. (In a
typical case we expect that there will be only two machines.) typical case we expect that there will be only two machines.)
6.1. Sender Behavior 6.1. Sender Behavior
The sender sends the receiver a stream of packets with schedule as The sender sends the receiver a stream of packets with schedule as
specified in the Request-Session command. The format of the body of specified in the Request-Session command. The sender SHOULD set the
a UDP packet in the stream depends on the mode being used. TTL in the UDP packet to 255. The format of the body of a UDP packet
in the stream depends on the mode being used.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at page 25, line 18 skipping to change at page 25, line 20
generated independently of any other pseudo-random numbers mentioned generated independently of any other pseudo-random numbers mentioned
in this document). However, implementations MUST provide a in this document). However, implementations MUST provide a
configuration parameter, an option, or a different means of making configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros. Packet Padding consist of all zeros.
The time elapsed between packets is computed according to the slot The time elapsed between packets is computed according to the slot
schedule as mentioned in Request-Session command description. At schedule as mentioned in Request-Session command description. At
that point we skipped over the issue of computing exponentially that point we skipped over the issue of computing exponentially
distributed pseudo-random numbers in a reproducible fashion. distributed pseudo-random numbers in a reproducible fashion.
7. Computing Exponentially Distributed Pseudo-Random Numbers 7. Receiver Behavior
Receiver knows when the sender will send packets. The following
parameter is defined: Timeout (from Request-Session). Packets that
are delayed by more than Timeout are considered lost (or `as good as
lost'). Note that there is never an actual assurance of loss by the
network: a `lost' packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value of 255).
To the best of the authors' knowledge, this requirement was never
actually implemented (and of course only a complete and universal
implementation would ensure that packets don't travel for longer than
TTL seconds). Further, IPv4 specification makes no claims about the
time it takes the packet to traverse the last link of the path.
The choice of a reasonable value of Timeout is a problem faced by a
user of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications (such as
interactive `one-way ping') might wish to obtain the data faster than
that.
As packets are received,
+ Timestamp the received packet.
+ In authenticated or encrypted mode, decrypt first block (16
octets) of packet body.
+ Store the packet sequence number, send time, receive time, and the
TTL from the packet IP header for the results to be transferred.
+ Packets not received within the Timeout are considered lost. They
are recorded with their true seqno, presumed send time, receive
time consisting of a string of zero bits, and TTL of 255.
Implementations SHOULD fetch the TTL value from the IP header of the
packet. If an implementation does not fetch the actual TTL value
(the only good reason to not do so is inability to access the TTL
field of arriving packets), it MUST record the TTL value as 255.
Packets that are actually received are recorded in the order of
arrival. Lost packet records serve as indications of the send times
of lost packets. They SHOULD be placed either at the point where the
receiver learns about the loss or at any later point; in particular,
one MAY place all the records that correspond to lost packets at the
very end.
Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have to be
discarded. (Send timestamps in the future would normally indicate
clocks that differ by more than the delay. Some data -- such as
jitter -- can be extracted even without knowledge of time difference.
For other kinds of data, the adjustment is best handled by the data
consumer on the basis of the complete information in a measurement
session as well as possibly external data.)
Packets with a sequence number that was already observed (duplicate
packets) MUST be recorded normally. (Duplicate packets are sometimes
introduced by IP networks. The protocol has to be able to measure
duplication.)
If any of the following is true, the packet MUST be discarded:
+ Send timestamp is more than Timeout in the past or in the future.
+ Send timestamp differs by more than Timeout from the time when the
packet should have been sent according to its seqno.
+ In authenticated or encrypted mode, any of the bits of zero
padding inside the first 16 octets of packet body is non-zero.
8. Computing Exponentially Distributed Pseudo-Random Numbers
Here we describe the way exponential random quantities used in the Here we describe the way exponential random quantities used in the
protocol are generated. While there is a fair number of algorithms protocol are generated. While there is a fair number of algorithms
for generating exponential random variables, most of them rely on for generating exponential random variables, most of them rely on
having logarithmic function as a primitive, resulting in potentially having logarithmic function as a primitive, resulting in potentially
different values, depending on the particular implementation of the different values, depending on the particular implementation of the
math library. We use algorithm 3.4.1.S in [KNUTH], which is free math library. We use algorithm 3.4.1.S in [KNUTH], which is free
of the above mentioned problem, and guarantees the same output on any of the above mentioned problem, and guarantees the same output on any
implementation. The algorithm belongs to the 'ziggurat' family implementation. The algorithm belongs to the 'ziggurat' family
developed in the 1970s by G.Marsaglia, M.Sibuya and J.H.Ahrens developed in the 1970s by G.Marsaglia, M.Sibuya and J.H.Ahrens
[ZIGG]. It replaces the use of logarithmic function by clever bit [ZIGG]. It replaces the use of logarithmic function by clever bit
manipulation, still producing the exponential variates on output. manipulation, still producing the exponential variates on output.
7.1. High-Level Description of the Algorithm 8.1. High-Level Description of the Algorithm
For ease of exposition, the algorithm is first described with all For ease of exposition, the algorithm is first described with all
arithmetic operations being interpreted in their natural sense. arithmetic operations being interpreted in their natural sense.
Later, exact details on data types, arithmetic, and generation of the Later, exact details on data types, arithmetic, and generation of the
uniform random variates used by the algorithm are given. It is an uniform random variates used by the algorithm are given. It is an
almost verbatim quotation from [KNUTH], p.133. almost verbatim quotation from [KNUTH], p.133.
Algorithm S: Given a real positive number 'mu', produce an Algorithm S: Given a real positive number 'mu', produce an
exponential random variate with mean 'mu'. exponential random variate with mean 'mu'.
skipping to change at page 26, line 18 skipping to change at page 28, line 4
U = (.b0 b1 b2 ... b31) [note the decimal point] U = (.b0 b1 b2 ... b31) [note the decimal point]
Locate the first zero bit b_j, and shift off the leading (j+1) bits, Locate the first zero bit b_j, and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31) setting U <- (.b_{j+1} ... b31)
NOTE: in the rare case that the zero has not been found it is NOTE: in the rare case that the zero has not been found it is
prescribed that the algorithm return (mu*32*ln2). prescribed that the algorithm return (mu*32*ln2).
S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and
terminate the algorithm. (Note that Q[1] = ln2.) terminate the algorithm. (Note that Q[1] = ln2.)
S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k
new uniform random binary fractions U1,...,Uk and set V <- new uniform random binary fractions U1,...,Uk and set V <-
min(U1,...,Uk). min(U1,...,Uk).
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.
7.2. Data Types, Representation and Arithmetic 8.2. Data Types, Representation and Arithmetic
The high-level algorithm operates on real numbers -- typically The high-level algorithm operates on real numbers -- typically
represented as floating point numbers. This specification prescribes represented as floating point numbers. This specification prescribes
that unsigned 64-bit integers be used instead. that unsigned 64-bit integers be used instead.
u_int64_t integers are interpreted as real numbers by placing the u_int64_t integers are interpreted as real numbers by placing the
decimal point after the first 32 bits. In other words, conceptually decimal point after the first 32 bits. In other words, conceptually
the interpretation is given by the map: the interpretation is given by the map:
u_int64_t u; u_int64_t u;
skipping to change at page 27, line 33 skipping to change at page 29, line 13
Operation of addition is done as usual on u_int64_t numbers; however, Operation of addition is done as usual on u_int64_t numbers; however,
the operation of multiplication in the high-level algorithm should be the operation of multiplication in the high-level algorithm should be
replaced by replaced by
(u, v) |---> (u * v) >> 32 (u, v) |---> (u * v) >> 32
Implementations MUST compute (u * v) exactly. For example, a Implementations MUST compute (u * v) exactly. For example, a
fragment of unsigned 128-bit arithmetic can be implemented for this fragment of unsigned 128-bit arithmetic can be implemented for this
purpose (see sample implementation below). purpose (see sample implementation below).
7.3. Uniform Random Quantities 8.3. Uniform Random Quantities
The procedure for obtaining a sequence of 32-bit random numbers (such The procedure for obtaining a sequence of 32-bit random numbers (such
as 'U' in algorithm S) relies on using AES encryption in counter as 'U' in algorithm S) relies on using AES encryption in counter
mode. To describe the exact working of the algorithm we introduce two mode. To describe the exact working of the algorithm we introduce two
primitives from Rijndael. Their prototypes and specification are primitives from Rijndael. Their prototypes and specification are
given below, and they are assumed to be provided by the supporting given below, and they are assumed to be provided by the supporting
Rijndael implementation, such as [RIJN]. Rijndael implementation, such as [RIJN].
+ This function initializes a Rijndael key with bytes from 'seed' + This function initializes a Rijndael key with bytes from 'seed'
skipping to change at page 28, line 22 skipping to change at page 30, line 5
BlockEncrypt(key, c) BlockEncrypt(key, c)
U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1 U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1
U4. [Do output] Output the i_th quartet of octets from s starting U4. [Do output] Output the i_th quartet of octets from s starting
from high-order octets, converted to native byte order and from high-order octets, converted to native byte order and
represented as OWPNum64 value (as in 3.b). represented as OWPNum64 value (as in 3.b).
U5. [Loop] Go to step U2. U5. [Loop] Go to step U2.
7.4. Receiver Behavior 9. Security Considerations
Receiver knows when the sender will send packets. The following
parameter is defined: Timeout (from Request-Session). Packets that
are delayed by more that Timeout are considered lost (or `as good as
lost'). Note that there is never an actual assurance of loss by the
network: a `lost' packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value of 255).
To the best of the authors' knowledge, this requirement was never
actually implemented (and of course only a complete and universal
implementation would ensure that packets don't travel for longer than
TTL seconds). Further, IPv4 specification makes no claims about the
time it takes the packet to traverse the last link of the path.
The choice of a reasonable value of Timeout is a problem faced by a
user of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications (such as
interactive `one-way ping') might wish to obtain the data faster than
that.
As packets are received,
+ Timestamp the received packet.
+ In authenticated or encrypted mode, decrypt first block (16
octets) of packet body.
+ Store the packet sequence number, send times, and receive times
for the results to be transferred.
+ Packets not received within the Timeout are considered lost. They
are recorded with their seqno, presumed send time, and receive
time consisting of a string of zero bits.
Packets that are actually received are recorded in the order of
arrival. Lost packet records serve as indications of the send times
of lost packets. They SHOULD be placed either at the point where the
receiver learns about the loss or at any later point; in particular,
one MAY place all the records that correspond to lost packets at the
very end.
Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have to be
discarded. (Send timestamps in the future would normally indicate
clocks that differ by more than the delay. Some data -- such as
jitter -- can be extracted even without knowledge of time difference.
For other kinds of data, the adjustment is best handled by the data
consumer on the basis of the complete information in a measurement
session as well as possibly external data.)
Packets with a sequence number that was already observed (duplicate
packets) MUST be recorded normally. (Duplicate packets are sometimes
introduced by IP networks. The protocol has to be able to measure
duplication.)
If any of the following is true, packet MUST be discarded:
+ Send timestamp is more than Timeout in the past or in the future.
+ Send timestamp differs by more than Timeout from the time when the
packet should have been sent according to its seqno.
+ In authenticated or encrypted mode, any of the bits of zero
padding inside the first 16 octets of packet body is non-zero.
8. Security Considerations
The goal of authenticated mode to let one passphrase-protect service The goal of authenticated mode to let one passphrase-protect service
provided by a particular OWAMP-Control server. One can imagine a provided by a particular OWAMP-Control server. One can imagine a
variety of circumstances where this could be useful. Authenticated variety of circumstances where this could be useful. Authenticated
mode is designed to prohibit theft of service. mode is designed to prohibit theft of service.
Additional design objective of authenticated mode was to make it Additional design objective of authenticated mode was to make it
impossible for an attacker who cannot read traffic between OWAMP-Test impossible for an attacker who cannot read traffic between OWAMP-Test
sender and receiver to tamper with test results in a fashion that sender and receiver to tamper with test results in a fashion that
affects the measurements, but not other traffic. affects the measurements, but not other traffic.
skipping to change at page 30, line 39 skipping to change at page 30, line 39
client. client.
OWAMP-Test sessions could be used as covert channels of information. OWAMP-Test sessions could be used as covert channels of information.
Environments that are worried about covert channels should take this Environments that are worried about covert channels should take this
into consideration. into consideration.
Notice that AES in counter mode is used for pseudo-random number Notice that AES in counter mode is used for pseudo-random number
generation, so implementation of AES MUST be included even in a generation, so implementation of AES MUST be included even in a
server that only supports unauthenticated mode. server that only supports unauthenticated mode.
9. IANA Considerations 10. IANA Considerations
IANA is requested to allocate a well-known TCP port number for OWAMP- IANA is requested to allocate a well-known TCP port number for OWAMP-
Control part of the OWAMP protocol. Control part of the OWAMP protocol.
10. Internationalization Considerations 11. Internationalization Considerations
The protocol does not carry any information in a natural language. The protocol does not carry any information in a natural language.
11. Appendix A: Sample Implementation of Exponential Deviate Computation 12. Appendix A: Sample Implementation of Exponential Deviate Computation
/* /*
** Example usage: generate a stream of exponential (mean 1) ** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization). ** random quantities (ignoring error checking during initialization).
** If a variate with some mean mu other than 1 is desired, the output ** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules ** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described. ** of arithmetic we described.
** Assume that a 16-octet 'seed' has been initialized ** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example) ** (as the shared secret in OWAMP, for example)
skipping to change at page 36, line 8 skipping to change at page 36, line 8
V = OWPunif_rand64(next); V = OWPunif_rand64(next);
for (i = 2; i <= k; i++){ for (i = 2; i <= k; i++){
tmp = OWPunif_rand64(next); tmp = OWPunif_rand64(next);
if (tmp < V) if (tmp < V)
V = tmp; V = tmp;
} }
/* Step S4. Return (j+V)*ln2 */ /* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2); return OWPnum64_mul(OWPnum64_add(J, V), LN2);
} }
12. Appendix B: Test Vectors for Exponential Deviates 13. Appendix B: Test Vectors for Exponential Deviates
It is important that the test schedules generated by different It is important that the test schedules generated by different
implementations from identical inputs be identical. The non-trivial implementations from identical inputs be identical. The non-trivial
part is the generation of pseudo-random exponentially distributed part is the generation of pseudo-random exponentially distributed
deviates. To aid implementors in verifying interoperability, several deviates. To aid implementors in verifying interoperability, several
test vectors are provided. For each of the four given 128-bit values test vectors are provided. For each of the four given 128-bit values
of SID represented as hexadecimal numbers, 1,000,000 exponentially of SID represented as hexadecimal numbers, 1,000,000 exponentially
distributed 64-bit deviates are generated as described above. As distributed 64-bit deviates are generated as described above. As
they are generated, they are all added to each other. The sum of all they are generated, they are all added to each other. The sum of all
1,000,000 deviates is given as a hexadecimal number for each SID. An 1,000,000 deviates is given as a hexadecimal number for each SID. An
skipping to change at page 36, line 37 skipping to change at page 36, line 37
SID = 0x0102030405060708090a0b0c0d0e0f00 SID = 0x0102030405060708090a0b0c0d0e0f00
SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds) SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SID = 0xfeed0feed1feed2feed3feed4feed5ab SID = 0xfeed0feed1feed2feed3feed4feed5ab
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
13. Normative References 14. Normative References
[AES] Advanced Encryption Standard (AES), [AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/ http://csrc.nist.gov/encryption/aes/
[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
Implementation and Analysis', RFC 1305, March 1992. Implementation and Analysis', RFC 1305, March 1992.
[RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321, [RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321,
April 1992. April 1992.
skipping to change at page 37, line 25 skipping to change at page 37, line 25
[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay
Metric for IPPM', RFC 2679, September 1999. Metric for IPPM', RFC 2679, September 1999.
[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet
Loss Metric for IPPM', RFC 2680, September 1999. Loss Metric for IPPM', RFC 2680, September 1999.
[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior
Identification Codes', RFC 2836, May 2000. Identification Codes', RFC 2836, May 2000.
14. Informative References 15. Informative References
[ZIGG] G. Marsaglia, M. Sibuya and J.H. Ahrens, Communications of [ZIGG] G. Marsaglia, M. Sibuya and J.H. Ahrens, Communications of
ACM, 15 (1972), 876-877 ACM, 15 (1972), 876-877
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd
edition, 1998 edition, 1998
[RIJN] Reference ANSI C implementation of Rijndael [RIJN] Reference ANSI C implementation of Rijndael
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip
skipping to change at page 38, line 5 skipping to change at page 38, line 5
Group Meeting, http://www.ripe.net/test- Group Meeting, http://www.ripe.net/test-
traffic/Talks/9805_nluug.ps.gz. traffic/Talks/9805_nluug.ps.gz.
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An
Infrastructure for Network Performance Measurements', Infrastructure for Network Performance Measurements',
Proceedings of INET'99, June 1999. Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
15. Authors' Addresses 16. Authors' Addresses
Stanislav Shalunov <shalunov@internet2.edu> Stanislav Shalunov <shalunov@internet2.edu>
Benjamin Teitelbaum <ben@internet2.edu> Benjamin Teitelbaum <ben@internet2.edu>
Anatoly Karp <karp@math.wisc.edu> Anatoly Karp <ankarp@yahoo.com>
Jeff Boote <boote@internet2.edu> Jeff Boote <boote@internet2.edu>
Matthew J. Zekauskas <matt@internet2.edu> Matthew J. Zekauskas <matt@internet2.edu>
Expiration date: April 2004 Expiration date: November 2004
 End of changes. 

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