draft-ietf-ippm-owdp-01.txt   draft-ietf-ippm-owdp-02.txt 
Network Working Group S. Shalunov Network Working Group S. Shalunov
Expiration Date: June 2001 B. Teitelbaum Expiration Date: August 2001 B. Teitelbaum
Advanced Network & Services and Internet2 Advanced Network & Services and Internet2
M. Zekauskas M. Zekauskas
Advanced Network & Services Advanced Network & Services
December 2000 February 2001
A One-way Delay Measurement Protocol A One-way Delay Measurement Protocol
<draft-ietf-ippm-owdp-01.txt> <draft-ietf-ippm-owdp-02.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 2, line 18 skipping to change at page 2, line 18
increasingly have available to them very accurate time increasingly have available to them very accurate time
sources--either directly or through their proximity to NTP primary sources--either directly or through their proximity to NTP primary
(stratum 1) time servers. By standardizing a technique for (stratum 1) time servers. By standardizing a technique for
collecting IPPM one-way delay measurements, we hope to create an collecting IPPM one-way delay measurements, we hope to create an
environment where IPPM metrics may be collected across a far broader environment where IPPM metrics may be collected across a far broader
mesh of Internet paths than is currently possible. One particularly mesh of Internet paths than is currently possible. One particularly
compelling vision is of widespread deployment of open OWDP servers compelling vision is of widespread deployment of open OWDP servers
that would make measurement of one-way delay as commonplace as that would make measurement of one-way delay as commonplace as
measurement of round-trip time using an ICMP-based tool like ping. measurement of round-trip time using an ICMP-based tool like ping.
Additional design goals of OWDP include stealth, security, logical Additional design goals of OWDP include being hard to detect and
separation of control and test functionality, and support for small manipulate, security, logical separation of control and test
test packets. functionality, and support for small test packets.
Stealth is achieved by making test packet streams look as much as OWDP test traffic is hard to detect, because it is simply a stream of
possible like ordinary Internet traffic. Towards this goal, OWDP's UDP packets from and to negotiated port numbers with potentially
test protocol is layered over UDP and allows for a wide range of nothing static in the packets (size is negotiated, too).
packet sizes and port numbers. Additionally, OWDP supports an Additionally, OWDP supports an encrypted mode, that further obscures
encrypted mode that obscures all transmitted data, making detection the traffic, at the same time making it impossible to alter
of OWDP test activity by Internet service providers very difficult. 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
who attempt to provide special treatment to OWDP test streams or who who attempt to provide special treatment to OWDP test streams or who
attempt to modify sender-generated timestamps to falsify test attempt to modify sender-generated timestamps to falsify test
results. results.
2.1. Relationship of Test and Control Protocols
OWDP actually consists of two inter-related protocols: OWDP-Control OWDP actually consists of two inter-related protocols: OWDP-Control
and OWDP-Test. OWDP-Control is used to initiate, start, stop and and OWDP-Test. OWDP-Control is used to initiate, start, stop and
retrieve test sessions, while OWDP-Test is the actual one-way delay retrieve test sessions, while OWDP-Test is used to exchange test
test protocol that exchanges singleton test packets between two packets between two measurement nodes.
measurement nodes.
Although OWDP-Test may be used in conjunction with a control protocol
other than OWDP-Control, the authors have deliberately chosen to
include both protocols in the same draft to encourage the
implementation and deployment of OWDP-Control as a common denominator
control protocol for one-way delay measurement. Having a complete and
open one-way delay measurement solution that is simple to implement
and deploy is crucial to assuring a future in which inter-domain one-
way delay measurement could become as commonplace as ping. We neither
anticipate nor recommend that OWDP-Control form the foundation of a
general purpose, extensible, measurement and monitoring control
protocol.
OWDP-Control is designed to support the negotiation of one-way delay
measurement sessions and results retrieval in a straightforward
manner. At session initiation, there is a negotiation of sender and
receiver addresses and port numbers, session start time, session
length, test packet size, the mean Poisson sampling interval for the
test stream, and some attributes of the very general RFC 2330 notion
of "packet type", including packet size and per-hop behavior (PHB)
[RFC2474], which could be used to support the measurement of one-way
delay across diff-serv networks. Additionally, OWDP-Control supports
per-session encryption and authentication for both test and control
traffic, measurement servers which may act as proxies for test stream
endpoints, and the exchange of a seed value for the pseudo-random
Poisson process that describes the test stream generated by the
sender.
We believe that OWDP-Control can effectively support one-way delay
measurement in a variety of environments, from publicly accessible
delay "beacons" running on arbitrary hosts to network monitoring
deployments within private corporate intra-nets. If integration with
SNMP or proprietary network management protocols is required,
gateways may be created.
2.2. Logical Model
Several roles are logically separated to allow for broad flexibility Several roles are logically separated to allow for broad flexibility
in use. Specifically, we define: in use. Specifically, we define:
Session-Sender the sending endpoint of an OWDP-Test session; Session-Sender the sending endpoint of an OWDP-Test session;
Session-Receiver the receiving endpoint of an OWDP-Test session; Session-Receiver the receiving endpoint of an OWDP-Test session;
Server an end system that manages one or more OWDP-Test Server an end system that manages one or more OWDP-Test
sessions, is capable of configuring per-session sessions, is capable of configuring per-session
skipping to change at page 4, line 11 skipping to change at page 5, line 7
Finally, because many Internet paths include segments that transport Finally, because many Internet paths include segments that transport
IP over ATM, delay and loss measurements can include the effects of IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWDP has been ATM segmentation and reassembly (SAR). Consequently, OWDP has been
designed to allow for small test packets that would fit inside the designed to allow for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in payload of a single ATM cell (this is only achieved in
unauthenticated and encrypted modes). unauthenticated and encrypted modes).
3. Protocol Overview 3. Protocol Overview
OWDP consists of two inter-related protocols: OWDP-Control and OWDP- As described above, OWDP consists of two inter-related protocols:
Test. The former is layered over TCP and is used to initiate and OWDP-Control and OWDP-Test. The former is layered over TCP and is
control measurement sessions and to fetch their results. The latter used to initiate and control measurement sessions and to fetch their
protocol is layered over UDP and is used to send singleton results. The latter protocol is layered over UDP and is used to send
measurement packets along the Internet path under test. singleton measurement packets along the Internet path under test.
The initiator of the measurement session establishes a TCP connection The initiator of the measurement session establishes a TCP connection
to a well-known port on the target point and this connection remains to a well-known port on the target point and this connection remains
open for the duration of the OWDP-Test sessions. IANA will be open for the duration of the OWDP-Test sessions. IANA will be
requested to allocate a well-known port number for OWDP-Control requested to allocate a well-known port number for OWDP-Control
sessions. An OWDP server SHOULD listen to this well-known port. sessions. An OWDP server SHOULD listen to this well-known port.
OWDP-Control messages are transmitted only before OWDP-Test sessions OWDP-Control messages are transmitted only before OWDP-Test sessions
are actually started and after they complete (with the possible are actually started and after they complete (with the possible
exception of an early Stop-Session message). exception of an early Stop-Session message).
The OWDP-Control and OWDP-Test protocols support three modes of The OWDP-Control and OWDP-Test protocols support three modes of
operation: unauthenticated, authenticated, and encrypted. The operation: unauthenticated, authenticated, and encrypted. The
authenticated or encrypted modes require endpoints to possess a authenticated or encrypted modes require endpoints to possess a
shared secret. shared secret.
All multi-octet quantities defined in this document are represented
in network byte order.
4. OWDP-Control 4. OWDP-Control
Each type of OWDP-Control message has a fixed length. The recipient
will know the full length of a message after examining first 16
octets of it. No message is shorter than 16 octets.
If the full message is not received within 30 minutes after it is
expected, connection SHOULD be dropped.
4.1. Connection Setup 4.1. Connection Setup
Before either a Control-Client or a Retrieve-Client can issue Before either a Control-Client or a Retrieve-Client can issue
commands of a Server, it must establish a connection to the server. commands of a Server, it must establish a connection to the server.
First, a client opens a TCP connection to the server on a well-known First, a client opens a TCP connection to the server on a well-known
port. The server responds with a server greeting: port. The server responds with a server greeting:
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 (15 octets) . | Unused (12 octets) |
. . | |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Modes | | Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . | Challenge (16 octets) |
. Challenge (16 octets) . | |
. .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following mode values are meaningful: 1 for unauthenticated, 2 The following mode values are meaningful: 1 for unauthenticated, 2
for authenticated, 4 for encrypted. The value of the Modes field for authenticated, 4 for encrypted. The value of the Modes field
sent by the server is the bit-wise OR of the mode values that it is sent by the server is the bit-wise OR of the mode values that it is
willing to support during this session. willing to support during this session.
If the Modes octet is zero, the server doesn't wish to communicate If Modes value is zero, the server doesn't wish to communicate with
with the client and MAY close the connection immediately. The client the client and MAY close the connection immediately. The client
SHOULD close the connection if it gets a greeting with Modes equal to SHOULD close the connection if it gets a greeting with Modes equal to
zero. zero.
Otherwise, the client MUST respond with the following message: Otherwise, the client 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Unused | | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KID | | KID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Token (32 octets) . . Token (32 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 6, line 4 skipping to change at page 6, line 51
. Token (32 octets) . . Token (32 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Client-IV (16 octets) . . Client-IV (16 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here Mode is the mode that the client chooses to use during this Here Mode is the mode that the client chooses to use during this
OWDP-Control session. It will also be used for all OWDP-Test OWDP-Control session. It will also be used for all OWDP-Test
sessions started under control of this OWDP-Control session. sessions started under control of this OWDP-Control session. In
Mode, one or zero bits MUST be set.
In unauthenticated mode, KID, Token, and Client-IV are unused. In unauthenticated mode, KID, Token, and Client-IV are unused.
Otherwise, KID (key ID) is a 4-octet indicator of which shared secret Otherwise, KID (key ID) is a 4-octet indicator of which shared secret
the client wishes to use to authenticate or encrypt and Token is the the client wishes to use to authenticate or encrypt and Token is the
concatenation of a 16-octet challenge and a 16-octet Session-key, concatenation of a 16-octet challenge and a 16-octet Session-key,
encrypted using the AES (Advanced Encryption Standard) [AES] in encrypted using the AES (Advanced Encryption Standard) [AES] in
Cipher Block Chaining (CBC). Encryption MUST be performed using an Cipher Block Chaining (CBC). Encryption MUST be performed using an
Initialization Vector (IV) of zero and a key value that is the shared Initialization Vector (IV) of zero and a key value that is the shared
secret associated with KID. secret associated with KID.
Session-key and Client-IV are generated randomly by the client. Session-key and Client-IV are generated randomly by the client.
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 (15 octets) . | Unused (15 octets) |
. . | |
. +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| | Yes/No | | | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . | Server-IV (16 octets) |
. Server-IV (16 octets) . | |
. .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A zero value in the "Yes/No" field means that the server accepts the A zero value in the Accept field means that the server accepts the
authentication and is willing to conduct further transactions. Any authentication and is willing to conduct further transactions. Any
non-zero value means that the server does not accept the non-zero value means that the server does not accept the
authentication provided by the client or, for some other reason, is authentication provided by the client or, for some other reason, is
not willing to conduct further transactions in this OWDP-Control not willing to conduct further transactions in this OWDP-Control
session. If a "No" response is sent, the server MAY close the session. If a negative response is sent, the server MAY and the
connection after this message. The client SHOULD close the client SHOULD close the connection after this message.
connection if it gets message that says "No" at this stage.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
4.2. OWDP-Control Commands 4.2. OWDP-Control Commands
In authenticated or encrypted mode (which are identical as far as In authenticated or encrypted mode (which are identical as far as
OWDP-Control is concerned, and only differ in OWDP-Test) all further OWDP-Control is concerned, and only differ in OWDP-Test) all further
communications are encrypted with the Session-key, using CBC mode. communications are encrypted with the Session-key, using CBC mode.
The client encrypts its stream using Client-IV. The server encrypts The client encrypts its stream using Client-IV. The server encrypts
its stream using Server-IV. its stream using Server-IV.
skipping to change at page 8, line 29 skipping to change at page 9, line 29
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port | | Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Flags | PHB ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inv-Lambda | | Inv-Lambda |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packets | | Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length | | Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time | | Start Time |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Precision | Receiver Precision | | Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding | | Zero Padding (16 octets) |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here the first octet (1) indicates that this is Request-Session Here the first octet (1) indicates that this is Request-Session
command. command.
IPVN-S and IPVN-R are IP version numbers for Sender and Receiver. In IPVN-S and IPVN-R are IP version numbers for Sender and Receiver. In
the case of IP version number being 4, twelve unused octets follow the case of IP version number being 4, twelve unused octets follow
the four-octet address. the four-octet address.
Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is
being asked to configure the corresponding agent (sender or being asked to configure the corresponding agent (sender or
receiver). In this case, the corresponding Port value SHOULD be receiver). In this case, the corresponding Port value SHOULD be
disregarded by the server. At least one of Conf-Sender and Conf- disregarded by the server. At least one of Conf-Sender and Conf-
Receiver MUST be 1. Receiver MUST be 1. (Both can be set, in which case the server is
being asked to perform a session between two hosts it can configure.)
The Sender Address and Receiver Address fields contain respectively The Sender Address and Receiver Address fields contain respectively
the sender and receiver addresses of the end points of the Internet the sender and receiver addresses of the end points of the Internet
path over which an OWDP test session is requested. path over which an OWDP test session is requested.
If Conf-Sender is not set, Sender Port is the UDP port OWDP-Test
packets will be sent from. If Conf-Receiver is not set, Receiver
Port is the UDP port OWDP-Test packets are requested to be sent to.
SID is the session identifier. It can be used in later sessions as SID is the session identifier. It can be used in later sessions as
an argument for Retrieve-Session command. It is meaningful only if an argument for Retrieve-Session command. It is meaningful only if
Conf-Receiver is 1. Conf-Receiver is 1.
The field Inv-Lambda is an unsigned integer and is the scaled The field Inv-Lambda is an unsigned integer and is the scaled
reciprocal of rate (in microseconds) at which the Poisson test stream reciprocal of rate (in microseconds) at which the Poisson test stream
is to be generated. This allows the average Poisson sampling is to be generated. This allows the average Poisson sampling
interval for the requested test session to be set to between 1 interval for the requested test session to be set to between 1
microsecond and over an hour. microsecond and over an hour.
The value Packets is the number of active measurement packets to be The value Packets is the number of active measurement packets to be
sent during this OWDP-Test session (note that both server and client sent during this OWDP-Test session (note that both server and client
can abort the session early). can abort the session early).
Padding length is the number of octets to be appended to normal OWDP- Padding length is the number of octets to be appended to normal OWDP-
Test packet (see more on padding in discussion of OWDP-Test). Test packet (see more on padding in discussion of OWDP-Test).
Start Time is the time when the session is to be started (but not Start Time is the time when the session is to be started (but not
before Start-Sessions command is issued). before Start-Sessions command is issued). This timestamp is in the
same format as OWDP-Test timestamps.
Sender Precision and Receiver Precision are signed integers in the Type-P Descriptor covers only a subset of (very large) Type-P space.
range +32 to -32 indicating the precision of the corresponding If the first two bits of Type-P Descriptor are 00, then subsequent 6
clocks, in seconds to the nearest power of two, as described in bits specify the requested Differentiated Services Codepoint (DSCP)
RFC 958. Sender Precision is meaningful only if Conf-Sender is not value of sent OWDP-Test packets as defined in RFC 2474. If the first
set. Receiver Precision is meaningful only if Conf-Receiver is not two bits of Type-P descriptor are 01, then subsequent 16 bits specify
set. the requested Per Hop Behavior Identification Code (PHB ID) as
defined in RFC 2836.
Therefore, the value of all zeros specifies the default best-effort
service.
If Conf-Sender is set, Type-P Descriptor is to be used to configure
the sender to send packets according to its value. If Conf-Sender is
not set, Type-P Descriptor is a declaration of how the sender will be
configured.
If Conf-Sender is set and the server doesn't recognize Type-P
Descriptor, cannot or does not wish to set the corresponding
attributes on OWDP-Test packets, it SHOULD reject the session
request. If Conf-Sender is not set, the server SHOULD accept the
session regardless of the value of Type-P Descriptor.
To each Request-Session message, an OWDP server MUST respond with an To each Request-Session message, an OWDP 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 | Unused | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Precision | Receiver Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Zero Padding |
| |
| | | |
| Zero Padding (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zero in the Accept field means that the server is willing to conduct Zero in the Accept field means that the server is willing to conduct
the session. Any non-zero value indicates rejection of the request. the session. Any non-zero value indicates rejection of the request.
If the server rejects a Request-Session command, it SHOULD not close If the server rejects a Request-Session command, it SHOULD not close
the TCP connection. The client MAY close it if it gets negative the TCP connection. The client MAY close it if it gets negative
response to Request-Session. response to Request-Session.
skipping to change at page 11, line 19 skipping to change at page 12, line 24
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 | | Unused (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Control-Ack message (which SHOULD be The server MUST respond with an Control-Ack message (which SHOULD be
sent as quickly as possible). Control-Ack messages have the following sent as quickly as possible). Control-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 | | Unused (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept has any non-zero value, the Start-Sessions request was If Accept has any non-zero value, the Start-Sessions request was
skipping to change at page 12, line 23 skipping to change at page 14, line 10
4.5. Stop-Sessions 4.5. 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 | | | 3 | Accept | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Unused | | Unused (14 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normally, the client SHOULD send this command after the OWDP-Test Normally, the client SHOULD send this command after the OWDP-Test
skipping to change at page 13, line 14 skipping to change at page 15, line 10
4.6. Retrieve-Session 4.6. Retrieve-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 | | Unused (17 octets) |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begin Seq is the sequence number of the first requested packet. End
Seq is the sequence number of the last requested packet. If Begin
Seq is all zeros and End Seq is all ones, complete session is said to
be requested.
If a complete session is requested and the session is still in
progress, or has terminated in any way other than normal, the request
to retrieve session results MUST be denied. If an incomplete session
is requested, all packets received so far that fall into the
requested range SHOULD be returned.
The server MUST respond with a Control-Ack message. Again, any non- The server MUST respond with a Control-Ack message. Again, any non-
zero value in the Accept field means rejection of command. Zero zero value in the Accept field means rejection of command. Zero
means that data will follow. means that data will follow.
If Yes/No was 0, the server then MUST send the OWDP-Test session data If Yes/No was 0, the server then MUST send the OWDP-Test session data
in question, followed by 16 octets of zero padding. in question, followed by 16 octets of zero padding.
The transmission starts with 4 octets that contain the number of The transmission starts with 4 octets that contain the number of
records that will follow, each record representing one received records that will follow, each record representing one received
packet. This is followed by 2 octets of Sender Precision, 2 octets packet. This is followed by 4 octets of Type-P Descriptor and 8
of Receiver precision, and 8 octets of zero padding. octets of zero padding.
Each packet is represented with 20 octets, and includes 4 octets of Each packet is represented with 20 octets, and includes 4 octets of
sequence number, 8 octets of send timestamp, and 8 octets of receive sequence number, 8 octets of send timestamp, and 8 octets of receive
timestamp. timestamp.
The last (possibly full, possibly incomplete) block (16 octets) of The last (possibly full, possibly incomplete) block (16 octets) of
data is padded with zeros. A zero padding consisting of 16 octets is data is padded with zeros if necessary. A zero padding consisting of
then appended. 16 octets is then appended.
5. OWDP-Test 5. OWDP-Test
This section describes OWDP-Test protocol. It runs over UDP using This section describes OWDP-Test protocol. It runs over UDP using
sender and receiver IP and port numbers negotiated during Session- sender and receiver IP and port numbers negotiated during Session-
Prepare exchange. Prepare exchange.
As OWDP-Control, OWDP-Test has three modes: unauthenticated, As OWDP-Control, OWDP-Test has three modes: unauthenticated,
authenticated, and encrypted. All OWDP-Test sessions spawned by an authenticated, and encrypted. All OWDP-Test sessions spawned by an
OWDP-Control session inherit its mode. OWDP-Control session inherit its mode.
skipping to change at page 15, line 11 skipping to change at page 17, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated mode: For authenticated 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding | | Zero Padding (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet padding (0-65503 octets) . . Packet padding (0-65503 octets) .
. . . .
| | | |
skipping to change at page 15, line 43 skipping to change at page 17, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero Padding | | Zero Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet padding (0-65511 octets) . . Packet padding (0-65511 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of timestamp is the same as that of NTP v3 protocol The format of the timestamp is influenced by RFC 1305 and is as
[RFC958]. Quoting from RFC 958: follows: first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; next 24 bits represent
the fractional part of a second that has elapsed since then (so,
first 56 bits of the timestamp would be the same as the corresponding
bits of NTP v3 timestamp). The remaining octet specifies
synchronization and precision. The first bit is set if the party
generating the timestamp has a clock that is synchronized to an
external source (e.g., the bit should be set if GPS hardware is used
and it indicates that it has acquired current position and time or if
NTP is used and it indicates that it has synchronized to an external
source, which includes stratum 0 source, etc.); if there is no notion
of external synchronization for the time source (e.g., a cesium
oscillator is used directly), the bit SHOULD be set. The next bit is
currently unused and may be set to an arbitrary value. The remaining
six bits form an unsigned integer, which is the number of bits in the
time-specifying main part of the timestamp that the party generating
timestamp believes to be correct (this should be set conservatively).
When generating a timestamp, one MUST ensure that this number falls
into the range from 0 to 56; when interpreting a timestamp, one MUST
treat numbers in the range 57 to 63 identically to the number 56.
NTP timestamps are represented as a 64-bit fixed-point number, in More rigorous semantics of precision indicators are out of scope of
seconds relative to 0000 UT on 1 January 1900. The integer part OWDP, but may be negotiated out-of-band.
is in the first 32 bits and the fraction part in the last 32 bits,
as shown in the following diagram.
So, timestamp is represented 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Part | | Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction Part | | Fractional part of seconds |S|U| Prec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where S is the synchronization bit, U is currently unused, and Prec
is the unsigned integer in the range from 0 to 56 discussed above.
This format allows convenient multiple-precision arithmetic and Sequence numbers start with 0 and are incremented by 1 for each
conversion to Time Protocol representation (seconds), but does subsequent packet.
complicate the conversion to ICMP Timestamp message representation
(milliseconds). The low-order fraction bit increments at about
0.2-nanosecond intervals, so a free-running one-millisecond clock
will be in error only a small fraction of one part per million, or
less than a second per year.
Sequence numbers start with 0.
The minimum data segment length is therefore 12 octets in The minimum data segment length is therefore 12 octets in
unauthenticated mode, 24 octets in authenticated mode, and 16 octets unauthenticated mode, 24 octets in authenticated mode, and 16 octets
in encrypted mode. in encrypted mode.
In authenticated and encrypted mode, the first block (16 octets) of In authenticated and encrypted mode, the first block (16 octets) of
each packet is encrypted using AES ECB mode. each packet is encrypted using AES ECB mode.
In unauthenticated mode, no encryption is applied. In unauthenticated mode, no encryption is applied.
skipping to change at page 18, line 44 skipping to change at page 21, line 10
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.
7. References 7. References
[AES] Advanced Encryption Standard (AES), [AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/ http://csrc.nist.gov/encryption/aes/
[RFC958]D. Mills, "Network Time Protocol (NTP)", RFC 958, September [RFC1305]D. Mills, "Network Time Protocol (Version 3) Specification,
1985. Implementation and Analysis", RFC 1305, March 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 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework
for IP Performance Metrics" RFC 2330, May 1998. for IP Performance Metrics" RFC 2330, May 1998.
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition
of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[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.
[RIPE] Ripe Test-Traffic Home page, http://www.ripe.net/test- [RIPE] RIPE NCC Test-Traffic Measurements home,
traffic/. http://www.ripe.net/test-traffic/.
[RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay [RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay
Measurements Using Test-Traffic", Spring 1998 Dutch Unix User Measurements Using Test-Traffic", Spring 1998 Dutch Unix User
Group Meeting, http://www.ripe.net/ripencc/mem- Group Meeting, http://www.ripe.net/test-
services/ttm/Talks/9805_nluug.ps.gz. (NOTE: it's actually traffic/Talks/9805_nluug.ps.gz.
postscript, not gzip'd postscript.)
[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
8. Authors' Addresses 8. Authors' Addresses
skipping to change at page 20, line 22 skipping to change at page 22, line 34
Matthew J. Zekauskas Matthew J. Zekauskas
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1112 Phone: +1 914 765 1112
EMail: matt@advanced.org EMail: matt@advanced.org
Expiration date: June 2001 Expiration date: August 2001
 End of changes. 

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