draft-ietf-ippm-owdp-12.txt   draft-ietf-ippm-owdp-13.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: June 2005 Anatoly Karp Expiration Date: June 2005 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
December 2004 December 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-12.txt> <draft-ietf-ippm-owdp-13.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 2, line 13 skipping to change at page 2, line 13
well as other unidirectional characteristics, such as one-way loss. well as other unidirectional characteristics, such as one-way loss.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship of Test and Control Protocols . . . . . . 4 1.1. Relationship of Test and Control Protocols . . . . . . 4
1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5 1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7 3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7 3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7
3.2. Values of the Accept Field . . . . . . . . . . . . . . 10 3.2. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 10
3.3. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11 3.3. Values of the Accept Field . . . . . . . . . . . . . . 11
3.4. Creating Test Sessions . . . . . . . . . . . . . . . . 11 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11
3.5. Send Schedules . . . . . . . . . . . . . . . . . . . . 16 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12
3.6. Starting Test Sessions . . . . . . . . . . . . . . . . 17 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17
3.7. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18
3.8. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 26 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 26 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27
4.1.2. Packet Format and Content . . . . . . . . . . . . 27 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 30 4.1.2. Packet Format and Content . . . . . . . . . . . . 28
5. Computing Exponentially Distributed Pseudo-Random Numbers . 32 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31
5.1. High-Level Description of the Algorithm . . . . . . . 32 5. Computing Exponentially Distributed Pseudo-Random Numbers . 33
5.2. Data Types, Representation, and Arithmetic . . . . . . 33 5.1. High-Level Description of the Algorithm . . . . . . . 33
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 34 5.2. Data Types, Representation, and Arithmetic . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . 35 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 35
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . 36
6.2. Preventing Third-Party Denial of Service . . . . . . . 36 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 36
6.3. Covert Information Channels . . . . . . . . . . . . . 36 6.2. Preventing Third-Party Denial of Service . . . . . . . 37
6.4. Requirement to Include AES in Implementations . . . . 36 6.3. Covert Information Channels . . . . . . . . . . . . . 37
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 36 6.4. Requirement to Include AES in Implementations . . . . 37
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 37 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 37
6.7. Required Properties of MD5 . . . . . . . . . . . . . . 38 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 38
6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 40 6.7. Required Properties of MD5 . . . . . . . . . . . . . . 39
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41 6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 41
8. Internationalization Considerations . . . . . . . . . . . . 41 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42
9. Appendix A: Sample C Code for Exponential Deviates . . . . 41 8. Internationalization Considerations . . . . . . . . . . . . 42
10. Appendix B: Test Vectors for Exponential Deviates . . . . 46 9. Appendix A: Sample C Code for Exponential Deviates . . . . 42
11. Normative References . . . . . . . . . . . . . . . . . . . 47 10. Appendix B: Test Vectors for Exponential Deviates . . . . 47
12. Informative References . . . . . . . . . . . . . . . . . . 47 11. Normative References . . . . . . . . . . . . . . . . . . . 48
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 12. Informative References . . . . . . . . . . . . . . . . . . 48
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has proposed The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC2680] across Internet paths. Although there are now several [RFC2680] across Internet paths. Although there are now several
measurement platforms that implement collection of these metrics measurement platforms that implement collection of these metrics
[SURVEYOR], [RIPE], there is not currently a standard that would [SURVEYOR] [RIPE] [BRIX], there is not currently a standard that
permit initiation of test streams or exchange of packets to collect would permit initiation of test streams or exchange of packets to
singleton metrics in an interoperable manner. collect singleton metrics in an interoperable manner.
With the increasingly wide availability of affordable global With the increasingly wide availability of affordable global
positioning systems (GPS) and CDMA-based time sources, hosts positioning systems (GPS) and CDMA-based time sources, hosts
increasingly have available to them very accurate time increasingly have available to them very accurate time
sources--either directly or through their proximity to Network Time sources--either directly or through their proximity to Network Time
Protocol (NTP) primary (stratum 1) time servers. By standardizing a Protocol (NTP) primary (stratum 1) time servers. By standardizing a
technique for collecting IPPM one-way active measurements, we hope to technique for collecting IPPM one-way active measurements, we hope to
create an environment where IPPM metrics may be collected across a create an environment where IPPM metrics may be collected across a
far broader mesh of Internet paths than is currently possible. One far broader mesh of Internet paths than is currently possible. One
particularly compelling vision is of widespread deployment of open particularly compelling vision is of widespread deployment of open
OWAMP servers that would make measurement of one-way delay as OWAMP servers that would make measurement of one-way delay as
commonplace as measurement of round-trip time using an ICMP-based commonplace as measurement of round-trip time using an ICMP-based
tool like ping. tool like ping.
Additional design goals of OWAMP include being hard to detect and Additional design goals of OWAMP include being hard to detect and
manipulate, security, logical separation of control and test manipulate, security, logical separation of control and test
functionality, and support for small test packets. functionality, and support for small test packets. (Being hard to
detect makes interference with measurements more difficult for
intermediaries in the middle of the network.)
OWAMP test traffic is hard to detect because it is simply a stream of OWAMP test traffic is hard to detect because it is simply a stream of
UDP packets from and to negotiated port numbers, with potentially UDP packets from and to negotiated port numbers, with potentially
nothing static in the packets (size is negotiated, as well). OWAMP nothing static in the packets (size is negotiated, as well). OWAMP
also supports an encrypted mode that further obscures the traffic, at also supports an encrypted mode that further obscures the traffic, at
the same time making it impossible to alter timestamps undetectably. the same time making it impossible to alter timestamps undetectably.
Security features include optional authentication and/or encryption Security features include optional authentication and/or encryption
of control and test messages. These features may be useful to of control and test messages. These features may be useful to
prevent unauthorized access to results or man-in-the-middle attackers prevent unauthorized access to results or man-in-the-middle attackers
skipping to change at page 9, line 11 skipping to change at page 9, line 11
that is the shared secret associated with Username. (Both the server that is the shared secret associated with Username. (Both the server
and the client use the same mappings from user names to secret keys. and the client use the same mappings from user names to secret keys.
The server, being prepared to conduct sessions with more than one The server, being prepared to conduct sessions with more than one
client, uses user names to choose the appropriate secret key; a client, uses user names to choose the appropriate secret key; a
client would typically have different secret keys for different client would typically have different secret keys for different
servers. The situation is analogous to that of passwords, except servers. The situation is analogous to that of passwords, except
that secret keys, rather than being the typical low-entropy that secret keys, rather than being the typical low-entropy
passwords, are suitable for use as AES keys.) The shared secret will passwords, are suitable for use as AES keys.) The shared secret will
typically be provided as a passphrase; in this case, the MD5 sum typically be provided as a passphrase; in this case, the MD5 sum
[RFC1321] of the passphrase (without possible newline character(s) at [RFC1321] of the passphrase (without possible newline character(s) at
the end of the passphrase) SHOULD be used as a key for encryption by the end of the passphrase) MUST be used as a key for encryption by
the client and decryption by the server (the passphrase also SHOULD the client and decryption by the server (the passphrase also MUST NOT
NOT contain newlines in the middle). contain newlines in the middle).
Session-key and Client-IV are generated randomly by the client. Session-key and Client-IV are generated randomly by the client.
Session-key MUST be generated with sufficient entropy not to reduce Session-key MUST be generated with sufficient entropy not to reduce
the security of the underlying cipher. Client-IV merely needs to be the security of the underlying cipher. Client-IV merely needs to be
unique (i.e., it MUST never be repeated for different sessions using unique (i.e., it MUST never be repeated for different sessions using
the same secret key; a simple way to achieve that without the use of the same secret key; a simple way to achieve that without the use of
cumbersome state is to generate the Client-IV strings using a cumbersome state is to generate the Client-IV strings using a
cryptographically secure pseudo-random number source: if this is cryptographically secure pseudo-random number source: if this is
done, the first repetition is unlikely to occur before 2^64 sessions done, the first repetition is unlikely to occur before 2^64 sessions
with the same secret key are conducted). with the same secret key are conducted).
The server MUST respond with the following message: The server MUST respond with the following message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Unused, MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | Accept | | | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Server-IV (16 octets) | | Server-IV (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime (Timestamp) | | Uptime (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IZP (8 octets) | | IZP (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unused 15-octet part MUST be zero. The client MUST ignore its The MBZ 15-octet part MUST be zero. The client MUST ignore its
value. MBZ (MUST be zero) fields here and hereafter have the same value. MBZ (MUST be zero) fields here and hereafter have the same
semantics: the party that sends the message MUST set the field to a semantics: the party that sends the message MUST set the field to a
string of zero bits; the party that interprets the message MUST string of zero bits; the party that interprets the message MUST
ignore the value. (This way the field could be used for future ignore the value. (This way the field could be used for future
extensions.) extensions.)
Server-IV is generated randomly by the server. In unauthenticated Server-IV is generated randomly by the server. In unauthenticated
mode, Server-IV is unused. mode, Server-IV is unused.
The Accept field indicates the server's willingness to continue The Accept field indicates the server's willingness to continue
skipping to change at page 10, line 40 skipping to change at page 10, line 40
Timestamp format is described in ``Sender Behavior'' section below. Timestamp format is described in ``Sender Behavior'' section below.
The same instantiation of the server SHOULD report the same exact The same instantiation of the server SHOULD report the same exact
Uptime value to each client in each session. Uptime value to each client in each session.
Integrity Zero Padding (IZP) is treated the same way as IZP in the Integrity Zero Padding (IZP) is treated the same way as IZP in the
next section and beyond. next section and beyond.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
3.2. Values of the Accept Field 3.2. Integrity Zero Padding (IZP)
IZP MUST be all zeros in all messages that use IZP. The recipient of
a message where IZP is not zero MUST reject the message, as it is an
indication of tampering with the content of the message by an
intermediary (or brokenness). If the message is part of
OWAMP-Control, the session MUST be terminated and results
invalidated. If the message is part of OWAMP-Test, it MUST be
silently ignored. This will ensure data integrity. In
unauthenticated mode, IZP is nothing more than a simple check. In
authenticated and encrypted modes, however, it ensures, in
conjunction with properties of CBC chaining mode, that everything
received before was not tampered with. For this reason, it is
important to check the IZP field as soon as possible, so that bad
data doesn't get propagated.
3.3. Values of the Accept Field
Accept values are used throughout the OWAMP-Control protocol to Accept values are used throughout the OWAMP-Control protocol to
communicate the server response to client requests. The full set of communicate the server response to client requests. The full set of
valid Accept field values are: valid Accept field values are:
0 OK. 0 OK.
1 Failure, reason unspecified (catch-all). 1 Failure, reason unspecified (catch-all).
2 Internal error. 2 Internal error.
skipping to change at page 11, line 18 skipping to change at page 11, line 34
5 Cannot perform request due to temporary resource limitations. 5 Cannot perform request due to temporary resource limitations.
All other values are reserved. The sender of the message MAY use the All other values are reserved. The sender of the message MAY use the
value of 1 for all non-zero Accept values. A message sender SHOULD value of 1 for all non-zero Accept values. A message sender SHOULD
use the correct Accept value if it is going to use other values. The use the correct Accept value if it is going to use other values. The
message receiver MUST interpret all values of Accept other than these message receiver MUST interpret all values of Accept other than these
reserved values as 1. This way, other values are available for reserved values as 1. This way, other values are available for
future extensions. future extensions.
3.3. OWAMP-Control Commands 3.4. OWAMP-Control Commands
In authenticated or encrypted mode (which are identical as far as In authenticated or encrypted mode (which are identical as far as
OWAMP-Control is concerned, and only differ in OWAMP-Test) all OWAMP-Control is concerned, and only differ in OWAMP-Test) all
further communications are encrypted with the Session-key, using CBC further communications are encrypted with the Session-key, using CBC
mode. The client encrypts its stream using Client-IV. The server mode. The client encrypts its stream using Client-IV. The server
encrypts its stream using Server-IV. encrypts its stream using Server-IV.
The following commands are available for the client: Request-Session, The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Sessions, and Fetch-Session. The command Start-Sessions, Stop-Sessions, and Fetch-Session. The command
Stop-Sessions is available to both the client and the server. (The Stop-Sessions is available to both the client and the server. (The
server can also send other messages in response to commands it server can also send other messages in response to commands it
receives.) receives.)
After Start-Sessions is sent/received by the client/server, and After the client sends the Start-Sessions command and until it both
before it both sends and receives Stop-Sessions (order unspecified), sends and receives (in an unspecified order) the Stop-Sessions
it is said to be conducting active measurements. command, it is said to be conducting active measurements. Similarly,
the server is said to be conducting active measurements after it
receives the Start-Sessions command and until it both sends and
receives (in an unspecified order) the Stop-Sessions command.
While conducting active measurements, the only command available is While conducting active measurements, the only command available is
Stop-Sessions. Stop-Sessions.
These commands are described in detail below. These commands are described in detail below.
3.4. Creating Test Sessions 3.5. Creating Test Sessions
Individual one-way active measurement sessions are established using Individual one-way active measurement sessions are established using
a simple request/response protocol. An OWAMP client MAY issue zero or a simple request/response protocol. An OWAMP client MAY issue zero or
more Request-Session messages to an OWAMP server, which MUST respond more Request-Session messages to an OWAMP server, which MUST respond
to each with an Accept-Session message. An Accept-Session message to each with an Accept-Session message. An Accept-Session message
MAY refuse a request. MAY refuse a request.
The format of Request-Session message is as follows: The format of Request-Session message is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 12, line 19 skipping to change at page 13, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots | | Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets | | Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port | | Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address | | Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Sender Address (cont.) or MBZ | | Sender Address (cont.) or MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address | | Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Receiver Address (cont.) or MBZ | | Receiver Address (cont.) or MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length | | Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time | | Start Time |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout | | Timeout, (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor | | Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by one or more schedule slot This is immediately followed by one or more schedule slot
descriptions (the number of schedule slots is specified in the descriptions (the number of schedule slots is specified in the
`Number of Schedule Slots' field above): `Number of Schedule Slots' field above):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | | | Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ | +-+-+-+-+-+-+-+-+ MBZ (15 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) | | Slot Parameter (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are immediately followed by IZP: These are immediately followed by IZP:
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
skipping to change at page 15, line 12 skipping to change at page 16, line 12
Conf-Sender is not set, the Type-P Descriptor is a declaration of how Conf-Sender is not set, the Type-P Descriptor is a declaration of how
the sender will be configured. the sender will be configured.
If Conf-Sender is set and the server does not recognize the Type-P If Conf-Sender is set and the server does not recognize the Type-P
Descriptor, or it cannot or does not wish to set the corresponding Descriptor, or it cannot or does not wish to set the corresponding
attributes on OWAMP-Test packets, it SHOULD reject the session attributes on OWAMP-Test packets, it SHOULD reject the session
request. If Conf-Sender is not set, the server SHOULD accept or request. If Conf-Sender is not set, the server SHOULD accept or
reject the session paying no attention to the value of the Type-P reject the session paying no attention to the value of the Type-P
Descriptor. Descriptor.
IZP MUST be all zeros in this and all messages that use IZP. The
recipient of a message where IZP is not zero MUST reject the message,
as it is an indication of tampering with the content of the message
by an intermediary (or brokenness). If the message is part of
OWAMP-Control, the session MUST be terminated and results
invalidated. If the message is part of OWAMP-Test, it MUST be
silently ignored. This will ensure data integrity. In
unauthenticated mode, IZP is nothing more than a simple check. In
authenticated and encrypted modes, however, it ensures, in
conjunction with properties of CBC chaining mode, that everything
received before was not tampered with. For this reason, it is
important to check the IZP field as soon as possible, so that bad
data doesn't get propagated.
To each Request-Session message, an OWAMP server MUST respond with an To each Request-Session message, an OWAMP server MUST respond with an
Accept-Session message: Accept-Session message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Unused | Port | | Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (12 octets) | | IZP (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 27 skipping to change at page 17, line 12
number belonging to the generating machine, an 8-octet timestamp, and number belonging to the generating machine, an 8-octet timestamp, and
a 4-octet random value. To reduce the probability of collisions, if a 4-octet random value. To reduce the probability of collisions, if
the generating machine has any IPv4 addresses (with the exception of the generating machine has any IPv4 addresses (with the exception of
loopback), one of them SHOULD be used for SID generation, even if all loopback), one of them SHOULD be used for SID generation, even if all
communication is IPv6-based. If it has no IPv4 addresses at all, the communication is IPv6-based. If it has no IPv4 addresses at all, the
last four octets of an IPv6 address MAY be used instead. Note that last four octets of an IPv6 address MAY be used instead. Note that
SID is always chosen by the receiver. If truly random values are not SID is always chosen by the receiver. If truly random values are not
available, it is important that the SID be made unpredictable, as available, it is important that the SID be made unpredictable, as
knowledge of the SID might be used for access control. knowledge of the SID might be used for access control.
3.5. Send Schedules 3.6. Send Schedules
The sender and the receiver both need to know the same send schedule. The sender and the receiver both need to know the same send schedule.
This way, when packets are lost, the receiver knows when they were This way, when packets are lost, the receiver knows when they were
supposed to be sent. It is desirable to compress common schedules supposed to be sent. It is desirable to compress common schedules
and still to be able to use an arbitrary one for the test sessions. and still to be able to use an arbitrary one for the test sessions.
In many cases, the schedule will consist of repeated sequences of In many cases, the schedule will consist of repeated sequences of
packets: this way, the sequence performs some test, and the test is packets: this way, the sequence performs some test, and the test is
repeated a number of times to gather statistics. repeated a number of times to gather statistics.
To implement this, we have a schedule with a given number of slots. To implement this, we have a schedule with a given number of slots.
skipping to change at page 17, line 29 skipping to change at page 18, line 17
+ Periodic stream: a single slot of type 1; + Periodic stream: a single slot of type 1;
+ Poisson stream of back-to-back packet pairs: two slots -- type 0 + Poisson stream of back-to-back packet pairs: two slots -- type 0
with a non-zero parameter and type 1 with a zero parameter. with a non-zero parameter and type 1 with a zero parameter.
Further, a completely arbitrary schedule can be specified (albeit Further, a completely arbitrary schedule can be specified (albeit
inefficiently) by making the number of test packets equal to the inefficiently) by making the number of test packets equal to the
number of schedule slots. In this case, the complete schedule is number of schedule slots. In this case, the complete schedule is
transmitted in advance of an OWAMP-Test session. transmitted in advance of an OWAMP-Test session.
3.6. Starting Test Sessions 3.7. Starting Test Sessions
Having requested one or more test sessions and received affirmative Having requested one or more test sessions and received affirmative
Accept-Session responses, an OWAMP client MAY start the execution of Accept-Session responses, an OWAMP client MAY start the execution of
the requested test sessions by sending a Start-Sessions message to the requested test sessions by sending a Start-Sessions message to
the server. the server.
The format of this message is as follows: The format of this message is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | | | 2 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (15 octets) | | MBZ (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Start-Ack message (which SHOULD be The server MUST respond with an Start-Ack message (which SHOULD be
sent as quickly as possible). Start-Ack messages have the following sent as quickly as possible). Start-Ack messages have the following
format: format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | | | Accept | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (15 octets) | | MBZ (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is non-zero, the Start-Sessions request was rejected; zero If Accept is non-zero, the Start-Sessions request was rejected; zero
skipping to change at page 19, line 5 skipping to change at page 19, line 35
The server SHOULD start all OWAMP-Test streams immediately after it The server SHOULD start all OWAMP-Test streams immediately after it
sends the response or immediately after their specified start times, sends the response or immediately after their specified start times,
whichever is later. If the client represents a Sender, the client whichever is later. If the client represents a Sender, the client
SHOULD start its OWAMP-Test streams immediately after it sees the SHOULD start its OWAMP-Test streams immediately after it sees the
Start-Ack response from the Server (if the Start-Sessions command was Start-Ack response from the Server (if the Start-Sessions command was
accepted) or immediately after their specified start times, whichever accepted) or immediately after their specified start times, whichever
is later. See more on OWAMP-Test sender behavior in a separate is later. See more on OWAMP-Test sender behavior in a separate
section below. section below.
3.7. Stop-Sessions 3.8. Stop-Sessions
The Stop-Sessions message may be issued by either the Control-Client The Stop-Sessions message may be issued by either the Control-Client
or the Server. The format of this command is as follows: or the Server. The format of this command is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | Unused | | 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions | | Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more session description This is immediately followed by zero or more session description
records (the number of session description records is specified in records (the number of session description records is specified in
the ``Number of Sessions'' field above). The session description the ``Number of Sessions'' field above). The session description
record is used to indicate which packets were actually sent by the record is used to indicate which packets were actually sent by the
sender process (rather than skipped). The header of the session sender process (rather than skipped). The header of the session
description record is as follows: description record is as follows:
skipping to change at page 22, line 20 skipping to change at page 22, line 43
completed time for send endpoints to ensure the Stop-Sessions message completed time for send endpoints to ensure the Stop-Sessions message
reaches the receiver endpoint after Timeout. reaches the receiver endpoint after Timeout.
To effect a premature stop of sessions, the party that initiates this To effect a premature stop of sessions, the party that initiates this
command MUST stop its OWAMP-Test send streams to send the Session command MUST stop its OWAMP-Test send streams to send the Session
Packets Sent values before sending this command. That party SHOULD Packets Sent values before sending this command. That party SHOULD
wait until receiving the response Stop-Sessions message before wait until receiving the response Stop-Sessions message before
stopping the receiver streams so that it can use the values from the stopping the receiver streams so that it can use the values from the
received Stop-Sessions message to validate the data. received Stop-Sessions message to validate the data.
3.8. Fetch-Session 3.9. Fetch-Session
The format of this client command is as follows: The format of this client command is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | | | 4 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (7 octets) | | MBZ (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq | | Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq | | End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 18 skipping to change at page 24, line 8
between Start-Sessions and Stop-Sessions, incomplete requests can between Start-Sessions and Stop-Sessions, incomplete requests can
only happen on a different OWAMP-Control connection (from the same or only happen on a different OWAMP-Control connection (from the same or
different host as Control-Client). different host as Control-Client).
The server MUST respond with a Fetch-Ack message. The format of this The server MUST respond with a Fetch-Ack message. The format of this
server response is as follows: server response is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | Unused (2 octets) | | Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno | | Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges | | Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records | | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (16 octets) |
| | | |
skipping to change at page 47, line 10 skipping to change at page 48, line 10
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)
11. Normative References 11. 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,
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.
[RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3',
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC2119] S. Bradner, `Key words for use in RFCs to Indicate [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate
Requirement Levels', RFC 2119, March 1997. Requirement Levels', RFC 2119, March 1997.
[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for
skipping to change at page 47, line 40 skipping to change at page 48, line 37
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.
12. Informative References 12. Informative References
[BRIX] Brix Networks, http://www.brixnet.com/
[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.
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, [MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,
Handbook of Applied Cryptography, CRC Press, revised reprint Handbook of Applied Cryptography, CRC Press, revised reprint
with updates, 1997. with updates, 1997.
[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.
skipping to change at page 48, line 23 skipping to change at page 49, line 21
Group Meeting, Group Meeting,
http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz. http://www.ripe.net/test-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
[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
Implementation and Analysis', RFC 1305, March 1992.
13. Authors' Addresses 13. Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48108 Ann Arbor, MI 48104
Telephone: +1-734-995-7060
Email: shalunov@internet2.edu Email: shalunov@internet2.edu
SIP: shalunov@internet2.edu SIP: shalunov@internet2.edu
Benjamin Teitelbaum Benjamin Teitelbaum
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48108 Ann Arbor, MI 48104
Email: ben@internet2.edu Email: ben@internet2.edu
SIP: ben@internet2.edu SIP: ben@internet2.edu
Anatoly Karp Anatoly Karp
4710 Regent St, Apt 81B 4710 Regent St, Apt 81B
Madison, WI 53705 Madison, WI 53705
Telephone: +1-608-347-6255 Telephone: +1-608-347-6255
Email: ankarp@charter.net Email: ankarp@charter.net
Jeff W. Boote Jeff W. Boote
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48108 Ann Arbor, MI 48104
Email: boote@internet2.edu Email: boote@internet2.edu
SIP: boote@internet2.edu SIP: boote@internet2.edu
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48108 Ann Arbor, MI 48104
Email: matt@internet2.edu Email: matt@internet2.edu
SIP: matt@internet2.edu
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
on the procedures with respect to rights in RFC documents can be found on the procedures with respect to rights in RFC documents can be found
 End of changes. 

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