draft-ietf-ippm-owdp-09.txt   draft-ietf-ippm-owdp-10.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: January 2005 Anatoly Karp Expiration Date: February 2005 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
July 2004 August 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-09.txt> <draft-ietf-ippm-owdp-10.txt>
1. Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. 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
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft shadow directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This memo provides information for the Internet community. This memo Copyright Notice
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Abstract Copyright (C) The Internet Society 2004. All Rights Reserved.
Abstract
With growing availability of good time sources to network nodes, it With growing availability of good time sources to network nodes, it
becomes increasingly possible to measure one-way IP performance becomes increasingly possible to measure one-way IP performance
metrics with high precision. To do so in an interoperable manner, a metrics with high precision. To do so in an interoperable manner, a
common protocol for such measurements is required. The One-Way common protocol for such measurements is required. The One-Way
Active Measurement Protocol (OWAMP) can measure one-way delay, as Active Measurement Protocol (OWAMP) can measure one-way delay, as
well as other unidirectional characteristics, such as one-way loss. well as other unidirectional characteristics, such as one-way loss.
3. Motivation and Goals Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship of Test and Control Protocols . . . . . . 4
1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7
3.2. OWAMP-Control Commands . . . . . . . . . . . . . . . . 10
3.3. Creating Test Sessions . . . . . . . . . . . . . . . . 11
3.4. Send Schedules . . . . . . . . . . . . . . . . . . . . 16
3.5. Starting Test Sessions . . . . . . . . . . . . . . . . 17
3.6. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19
3.7. Fetch-Session . . . . . . . . . . . . . . . . . . . . 21
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 24
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 24
4.1.2. Packet Format and Content . . . . . . . . . . . . 25
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 28
5. Computing Exponentially Distributed Pseudo-Random Numbers . 30
5.1. High-Level Description of the Algorithm . . . . . . . 30
5.2. Data Types, Representation and Arithmetic . . . . . . 31
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . . . 33
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 33
6.2. Preventing Third-Party Denial of Service . . . . . . . 34
6.3. Covert Information Channels . . . . . . . . . . . . . 34
6.4. Requirement to Include AES in Implementations . . . . 34
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 34
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 35
6.7. Required Properties of MD5 . . . . . . . . . . . . . . 36
6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
8. Internationalization Considerations . . . . . . . . . . . . 39
9. Appendix A: Sample C Code for Exponential Deviates . . . . 39
10. Appendix B: Test Vectors for Exponential Deviates . . . . 44
11. Normative References . . . . . . . . . . . . . . . . . . . 45
12. Informative References . . . . . . . . . . . . . . . . . . 45
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 46
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
[RFC 2680] across Internet paths. Although there are now several [RFC 2680] 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], there is not currently a standard that would
permit initiation of test streams or exchange of packets to collect permit initiation of test streams or exchange of packets to collect
singleton metrics in an interoperable manner. singleton metrics in an interoperable manner.
With the increasingly wide availability of affordable global With the increasingly wide availability of affordable global
skipping to change at page 2, line 45 skipping to change at page 3, line 45
the traffic, at the same time making it impossible to alter the traffic, at the same time making it impossible to alter
timestamps undetectably. 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 OWAMP test streams or who who attempt to provide special treatment to OWAMP test streams or who
attempt to modify sender-generated timestamps to falsify test attempt to modify sender-generated timestamps to falsify test
results. results.
3.1. Relationship of Test and Control Protocols The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119].
1.1. Relationship of Test and Control Protocols
OWAMP actually consists of two inter-related protocols: OWAMP-Control OWAMP actually consists of two inter-related protocols: OWAMP-Control
and OWAMP-Test. OWAMP-Control is used to initiate, start and stop and OWAMP-Test. OWAMP-Control is used to initiate, start and stop
test sessions and fetch their results, while OWAMP-Test is used to test sessions and fetch their results, while OWAMP-Test is used to
exchange test packets between two measurement nodes. exchange test packets between two measurement nodes.
Although OWAMP-Test may be used in conjunction with a control Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, the authors have deliberately protocol other than OWAMP-Control, the authors have deliberately
chosen to include both protocols in the same draft to encourage the chosen to include both protocols in the same draft to encourage the
implementation and deployment of OWAMP-Control as a common implementation and deployment of OWAMP-Control as a common
denominator control protocol for one-way active measurements. Having denominator control protocol for one-way active measurements. Having
a complete and open one-way active measurement solution that is a complete and open one-way active measurement solution that is
simple to implement and deploy is crucial to assuring a future in simple to implement and deploy is crucial to assuring a future in
which inter-domain one-way active measurement could become as which inter-domain one-way active measurement could become as
commonplace as ping. We neither anticipate nor recommend that OWAMP- commonplace as ping. We neither anticipate nor recommend that
Control form the foundation of a general purpose extensible OWAMP-Control form the foundation of a general-purpose extensible
measurement and monitoring control protocol. measurement and monitoring control protocol.
OWAMP-Control is designed to support the negotiation of one-way OWAMP-Control is designed to support the negotiation of one-way
active measurement sessions and results retrieval in a active measurement sessions and results retrieval in a
straightforward manner. At session initiation, there is a negotiation straightforward manner. At session initiation, there is a negotiation
of sender and receiver addresses and port numbers, session start of sender and receiver addresses and port numbers, session start
time, session length, test packet size, the mean Poisson sampling time, session length, test packet size, the mean Poisson sampling
interval for the test stream, and some attributes of the very general interval for the test stream, and some attributes of the very general
RFC 2330 notion of `packet type', including packet size and per-hop RFC 2330 notion of `packet type', including packet size and per-hop
behavior (PHB) [RFC2474], which could be used to support the behavior (PHB) [RFC2474], which could be used to support the
skipping to change at page 3, line 39 skipping to change at page 4, line 46
of a seed value for the pseudo-random Poisson process that describes of a seed value for the pseudo-random Poisson process that describes
the test stream generated by the sender. the test stream generated by the sender.
We believe that OWAMP-Control can effectively support one-way active We believe that OWAMP-Control can effectively support one-way active
measurement in a variety of environments, from publicly accessible measurement in a variety of environments, from publicly accessible
measurement `beacons' running on arbitrary hosts to network measurement `beacons' running on arbitrary hosts to network
monitoring deployments within private corporate networks. If monitoring deployments within private corporate networks. If
integration with SNMP or proprietary network management protocols is integration with SNMP or proprietary network management protocols is
required, gateways may be created. required, gateways may be created.
3.2. Logical Model 1.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 OWAMP-Test session; Session-Sender the sending endpoint of an OWAMP-Test session;
Session-Receiver the receiving endpoint of an OWAMP-Test session; Session-Receiver the receiving endpoint of an OWAMP-Test session;
Server an end system that manages one or more OWAMP-Test Server an end system that manages one or more OWAMP-Test
sessions, is capable of configuring per-session sessions, is capable of configuring per-session
state in session endpoints, and is capable of state in session endpoints, and is capable of
returning the results of a test session; returning the results of a test session;
Control-Client an end system that initiates requests for Control-Client an end system that initiates requests for
OWAMP-Test sessions, triggers the start of a set OWAMP-Test sessions, triggers the start of a set
of sessions, and may trigger their termination; of sessions, and may trigger their termination;
Fetch-Client an end system that initiates requests to fetch Fetch-Client an end system that initiates requests to fetch
the results of completed OWAMP-Test sessions; the results of completed OWAMP-Test sessions;
One possible scenario of relationships between these roles is shown One possible scenario of relationships between these roles is shown
below. below.
skipping to change at page 4, line 38 skipping to change at page 5, line 45
v v v v v v
+----------------+ +-----------------+ +----------------+ +-----------------+
| Control-Client | | Fetch-Client | | Control-Client | | Fetch-Client |
+----------------+ +-----------------+ +----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this draft and may (Unlabeled links in the figure are unspecified by this draft and may
be proprietary protocols.) be proprietary protocols.)
Different logical roles can be played by the same host. For example, Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Fetch-Client, and Session- playing the roles of Control-Client, Fetch-Client, and
Sender, and the other playing the roles of Server and Session- Session-Sender, and the other playing the roles of Server and
Receiver. This is shown below. Session-Receiver. This is shown below.
+-----------------+ +------------------+ +-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server | | Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | | | Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver | | Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+ +-----------------+ +------------------+
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, OWAMP has been ATM segmentation and reassembly (SAR). Consequently, OWAMP 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).
4. Protocol Overview 2. Protocol Overview
As described above, OWAMP consists of two inter-related protocols: As described above, OWAMP consists of two inter-related protocols:
OWAMP-Control and OWAMP-Test. The former is layered over TCP and is OWAMP-Control and OWAMP-Test. The former is layered over TCP and is
used to initiate and control measurement sessions and to fetch their used to initiate and control measurement sessions and to fetch their
results. The latter protocol is layered over UDP and is used to send results. The latter protocol is layered over UDP and is used to send
singleton 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 OWAMP-Test sessions. IANA will be open for the duration of the OWAMP-Test sessions. IANA will be
requested to allocate a well-known port number for OWAMP-Control requested to allocate a well-known port number for OWAMP-Control
sessions. An OWAMP server SHOULD listen to this well-known port. sessions. An OWAMP server SHOULD listen to this well-known port.
OWAMP-Control messages are transmitted only before OWAMP-Test OWAMP-Control messages are transmitted only before OWAMP-Test
sessions are actually started and after they complete (with the sessions are actually started and after they complete (with the
possible exception of an early Stop-Session message). possible exception of an early Stop-Sessions message).
The OWAMP-Control and OWAMP-Test protocols support three modes of The OWAMP-Control and OWAMP-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 All multi-octet quantities defined in this document are represented
as unsigned integers in network byte order unless specified as unsigned integers in network byte order unless specified
otherwise. otherwise.
5. OWAMP-Control 3. OWAMP-Control
Each type of OWAMP-Control message has a fixed length. The recipient Each type of OWAMP-Control message has a fixed length. The recipient
will know the full length of a message after examining first 16 will know the full length of a message after examining first 16
octets of it. No message is shorter than 16 octets. octets of it. No message is shorter than 16 octets.
If the full message is not received within 30 minutes after it is If the full message is not received within 30 minutes after it is
expected, connection SHOULD be dropped. expected, connection SHOULD be dropped.
5.1. Connection Setup 3.1. Connection Setup
Before either a Control-Client or a Fetch-Client can issue commands Before either a Control-Client or a Fetch-Client can issue commands
of a Server, it must establish a connection to the server. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 33 skipping to change at page 10, line 38
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 is treated the same way as Integrity Zero Integrity Zero Padding is treated the same way as Integrity Zero
Padding in the next section and beyond. Padding in the next section and beyond.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
5.2. OWAMP-Control Commands 3.2. 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-Session, Fetch-Session. The command Stop- Start-Sessions, Stop-Sessions, Fetch-Session. The command
Session is available to both the client and the server. (The server Stop-Sessions is available to both the client and the server. (The
can also send other messages in response to commands it receives.) server can also send other messages in response to commands it
receives.)
After Start-Sessions is sent/received by the client/server, and After Start-Sessions is sent/received by the client/server, and
before it both sends and receives Stop-Session (order unspecified), before it both sends and receives Stop-Sessions (order unspecified),
it is said to be conducting active measurements. it is said to be conducting active measurements.
While conducting active measurements, the only command available is While conducting active measurements, the only command available is
Stop-Session. Stop-Sessions.
These commands are described in detail below. These commands are described in detail below.
5.3. Creating Test Sessions 3.3. 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 14, line 15 skipping to change at page 15, line 15
If Conf-Sender is set and the server doesn't recognize Type-P If Conf-Sender is set and the server doesn't recognize Type-P
Descriptor, cannot or does not wish to set the corresponding Descriptor, 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 the request. If Conf-Sender is not set, the server SHOULD accept the
session regardless of the value of Type-P Descriptor. session regardless of the value of Type-P Descriptor.
Integrity Zero Padding MUST be all zeros in this and all subsequent Integrity Zero Padding MUST be all zeros in this and all subsequent
messages that use zero padding. The recipient of a message where messages that use zero padding. The recipient of a message where
zero padding is not zero MUST reject the message as it is an zero padding is not zero MUST reject the message as it is an
indication of tampering with the content of the message by an indication of tampering with the content of the message by an
intermediary (or brokenness). If the message is part of OWAMP- intermediary (or brokenness). If the message is part of
Control, the session MUST be terminated and results invalidated. If OWAMP-Control, the session MUST be terminated and results
the message is part of OWAMP-Test, it MUST be silently ignored. This invalidated. If the message is part of OWAMP-Test, it MUST be
will ensure data integrity. In unauthenticated mode, Integrity Zero silently ignored. This will ensure data integrity. In
Padding is nothing more than a simple check. In authenticated and unauthenticated mode, Integrity Zero Padding is nothing more than a
encrypted modes, however, it ensures, in conjunction with properties simple check. In authenticated and encrypted modes, however, it
of CBC chaining mode, that everything received before was not ensures, in conjunction with properties of CBC chaining mode, that
tampered with. For this reason, it is important to check the everything received before was not tampered with. For this reason,
Integrity Zero Padding Field as soon as possible, so that bad data it is important to check the Integrity Zero Padding Field as soon as
doesn't get propagated. 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 | Unused | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
skipping to change at page 14, line 52 skipping to change at page 15, line 52
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this message, zero in the Accept field means that the server is In this message, zero in the Accept field means that the server is
willing to conduct the session. A value of 1 indicates rejection of willing to conduct the session. A value of 1 indicates rejection of
the request. All other values are reserved. the request. All other values are reserved.
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.
The meaning of Port in the response depends on the values of Conf- The meaning of Port in the response depends on the values of
Sender and Conf-Receiver in the query that solicited the response. Conf-Sender and Conf-Receiver in the query that solicited the
If both were set, Port field is unused. If only Conf-Sender was set, response. If both were set, Port field is unused. If only
Port is the port to expect OWAMP-Test packets from. If only Conf- Conf-Sender was set, Port is the port to expect OWAMP-Test packets
Receiver was set, Port is the port to send OWAMP-Test packets to. from. If only Conf-Receiver was set, Port is the port to send
OWAMP-Test packets to.
If only Conf-Sender was set, SID field in the response is unused. If only Conf-Sender was set, SID field in the response is unused.
Otherwise, SID is a unique server-generated session identifier. It Otherwise, SID is a unique server-generated session identifier. It
can be used later as handle to fetch the results of a session. can be used later as handle to fetch the results of a session.
SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number
belonging to the generating machine, 8-octet timestamp, and 4-octet belonging to the generating machine, 8-octet timestamp, and 4-octet
random value. To reduce the probability of collisions, if the random value. To reduce the probability of collisions, if the
generating machine has any IPv4 addresses (with the exception of 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 4 octets of an IPv6 address can be used instead. Note that SID last 4 octets of an IPv6 address MAY be used instead. Note that SID
is always chosen by the receiver. If truly random values are not is always chosen by the receiver. If truly random values are not
available, it is important that SID be made unpredictable as available, it is important that SID be made unpredictable as
knowledge of SID might be used for access control. knowledge of SID might be used for access control.
5.4. Send Schedules 3.4. Send Schedules
The sender and the receiver need to both know the same send schedule. The sender and the receiver need to both 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'.
Each slots has a type and a parameter. Two types are supported: Each slot has a type and a parameter. Two types are supported:
exponentially distributed pseudo-random quantity (denoted by a code exponentially distributed pseudo-random quantity (denoted by a code
of 0) and a fixed quantity (denoted by a code of 1). The parameter of 0) and a fixed quantity (denoted by a code of 1). The parameter
is expressed as a timestamp and specifies a time interval. For a is expressed as a timestamp and specifies a time interval. For a
type 0 slot (exponentially distributed pseudo-random quantity) this type 0 slot (exponentially distributed pseudo-random quantity) this
interval is the mean value (or 1/lambda if the distribution density interval is the mean value (or 1/lambda if the distribution density
function is expressed as lambda*exp(-lambda*x) for positive values of function is expressed as lambda*exp(-lambda*x) for positive values of
x). For a type 1 slot, the parameter is the delay itself. The x). For a type 1 slot, the parameter is the delay itself. The
sender starts with the beginning of the schedule, and `executes' the sender starts with the beginning of the schedule, and `executes' the
instructions in the slots: for a slot of type 0, wait exponentially instructions in the slots: for a slot of type 0, wait exponentially
distributed time with mean of the specified parameter and then send a distributed time with mean of the specified parameter and then send a
skipping to change at page 16, line 13 skipping to change at page 17, line 13
the sender returns to the first slot. the sender returns to the first slot.
The sender and the receiver must be able to reproducibly execute the The sender and the receiver must be able to reproducibly execute the
entire schedule (so if a packet is lost, the receiver can still entire schedule (so if a packet is lost, the receiver can still
attach a send timestamp to it). Slots of type 1 are trivial to attach a send timestamp to it). Slots of type 1 are trivial to
reproducibly execute. To reproducibly execute slots of type 0, we reproducibly execute. To reproducibly execute slots of type 0, we
need to be able to generate pseudo-random exponentially distributed need to be able to generate pseudo-random exponentially distributed
quantities in a reproducible manner. The way this is accomplished is quantities in a reproducible manner. The way this is accomplished is
discussed later. discussed later.
Using this mechanism one can easily specify common testing scenarios: Using this mechanism one can easily specify common testing scenarios.
Some examples include:
+ Poisson stream: a single slot of type 0; + Poisson stream: a single slot of type 0;
+ 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.
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.
5.5. Starting Test Sessions 3.5. 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
skipping to change at page 17, line 42 skipping to change at page 18, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (16 octets) | | Integrity Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is 1, the Start-Sessions request was rejected; zero means If Accept is 1, the Start-Sessions request was rejected; zero means
that the command was accepted. All other values are reserved. The that the command was accepted. All other values are reserved. The
server MAY and the client SHOULD close the connection in the case of server MAY and the client SHOULD close the connection in the case of
a negative response. a rejection.
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. (Note that a client can effect an immediate whichever is later. If the client represents a Sender, the client
start by specifying in Request-Session a Start Time in the past.) If SHOULD start its OWAMP-Test streams immediately after it sees the
the client represents a Sender, the client SHOULD start its OWAMP- Control-Ack response from the Server (if the Start-Sessions command
Test streams immediately after it sees the Control-Ack response from was accepted) or immediately after their specified start times,
the Server. whichever is later. See more on OWAMP-Test sender behavior in a
separate section below.
5.6. Stop-Sessions 3.6. 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 | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions | | Number of Sessions |
skipping to change at page 18, line 45 skipping to change at page 19, line 45
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Packets Sent | | Session Packets Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (12 octets) | | Integrity Zero Padding (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages comprise one logical message: the Stop-Session All these messages comprise one logical message: the Stop-Sessions
command. command.
Above, the first octet (3) indicates that this is the Stop-Session Above, the first octet (3) indicates that this is the Stop-Sessions
command. command.
Accept values of 1 indicate a failure of some sort. Zero values Accept values of 1 indicate a failure of some sort. Zero values
indicate normal (but possibly premature) completion. All other indicate normal (but possibly premature) completion. All other
values are reserved. values are reserved.
If Accept had a non-zero value (from either party) results of all If Accept had a non-zero value (from either party) results of all
OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be
considered invalid, even if a Fetch-Session with SID from this considered invalid, even if a Fetch-Session with SID from this
session works for a different OWAMP-Control session. If Accept was session works for a different OWAMP-Control session. If Accept was
not transmitted at all (for whatever reason, including the TCP not transmitted at all (for whatever reason, including the TCP
connection used for OWAMP-Control breaking), the results of all connection used for OWAMP-Control breaking), the results of all
OWAMP-Test sessions spawned by this OWAMP-control session MAY be OWAMP-Test sessions spawned by this OWAMP-control session MAY be
considered invalid. considered invalid.
Number of Sessions indicates the number of session packets sent Number of Sessions indicates the number of session packets sent
records that immediately follow the Stop-Sessions message. records that immediately follow the Stop-Sessions message.
Number of Sessions MUST contain the number of send sessions started Number of Sessions MUST contain the number of send sessions started
by the local side of the control connection that have not been by the local side of the control connection that have not been
previously terminated by a Stop-Sessions command. (i.e. The Control- previously terminated by a Stop-Sessions command (i.e., the
Client MUST account for each accepted Request-Session where Conf- Control-Client MUST account for each accepted Request-Session where
Receiver was set. The Control-Server MUST account for each accepted Conf-Receiver was set. The Control-Server MUST account for each
Request-Session where Conf-Sender was set.) If the Stop-Sessions accepted Request-Session where Conf-Sender was set). If the
message does not account for all the send sessions controlled by that Stop-Sessions message does not account for all the send sessions
side, then it is to be considered invalid and the connection SHOULD controlled by that side, then it is to be considered invalid and the
be closed and any results obtained considered invalid. connection SHOULD be closed and any results obtained considered
invalid.
Each session packets sent record represents one OWAMP-Test session Each session packets sent record represents one OWAMP-Test session
and contains the session identifier (SID) and the number of packets and contains the session identifier (SID) and the number of packets
sent in that session. For completed sessions, Session Packets Sent sent in that session. For completed sessions, Session Packets Sent
will equal NumPackets from the Request-Session. Session Packets Sent will equal NumPackets from the Request-Session. Session Packets Sent
MAY be all ones (0xFFFFFFFF); in this case, the sender of the Stop- MAY be all ones (0xFFFFFFFF); in this case, the sender of the
Sessions command could not determine the number of packets sent Stop-Sessions command could not determine the number of packets sent
(perhaps, due to some internal error such as a process crash); this (perhaps, due to some internal error such as a process crash); this
special value SHOULD NOT be sent under normal operating conditions. special value SHOULD NOT be sent under normal operating conditions.
If the OWAMP-Control connection associated with an OWAMP-Test If the OWAMP-Control connection associated with an OWAMP-Test
receiver receives the (0xFFFFFFFF) special value for the Session receiver receives the (0xFFFFFFFF) special value for the Session
Packets Sent, or if the OWAMP-Control connection breaks when the Packets Sent, or if the OWAMP-Control connection breaks when the
Stop-Sessions command is sent, the receiver MAY not completely Stop-Sessions command is sent, the receiver MAY not completely
invalidate the session results. It MUST discard any records of lost invalidate the session results. It MUST discard any records of lost
packets that follow (in other words, have greater sequence number packets that follow (in other words, have greater sequence number
than) the last packet that was actually received. This will help than) the last packet that was actually received. This will help
skipping to change at page 20, line 17 skipping to change at page 21, line 19
A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control
Stop-Sessions command, MUST discard any packet records -- including Stop-Sessions command, MUST discard any packet records -- including
lost packet records -- with a (computed) send time that falls between lost packet records -- with a (computed) send time that falls between
the current time minus Timeout and the current time. This ensures the current time minus Timeout and the current time. This ensures
statistical consistency for the measurement of loss and duplicates in statistical consistency for the measurement of loss and duplicates in
the event that the Timeout is greater than the time it takes for the the event that the Timeout is greater than the time it takes for the
Stop-Sessions command to take place. Stop-Sessions command to take place.
To effect complete sessions, each side of the control connection To effect complete sessions, each side of the control connection
SHOULD wait until all Sessions are complete before sending the Stop- SHOULD wait until all Sessions are complete before sending the
Sessions message. The completed time of each sessions is determined Stop-Sessions message. The completed time of each sessions is
as Timeout after the scheduled time for the last sequence number. determined as Timeout after the scheduled time for the last sequence
Endpoints MAY add a small increment to the computed completed time number. Endpoints MAY add a small increment to the computed
for send endpoints to ensure the Stop-Sessions message reaches the completed time for send endpoints to ensure the Stop-Sessions message
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.
5.7. Fetch-Session 3.7. 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) | | Unused (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 29 skipping to change at page 23, line 29
timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6): timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number | 00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Timestamp | 04| Send Timestamp |
08| | 08| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12| Send Error Estimate | | 12| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp | 16| Receive Timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| |
20| | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL | 24| TTL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Packet records are sent out in the same order they are made when the 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 results of the session are recorded. Therefore, the data is in
arrival order. 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
Test session) MUST appear in the sequence of packets. They can OWAMP-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 as follows: point. Lost packet records are distinguished as follows:
+ A send timestamp filled with the presumed send time (as computed + A send timestamp filled with the presumed send time (as computed
by the send schedule). by the send schedule).
+ A send error estimate filled with Multiplier=1, Scale=64, and S=0 + A send error estimate filled with Multiplier=1, Scale=64, and S=0
(see the OWAMP-Test description for definition of these quantities (see the OWAMP-Test description for definition of these quantities
and explanation of timestamp format and error estimate format). and explanation of timestamp format and error estimate format).
+ A receive timestamp consisting of all zero bits.
+ A normal receive error estimate as determined by the error of the + A normal receive error estimate as determined by the error of the
clock being used to declare the packet lost (it MUST be declared clock being used to declare the packet lost (it MUST be declared
lost if it is not received Timeout after the presumed send time as lost if it is not received Timeout after the presumed send time as
determined by the receivers clock). determined by the receivers clock).
+ A receive timestamp consisting of all zero bits.
+ A TTL value of 255. + A TTL value of 255.
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 if necessary. (These zeros are simple data is padded with zeros if necessary. (These zeros are simple
padding and should be distinguished from the 16 octets of Integrity padding and should be distinguished from the 16 octets of Integrity
Zero Padding that follow the session data and conclude the response Zero Padding that follow the session data and conclude the response
to Fetch-Session.) to Fetch-Session.)
6. OWAMP-Test 4. OWAMP-Test
This section describes OWAMP-Test protocol. It runs over UDP using This section describes OWAMP-Test protocol. It runs over UDP using
sender and receiver IP and port numbers negotiated during Request- sender and receiver IP and port numbers negotiated during
Session exchange. Request-Session exchange.
As OWAMP-Control, OWAMP-Test has three modes: unauthenticated, As OWAMP-Control, OWAMP-Test has three modes: unauthenticated,
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 4.1. Sender Behavior
4.1.1. Packet Timings
Send schedules based on slots, described previously, in conjunction
with scheduled session start time enable the sender and the receiver
to compute the same exact packet sending schedule independently of
each other. These sending schedules are independent for different
OWAMP-Test sessions, even if they are governed by the same
OWAMP-Control session.
Consider any OWAMP-Test session. Once Start-Sessions exchange is
complete, the sender is ready to start sending packets. Under normal
OWAMP use circumstances, the time to send the first packet is in the
near future (perhaps a fraction of a second away). The sender SHOULD
send packets as close as possible to their scheduled time, with the
following exception: if the scheduled time to send is in the past,
and separated from the present by more than Timeout time, the sender
MUST NOT send the packet. (Indeed, such a packet would be considered
lost by the receiver anyway.) This could happen if a time in the
past was specified in the Request-Session command, or if the
Start-Sessions exchange took unexpectedly long, or if the sender
could not start serving the OWAMP-Test session on time due to
internal scheduling problems of the OS. Packets in the past, but
separated from the present by less than Timeout value, SHOULD be sent
as quickly as possible. With normal test rates and timeout values,
the number of packets in such a burst is limited. Nevertheless,
hosts SHOULD NOT intentionally schedule sessions so that such bursts
of packets occur.
Regardless of any scheduling delays, each packet that is actually
sent MUST have the best possible approximation of its real time of
departure as its timestamp (in the packet).
4.1.2. Packet Format and Content
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 sender SHOULD set the specified in the Request-Session command. The sender SHOULD set the
TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The
format of the body of a UDP packet in the stream depends on the mode format of the body of a UDP packet in the stream depends on the mode
being used. being used.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
skipping to change at page 24, line 47 skipping to change at page 26, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Integrity Zero Padding (6 octets) | | Integrity Zero Padding (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in RFC 1305 and is as The format of the timestamp is the same as in [RFC 1305] and is as
follows: first 32 bits represent the unsigned integer number of follows: first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; next 32 bits represent seconds elapsed since 0h on 1 January 1900; next 32 bits represent
the fractional part of a second that has elapsed since then. the fractional part of a second that has elapsed since then.
So, Timestamp is represented as follows: 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 of seconds | | Integer part of seconds |
skipping to change at page 26, line 35 skipping to change at page 28, line 35
Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
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. It is
discussed later in a separate section.
7. Receiver Behavior 4.2. Receiver Behavior
Receiver knows when the sender will send packets. The following Receiver knows when the sender will send packets. The following
parameter is defined: Timeout (from Request-Session). Packets that parameter is defined: Timeout (from Request-Session). Packets that
are delayed by more than Timeout are considered lost (or `as good as 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 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 network: a `lost' packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value of 255). within TTL seconds or never (with TTL having a maximum value of 255).
To the best of the authors' knowledge, this requirement was never To the best of the authors' knowledge, this requirement was never
actually implemented (and of course only a complete and universal actually implemented (and of course only a complete and universal
skipping to change at page 28, line 19 skipping to change at page 30, line 19
If any of the following is true, the packet MUST be discarded: 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 is more than Timeout in the past or in the future.
+ Send timestamp differs by more than Timeout from the time when the + Send timestamp differs by more than Timeout from the time when the
packet should have been sent according to its seqno. packet should have been sent according to its seqno.
+ In authenticated or encrypted mode, any of the bits of zero + In authenticated or encrypted mode, any of the bits of zero
padding inside the first 16 octets of packet body is non-zero. padding inside the first 16 octets of packet body is non-zero.
8. Computing Exponentially Distributed Pseudo-Random Numbers 5. 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.
8.1. High-Level Description of the Algorithm 5.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'.
First, the constants First, the constants
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
are computed in advance. The exact values which MUST be used by all are computed in advance. The exact values which MUST be used by all
implementations are given in the reference code (see Appendix). This implementations are given in the reference code (see Appendix A).
is necessary to insure that exactly the same pseudo-random sequences This is necessary to insure that exactly the same pseudo-random
are produced by all implementations. sequences are produced by all implementations.
S1. [Get U and shift.] Generate a 32-bit uniform random binary S1. [Get U and shift.] Generate a 32-bit uniform random binary
fraction fraction
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
skipping to change at page 29, line 28 skipping to change at page 31, line 28
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.
8.2. Data Types, Representation and Arithmetic 5.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 30, line 33 skipping to change at page 32, line 33
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).
8.3. Uniform Random Quantities 5.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 31, line 22 skipping to change at page 33, line 22
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.
9. Security Considerations 6. Security Considerations
6.1. Introduction
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.
The goal of encrypted mode is quite different: To make it hard for a The goal of encrypted mode is quite different: To make it hard for a
party in the middle of the network to make results look `better' than party in the middle of the network to make results look `better' than
they should be. This is especially true if one of client and server they should be. This is especially true if one of client and server
doesn't coincide with neither sender nor receiver. doesn't coincide with neither sender nor receiver.
Encryption of OWAMP-Control using AES CBC mode with blocks of zeros Encryption of OWAMP-Control using AES CBC mode with blocks of zeros
after each message aims to achieve two goals: (i) to provide secrecy after each message aims to achieve two goals: (i) to provide secrecy
of exchange; (ii) to provide authentication of each message. of exchange; (ii) to provide authentication of each message.
6.2. Preventing Third-Party Denial of Service
OWAMP-Test sessions directed at an unsuspecting party could be used OWAMP-Test sessions directed at an unsuspecting party could be used
for denial of service (DoS) attacks. In unauthenticated mode servers for denial of service (DoS) attacks. In unauthenticated mode servers
should limits receivers to hosts they control or to the OWAMP-Control should limits receivers to hosts they control or to the OWAMP-Control
client. client.
6.3. Covert Information Channels
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.
6.4. Requirement to Include AES in Implementations
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.1. An OWAMP server can consume resources of various kinds. The two 6.5. Resource Use Limitations
most important kinds of resources are network capacity and memory
(primary or secondary) for storing test results. An OWAMP server can consume resources of various kinds. The two most
important kinds of resources are network capacity and memory (primary
or secondary) for storing test results.
Any implementation of OWAMP server MUST include technical mechanisms Any implementation of OWAMP server MUST include technical mechanisms
to limit the use of network capacity and memory. Mechanisms for to limit the use of network capacity and memory. Mechanisms for
managing the resources consumed by unauthenticated users and users managing the resources consumed by unauthenticated users and users
authenticated with a username and passphrase SHOULD be separate. The authenticated with a username and passphrase SHOULD be separate. The
default configuration of an implementation MUST enable these default configuration of an implementation MUST enable these
mechanisms and set the resource use limits to conservatively low mechanisms and set the resource use limits to conservatively low
values. values.
One way to design the resource limitation mechanisms is as follows: One way to design the resource limitation mechanisms is as follows:
skipping to change at page 33, line 5 skipping to change at page 35, line 24
data is deleted. For unauthenticated sessions, memory consumed by an data is deleted. For unauthenticated sessions, memory consumed by an
OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control
connection that initiated the session is closed (gracefully or connection that initiated the session is closed (gracefully or
otherwise). For authenticated sessions, the administrator who otherwise). For authenticated sessions, the administrator who
configures the service should be able to decide the exact policy, but configures the service should be able to decide the exact policy, but
useful policy mechanisms that MAY be implemented are the ability to useful policy mechanisms that MAY be implemented are the ability to
automatically reclaim memory when the data is retrieved and the automatically reclaim memory when the data is retrieved and the
ability to reclaim memory after a certain configurable (based on user ability to reclaim memory after a certain configurable (based on user
class) period of time passes after the OWAMP-Test session terminates. class) period of time passes after the OWAMP-Test session terminates.
10. IANA Considerations 6.6. Use of Cryptographic Primitives in OWAMP
IANA is requested to allocate a well-known TCP port number for OWAMP- At an early stage in designing the protocol, we considered using TLS
Control part of the OWAMP protocol. and IPsec as cryptographic security mechanisms for OWAMP. The
disadvantages of those are as follows (not an exhaustive list):
11. Internationalization Considerations Regarding TLS:
+ While TLS could be used to secure TCP-based OWAMP-Control, but
difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test
packets, if lost, are not resent, so packets have to be
(optionally) encrypted and authenticated while retaining
individual usability. Stream-based TLS is not conducive of this.
+ Dealing with streams, does not authenticate individual messages
(even in OWAMP-Control). The easiest way out would be to add some
known-format padding to each message and verify that the format of
the padding is intact before using the message. The solution
would thus lose some of its appeal (``just use TLS''); it would
also be much more difficult to evaluate the security of this
scheme with the various modes and options of TLS---it would almost
certainly not be secure with all. The capacity of an attacker to
replace parts of messages (namely, the end) with random garbage
could have serious security implications and would need to be
analyzed carefully: suppose, for example, that a parameter that is
used in some form to control the rate were replaced by random
garbage---chances are the result (an unsigned integer) would be
quite large.
+ Dependent on the mode of use, one can end up with a requirement
for certificates for all users and a PKI. Even if one is to
accept that PKI is desirable, there just isn't a usable one today.
+ TLS requires a fairly large implementation. OpenSSL, for example,
is larger than our implementation of OWAMP as a whole. This can
matter for embedded implementations.
Regarding IPsec:
+ What we now call authenticated mode would not be possible (in
IPsec you can't authenticate part of a packet).
+ The deployment paths of IPsec and OWAMP could be separate if OWAMP
does not depend on IPsec. After nine years of IPsec, only 0.05%
of traffic on an advanced backbone network such as Abilene uses
IPsec (for comparison purposes with encryption above layer 4, SSH
use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to
be able to deploy OWAMP on as large of a number of different
platforms as possible.
+ The deployment problems of a protocol dependent on IPsec would be
especially acute in the case of lightweight embedded devices.
Ethernet switches, DSL ``modems,'' and other such devices mostly
do not support IPsec.
+ The API for manipulation IPsec from an application is currently
poorly understood. Writing a program that needs to encrypt some
packets, authenticate some packets, and leave some open---for the
same destination---would become more of an exercise in IPsec
rather than IP measurement.
For the enumerated reasons, we decided to use a simple cryptographic
protocol (based on a block cipher in CBC mode) that is different from
TLS and IPsec.
6.7. Required Properties of MD5
The protocol makes use of the MD5 hash function to convert a
user-supplied passphrase into a key that will be used to encrypt a
short piece of random data (the session key).
In this document we use cryptographic terminology of [MENEZES].
It has long been suspected, and has been conclusively shown recently
that MD5 is not a collision-resistant hash function. Since collision
resistance was one of design goals of MD5, this casts strong
suspicion on the other design goals of MD5, namely preimage
resistance and 2nd preimage resistance.
OWAMP does not rely on any of these properties.
The properties of MD5 that are necessary are as follows: (1) it's a
function that maps arbitrary length inputs into 128-bit outputs
[fixed-length hash function], (2) a change in any bit of the input
usually results in a change of a few bits of output [weakened
avalanche property], (3) many 128-bit strings have preimages [almost
surjective], and (4) the visible special structure of
natural-language text possibly present in the passphrase is concealed
after application of the function. These are very weak requirements
that many functions satisfy. Something resembling CRC-128 would work
just as well.
We chose MD5 here because it has the required properties and is
widely implemented, understood, and documented. Alternatives would
include (1) a non-cryptographic primitive, such as CRC-128, (2) SHA-1
truncated to 128 bits, or (3) a hash function based on AES (using
Matyas-Meyer-Oseas, Davies-Meyer, or Miyaguchi-Preneel constructions;
we would probably gravitate towards the last one if a block-cipher-
based cryptographically secure hash function were required). Note
that option 1 would not have any cryptographically relevant
properties. We chose not to use it because of lack of
well-documented 128-bit checksums; this specification would incur an
unnecessary burden precisely defining one, providing test vectors,
etc., with no advantage over MD5. Option 2, SHA-1, belongs to the
MD4 family that appears to be under suspicion in light of recent
developments. To avoid creating an impression that any potential
future changes in the status of SHA-1 can affect the status of OWAMP
we chose not to use it. Option 3 would result in a hash function
that, with the current state of knowledge, would probably be one of
the most cryptographically sound. Our requirements 1-4 from the
preceding paragraph, however, do not call for a cryptographically
sound hash function. Just as with CRC-128, this specification would
need to define the hash function and provide test vectors (and
perhaps sample code); we see no advantage in this approach versus
using MD5. (Note that the performance advantages of MD5 are
irrelevant for this application, as the hash is computed on a
relatively short human-supplied string only once per OWAMP-Control
session, so if the Miyaguchi-Preneel construction were documented in
an RFC, we might just as well have used that.)
6.8. The Use of AES-CBC-MAC
OWAMP relies on AES-CBC-MAC for message authentication. Random IV
choice is important for prevention of a codebook attack on the first
block, it is unimportant for the purposes of CBC-MAC authentication
(it should also be noted that with its 128-bit block size, AES is
more resistant to codebook attacks than ciphers with shorter blocks;
we use random IV anyway).
Integrity zero padding, when decrypted, MUST be zero. It is crucial
to check for this before using the message, otherwise existential
forgery becomes possible. The complete message for which integrity
zero padding is decrypted to non-zero MUST be discarded (for both
short messages consisting of a few blocks and potentially long
messages, such as a response to the Fetch-Session command).
Since OWAMP messages can have different numbers of blocks,
existential forgery attack described in example 9.62 of [MENEZES]
becomes a concern. To prevent it (and to simplify implementation),
the length of any message becomes known after decrypting the first
block of it.
A special case is the first (fixed-length) message sent by the
client. There, the token is a concatenation of the 128-bit challenge
(transmitted by the server in the clear) and a 128-bit session key
(generated randomly by the client, encrypted with AES-CBC with IV=0.
Since IV=0, the challenge (a single cipher block) is simply encrypted
with the secret key. Therefore, we rely on resistance of AES to
chosen plaintext attacks (as the challenge could be substituted by an
attacker). It should be noted that the number of blocks of chosen
plaintext an attacker can have encrypted with the secret key is
limited by the number of sessions the client wants to initiate. An
attacker who knows the encryption of a server's challenge can produce
an existential forgery of the session key and thus disrupt the
session; however, any attacker can disrupt a session by corrupting
the protocol messages in an arbitrary fashion, therefore no new
threat is created here; nevertheless, we require that the server
never issues the same challenge twice (if challenges are generated
randomly, a repetition would occur, on average, after 2^64 sessions;
we deem this satisfactory as this is enough even for an implausibly
busy server that participates in 1,000,000 sessions per second to go
without repetitions for more than 500 centuries). With respect to
the second part of the token, an attacker can produce an existential
forgery of the session key by modifying the second half of the
client's token while leaving the first part intact. This forgery,
however, would be immediately discovered by the client when the
integrity zero padding on the server's next message (acceptance or
rejection of the connection) does not verify.
7. IANA Considerations
IANA is requested to allocate a well-known TCP port number for the
OWAMP-Control part of the OWAMP protocol.
8. Internationalization Considerations
The protocol does not carry any information in a natural language. The protocol does not carry any information in a natural language.
12. Appendix A: Sample Implementation of Exponential Deviate Computation 9. Appendix A: Sample C Code for Exponential Deviates
The values in array Q[] are the exact values that MUST be used by all
implementations. The rest of this appendix only serves for
illustrative purposes.
/* /*
** 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 33, line 47 skipping to change at page 40, line 5
** } ** }
*/ */
#include <stdlib.h> #include <stdlib.h>
typedef u_int64_t u_int64_t; typedef u_int64_t u_int64_t;
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12 #define K 12
#define BIT31 0x80000000UL /* see if first bit in the lower #define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero */ 32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL) #define MASK32(n) ((n) & 0xFFFFFFFFUL)
#define EXP2POW32 0x100000000ULL #define EXP2POW32 0x100000000ULL
typedef struct OWPrand_context { typedef struct OWPrand_context {
unsigned char counter[16]; /* 16-octet counter (network byte order) */ unsigned char counter[16]; /* Counter (network byte order). */
keyInstance key; /* key used to encrypt the counter. */ keyInstance key; /* Key to encrypt the counter. */
unsigned char out[16]; /* the encrypted block is kept there. */ unsigned char out[16]; /* The encrypted block. */
} OWPrand_context; } OWPrand_context;
/* /*
** The array has been computed according to the formula: ** The array has been computed according to the formula:
** **
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) ** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
** **
** as described in algorithm S. (The values below have been ** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.) ** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation ** These exact values MUST be used so that different implementation
skipping to change at page 34, line 42 skipping to change at page 40, line 46
0xFFFFFE2B, 0xFFFFFE2B,
0xFFFFFFE0, 0xFFFFFFE0,
0xFFFFFFFE, 0xFFFFFFFE,
0xFFFFFFFF 0xFFFFFFFF
}; };
/* this element represents ln2 */ /* this element represents ln2 */
#define LN2 Q[1] #define LN2 Q[1]
/* /*
** Convert an unsigned 32-bit integer into a u_int64_t number.. ** Convert an unsigned 32-bit integer into a u_int64_t number.
*/ */
u_int64_t u_int64_t
OWPulong2num64(u_int32_t a) OWPulong2num64(u_int32_t a)
{ {
return ((u_int64_t)1 << 32) * a; return ((u_int64_t)1 << 32) * a;
} }
/* /*
** Arithmetic functions on u_int64_t numbers. ** Arithmetic functions on u_int64_t numbers.
*/ */
skipping to change at page 35, line 16 skipping to change at page 41, line 20
** Addition. ** Addition.
*/ */
u_int64_t u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y) OWPnum64_add(u_int64_t x, u_int64_t y)
{ {
return x + y; return x + y;
} }
/* /*
** Multiplication. Allows overflow. Straightforward implementation ** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH] ** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/ */
u_int64_t u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y) OWPnum64_mul(u_int64_t x, u_int64_t y)
{ {
unsigned long w[4]; unsigned long w[4];
u_int64_t xdec[2]; u_int64_t xdec[2];
u_int64_t ydec[2]; u_int64_t ydec[2];
int i, j; int i, j;
u_int64_t k, t, ret; u_int64_t k, t, ret;
skipping to change at page 36, line 33 skipping to change at page 42, line 37
for (i = 0; i < 16; i++) for (i = 0; i < 16; i++)
next->counter[i] = 0UL; next->counter[i] = 0UL;
} }
/* /*
** Random number generating functions. ** Random number generating functions.
*/ */
/* /*
** Generate and return a 32-bit uniform random string (saved in the less ** Generate and return a 32-bit uniform random string (saved in the less
** significant half of the u_int64_t). This function implements steps U2-U4 ** significant half of the u_int64_t). This function implements steps
** of the algorithm Unif. ** U2-U4 of the algorithm Unif.
*/ */
u_int64_t u_int64_t
OWPunif_rand64(OWPrand_context *next) OWPunif_rand64(OWPrand_context *next)
{ {
int j; int j;
u_int8_t *buf; u_int8_t *buf;
u_int64_t ret = 0; u_int64_t ret = 0;
/* step U2 */ /* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3; u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i) if (!i)
rijndaelEncrypt(next->key, next->counter, next->out); rijndaelEncrypt(next->key, next->counter, next->out);
/* Step U3. Increment next.counter as a 16-octet single quantity /* Step U3. Increment next.counter as a 16-octet single
in network byte order for AES counter mode. */ quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--) for (j = 15; j >= 0; j--)
if (++next->counter[j]) if (++next->counter[j])
break; break;
/* Step U4. Do output. The last 4 bytes of ret now contain the /* Step U4. Do output. The last 4 bytes of ret now contain the
random integer in network byte order */ random integer in network byte order */
buf = &next->out[4*i]; buf = &next->out[4*i];
for(j=0;j<4;j++){ for(j=0;j<4;j++){
ret <<= 8; ret <<= 8;
ret += *buf++; ret += *buf++;
} }
return ret; return ret;
} }
/* /*
** Generate a mean 1 exponential deviate. ** Generate an exponential deviate with mean 1.
*/ */
u_int64_t u_int64_t
OWPexp_rand64(OWPrand_context *next) OWPexp_rand64(OWPrand_context *next)
{ {
unsigned long i, k; unsigned long i, k;
u_int32_t j = 0; u_int32_t j = 0;
u_int64_t U, V, J, tmp; u_int64_t U, V, J, tmp;
/* Step S1. Get U and shift */ /* Step S1. Get U and shift */
U = OWPunif_rand64(next); U = OWPunif_rand64(next);
while ((U & BIT31) && (j < 32)){ /* shift until find first '0' */ while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1; U <<= 1;
j++; j++;
} }
/* remove the '0' itself */ /* Remove the 0 itself. */
U <<= 1; U <<= 1;
U = MASK32(U); /* Keep only the fractional part. */ U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j); J = OWPulong2num64(j);
/* Step S2. Immediate acceptance? */ /* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */ if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U); return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S3. Minimize. */ /* Step S3. Minimize. */
skipping to change at page 38, line 13 skipping to change at page 44, line 16
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);
} }
13. Appendix B: Test Vectors for Exponential Deviates 10. 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 38, line 42 skipping to change at page 45, line 5
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)
14. 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, [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 39, line 30 skipping to change at page 45, line 38
[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.
15. Informative References 12. 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.
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,
Handbook of Applied Cryptography, CRC Press, revised reprint
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.
[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
[RIPE] RIPE NCC Test-Traffic Measurements home, [RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-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/test- Group Meeting,
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
16. Authors' Addresses 13. Authors' Addresses
Stanislav Shalunov <shalunov@internet2.edu> Stanislav Shalunov
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Telephone: +1-734-995-7060
Email: shalunov@internet2.edu
SIP: shalunov@internet2.edu
Benjamin Teitelbaum <ben@internet2.edu> Benjamin Teitelbaum
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Email: ben@internet2.edu
SIP: ben@internet2.edu
Anatoly Karp <ankarp@yahoo.com> Anatoly Karp
4710 Regent St Apt 81B
Madison, WI 53705
Telephone: +1-608-347-6255
Email: ankarp@charter.net
Jeff W. Boote
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Email: boote@internet2.edu
SIP: boote@internet2.edu
Jeff Boote <boote@internet2.edu> Matthew J. Zekauskas
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Email: matt@internet2.edu
Matthew J. Zekauskas <matt@internet2.edu> Intellectual Property
Expiration date: January 2005 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgments
We would like to thank Bernard Aboba, Guy Almes, Hamid Asgari, Steven
Van den Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen
Donnelly, Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi, Daniel
H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al
Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy
Scherrer, Henk Uijterwaal, and Sam Weiler for their comments,
suggestions, reviews, helpful discussion and proof-reading.
Expiration date: February 2005
 End of changes. 

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