wdiff draft-ietf-ippm-owdp-09.txt draft-ietf-ippm-owdp-10.txt

Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum
Expiration Date: January February 2005 Anatoly Karp
Jeff W. Boote
Matthew J. Zekauskas
Internet2
July
August 2004

A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-09.txt>

1.
<draft-ietf-ippm-owdp-10.txt>

Status of this Memo

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026.
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft shadow directories Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This memo provides information for the Internet community. This memo
does not specify an
http://www.ietf.org/shadow.html.

Abstract

With growing availability of good time sources to network nodes, it
becomes increasingly possible to measure one-way IP performance
metrics with high precision. To do so in an interoperable manner, a
common protocol for such measurements is required. The One-Way
Active Measurement Protocol (OWAMP) can measure one-way delay, as
well as other unidirectional characteristics, such as one-way loss.

3. Motivation and Goals

The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC 2680] across Internet paths. Although there are now several
measurement platforms that implement collection of these metrics
[SURVEYOR], [RIPE], there is not currently a standard that would
permit initiation of test streams or exchange of packets to collect
singleton metrics in an interoperable manner.

With the increasingly wide availability of affordable global
positioning system (GPS) and CDMA based time sources, hosts
increasingly have available to them very accurate time
sources--either directly or through their proximity to NTP primary
(stratum 1) time servers. By standardizing a technique for
collecting IPPM one-way active measurements, we hope to create an
environment where IPPM metrics may be collected across a far broader
mesh of Internet paths than is currently possible. One particularly
compelling vision is of widespread deployment of open OWAMP servers
that would make measurement of one-way delay as commonplace as
measurement

Table of round-trip time using an ICMP-based tool like ping.

Additional design goals Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship of OWAMP include being hard to detect 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
draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC2680] across Internet paths. Although there are now several
measurement platforms that implement collection of these metrics
[SURVEYOR], [RIPE], there is not currently a standard that would
permit initiation of test streams or exchange of packets to collect
singleton metrics in an interoperable manner.

Additional design goals of OWAMP include being hard to detect and
manipulate, security, logical separation of control and test
functionality,
functionality, and support for small test packets.

OWAMP test traffic is hard to detect, because it is simply a stream
of UDP packets from and to negotiated port numbers with potentially
nothing static in the packets (size is negotiated, too).
Additionally, OWAMP supports an encrypted mode, that further obscures
the traffic, at the same time making it impossible to alter
timestamps undetectably.

Security features include optional authentication and/or encryption
of control and test messages. These features may be useful to
prevent unauthorized access to results or man-in-the-middle attackers
who attempt to provide special treatment to OWAMP test streams or who
attempt to modify sender-generated timestamps to falsify test
results.

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
and OWAMP-Test. OWAMP-Control is used to initiate, start and stop
test sessions and fetch their results, while OWAMP-Test is used to
exchange test packets between two measurement nodes.

Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, the authors have deliberately
chosen to include both protocols in the same draft to encourage the
implementation and deployment of OWAMP-Control as a common
denominator control protocol for one-way active measurements. Having
a complete and open one-way active measurement solution that is
simple to implement and deploy is crucial to assuring a future in
which inter-domain one-way active measurement could become as
commonplace as ping. We neither anticipate nor recommend that
OWAMP-Control form the foundation of a general-purpose extensible
measurement and monitoring control protocol.

OWAMP-Control is designed to support the negotiation of one-way
active measurement sessions and results retrieval in a
straightforward manner. At session initiation, there is a negotiation
of sender and receiver addresses and port numbers, session start
time, session length, test packet size, the mean Poisson sampling
interval for the test stream, and some attributes of the very general
RFC 2330 notion of `packet type', including packet size and per-hop
behavior (PHB) [RFC2474], which could be used to support the
measurement of one-way active across diff-serv networks.
Additionally, OWAMP-Control supports per-session encryption and
authentication for both test and control traffic, measurement servers
which may act as proxies for test stream endpoints, and support the exchange
of a seed value for small test packets.

OWAMP the pseudo-random Poisson process that describes
the test traffic is hard to detect, because it is simply a stream generated by the sender.

We believe that OWAMP-Control can effectively support one-way active
measurement in a variety of UDP packets environments, from and publicly accessible
measurement `beacons' running on arbitrary hosts to negotiated port numbers network
monitoring deployments within private corporate networks. If
integration with potentially
nothing static SNMP or proprietary network management protocols is
required, gateways may be created.

1.2. Logical Model

Several roles are logically separated to allow for broad flexibility
in use. Specifically, we define:

Session-Sender the packets (size sending 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
sessions, is negotiated, too).
Additionally, OWAMP supports capable of configuring per-session
state in session endpoints, and is capable of
returning the results of a test session;

Control-Client an encrypted mode, end system that further obscures initiates requests for
OWAMP-Test sessions, triggers the traffic, at start of a set
of sessions, and may trigger their termination;

Fetch-Client an end system that initiates requests to fetch
the results of completed OWAMP-Test sessions;

One possible scenario of relationships between these roles is shown
below.

+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+

(Unlabeled links in the same time making it impossible to alter
timestamps undetectably.

Security features include optional authentication and/or encryption
of control figure are unspecified by this draft and test messages. These features may
be useful to
prevent unauthorized access to results or man-in-the-middle attackers
who attempt to provide special treatment to OWAMP test streams or who
attempt to modify sender-generated timestamps to falsify test
results.

3.1. Relationship proprietary protocols.)

Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one
playing the roles of Test Control-Client, Fetch-Client, and Control Protocols

OWAMP actually consists
Session-Sender, and the other playing the roles of two inter-related protocols: OWAMP-Control Server and OWAMP-Test. OWAMP-Control
Session-Receiver. This is used to initiate, start shown below.

Finally, because many Internet paths include segments that transport
IP over ATM, delay and stop
test sessions loss measurements can include the effects of
ATM segmentation and fetch their results, while OWAMP-Test is used reassembly (SAR). Consequently, OWAMP has been
designed to
exchange allow for small test packets between two measurement nodes.

Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, that would fit inside the authors have deliberately
chosen to include both protocols
payload of a single ATM cell (this is only achieved in the same draft to encourage the
implementation
unauthenticated and deployment encrypted modes).

2. Protocol Overview

As described above, OWAMP consists of OWAMP-Control as a common
denominator control protocol for one-way active measurements. Having
a complete two inter-related protocols:
OWAMP-Control and open one-way active measurement solution that OWAMP-Test. The former is
simple to implement layered over TCP and deploy is crucial
used to assuring a future in
which inter-domain one-way active measurement could become as
commonplace as ping. We neither anticipate nor recommend that OWAMP-
Control form the foundation of a general purpose extensible
measurement initiate and monitoring control protocol.

OWAMP-Control measurement sessions and to fetch their
results. The latter protocol is designed layered over UDP and is used to support send
singleton measurement packets along the negotiation Internet path under test.

The initiator of one-way
active the measurement sessions and results retrieval in a
straightforward manner. At session initiation, there is establishes a negotiation
of sender and receiver addresses and TCP connection
to a well-known port numbers, session start
time, session length, test packet size, on the mean Poisson sampling
interval target point and this connection remains
open for the test stream, and some attributes duration of the very general
RFC 2330 notion of `packet type', including packet size and per-hop
behavior (PHB) [RFC2474], which could OWAMP-Test sessions. IANA will be used
requested to support allocate a well-known port number for OWAMP-Control
sessions. An OWAMP server SHOULD listen to this well-known port.

OWAMP-Control messages are transmitted only before OWAMP-Test
sessions are actually started and after they complete (with the
measurement
possible exception of one-way active across diff-serv networks.
Additionally, an early Stop-Sessions message).

The OWAMP-Control supports per-session encryption and
authentication for both test OWAMP-Test protocols support three modes of
operation: unauthenticated, authenticated, and control traffic, measurement servers
which may act encrypted. The
authenticated or encrypted modes require endpoints to possess a
shared secret.

All multi-octet quantities defined in this document are represented
as proxies for test stream endpoints, and the exchange unsigned integers in network byte order unless specified
otherwise.

3. OWAMP-Control

Each type of OWAMP-Control message has a seed value for the pseudo-random Poisson process that describes
the test stream generated by fixed length. The recipient
will know the sender.

We believe that OWAMP-Control can effectively support one-way active
measurement in full length of a variety message after examining first 16
octets of environments, from publicly accessible
measurement `beacons' running on arbitrary hosts to network
monitoring deployments within private corporate networks. it. No message is shorter than 16 octets.

If
integration with SNMP or proprietary network management protocols the full message is
required, gateways may not received within 30 minutes after it is
expected, connection SHOULD be created.

3.2. Logical Model

Several roles are logically separated dropped.

3.1. Connection Setup

Before either a Control-Client or a Fetch-Client can issue commands
of a Server, it must establish a connection to allow for broad flexibility
in use. Specifically, we define:

Session-Sender the sending endpoint server.

First, a client opens a TCP connection to the server on a well-known
port. The server responds with a server greeting:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following mode values are meaningful: 1 for unauthenticated, 2
for authenticated, 4 for encrypted. The value of an OWAMP-Test session;

Session-Receiver the receiving endpoint Modes field
sent by the server is the bit-wise OR of an OWAMP-Test session;

Server an end system the mode values that manages one or more OWAMP-Test
sessions, it is capable
willing to support during this session. Thus, last three bits of configuring per-session
state the
Modes 32-bit value are used. The first 29 bits MUST be zero. A
client MUST ignore the values in session endpoints, and is capable of
returning the results first 29 bits of a test session;
Control-Client an end system that initiates requests the Modes
value. (This way, the bits are available for
OWAMP-Test sessions, triggers future protocol
extensions. This is the start of only intended extension mechanism.)

Challenge is a set random sequence of sessions, octets generated by the server; it
is used subsequently by the client to prove possession of a shared
secret in a manner prescribed below.

If Modes value is zero, the server doesn't wish to communicate with
the client and may trigger their termination;

Fetch-Client an end system that initiates requests MAY close the connection immediately. The client
SHOULD close the connection if it gets a greeting with Modes equal to fetch
zero. The client MAY close the results of completed OWAMP-Test sessions;

One possible scenario of relationships between these roles connection if the client's desired
mode is shown
below.

Otherwise, the client MUST respond with the following message:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Username (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OWAMP-Control OWAMP-Control |
. .
. Token (32 octets) .
. .
| |
v v v
+----------------+ +-----------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control-Client |
. .
. Client-IV (16 octets) .
. .
| Fetch-Client |
+----------------+ +-----------------+

(Unlabeled links in the figure are unspecified by this draft and may
be proprietary protocols.)

Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Fetch-Client, and Session-
Sender, and the other playing the roles of Server and Session-
Receiver. This
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here Mode is shown below.

Finally, because many Internet paths include segments the mode that transport
IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWAMP has been
designed client chooses to allow use during this
OWAMP-Control session. It will also be used for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in
unauthenticated and encrypted modes).

4. Protocol Overview

As described above, OWAMP consists all OWAMP-Test
sessions started under control of two inter-related protocols: this OWAMP-Control and OWAMP-Test. session. In
Mode, one or zero bits MUST be set within last three bits. The former is layered over TCP first
29 bits of Mode MUST be zero. A server MUST ignore the values of the
first 29 bits.

In unauthenticated mode, Username, Token, and Client-IV are unused.

Otherwise, Username is
used a 16-octet indicator of which shared secret
the client wishes to initiate and control measurement sessions and use to fetch their
results. The latter protocol is layered over UDP authenticate or encrypt and Token is used to send
singleton measurement packets along the Internet path under test.

The initiator
concatenation of the measurement session establishes a TCP connection
to 16-octet challenge and a well-known port on 16-octet Session-key,
encrypted using the target point AES (Advanced Encryption Standard) [AES] in
Cipher Block Chaining (CBC). Encryption MUST be performed using an
Initialization Vector (IV) of zero and this connection remains
open for a key value that is the duration of shared
secret associated with Username. (Both the OWAMP-Test sessions. IANA will be
requested to allocate a well-known port number for OWAMP-Control
sessions. An OWAMP server SHOULD listen to this well-known port.

OWAMP-Control messages are transmitted only before OWAMP-Test
sessions are actually started and after they complete (with the
possible exception of an early Stop-Session message).

The OWAMP-Control and OWAMP-Test protocols support three modes of
operation: unauthenticated, authenticated, and encrypted. The
authenticated or encrypted modes require endpoints client use
the same mappings from user names to possess secret keys; the server, being
prepared to conduct sessions with more than one client, uses user
names to choose the appropriate secret key; a
shared secret.

All multi-octet quantities defined in this document client would typically
have different secret keys for different servers. The situation is
analogous to that of passwords, except that secret keys, rather than
being the typical low-entropy passwords, are represented suitable for use as unsigned integers in network byte order unless specified
otherwise.

5. OWAMP-Control

Each type of OWAMP-Control message has a fixed length. AES
keys.) The recipient shared secret will know typically be provided as a passphrase;
in this case, the full length MD5 sum [RFC1321] of a message after examining first 16
octets the passphrase (without
possible newline character(s) at the end of it. No message is shorter than 16 octets.

If the full message is not received within 30 minutes after it is
expected, connection passphrase) SHOULD be dropped.

5.1. Connection Setup

Before either a Control-Client or
used as a Fetch-Client can issue commands key for encryption by the client and decryption by the
server (the passphrase also SHOULD NOT contain newlines in the
middle).

Session-key and Client-IV are generated randomly by the client.
Session-key MUST be generated with sufficient entropy not to reduce
the security of a Server, the underlying cipher. Client-IV merely needs to be
unique (i.e., it must establish MUST never be repeated for different sessions using
the same secret key; a connection simple way to achieve that without the use of
cumbersome state is to generate the server.

First, a client opens Client-IV strings using a TCP connection
cryptographically secure pseudo-random number source: if this is
done, the first repetition is unlikely to occur before 2^64 sessions
with the server on a well-known
port. same secret key are conducted).

The server responds MUST respond with a server greeting: the following message:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 Unused, MBZ (15 octets) |
| |
| +-+-+-+-+-+-+-+-+
| | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Server-IV (16 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime (Timestamp) |
| Challenge (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Zero Padding (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following mode values are meaningful: 1 for unauthenticated, 2
for authenticated, 4 for encrypted. Unused 15-octet part MUST be zero. The value client MUST ignore its
value. MBZ (MUST be zero) fields here and hereafter have the same
semantics: the party that sends the message MUST set the field to a
string of zero bits; the party that interprets the message MUST
ignore the value. (This way the Modes field
sent could be used for future
extensions.)

Server-IV is generated randomly by the server server. In unauthenticated
mode, Server-IV is unused.

A zero value in the bit-wise OR of Accept field means that the mode values server accepts the
authentication and is willing to conduct further transactions. A
value of 1 means that it the server does not accept the authentication
provided by the client or, for some other reason, is not willing to support during
conduct further transactions in this OWAMP-Control session. Thus, last three bits of the
Modes 32-bit value All
other values are used. reserved. The first 29 bits MUST be zero. A client MUST ignore the interpret all values in the first 29 bits of the Modes
value. (This
Accept other than 0 and 1 as 1. This way, the bits other values are available
for future protocol extensions. This is the only intended extension mechanism.)

Challenge is a random sequence of octets generated by the server; it
is used subsequently by the client to prove possession of a shared
secret in a manner prescribed below. If Modes value a negative response is zero, sent, the server doesn't wish to communicate with
the client and
MAY close and the connection immediately. The client SHOULD close the connection if it gets after this message.

Uptime is a greeting with Modes equal to
zero. The client MAY close the connection if timestamp representing the client's desired
mode is unavailable.

Otherwise, time when the client MUST respond with current
instantiation of the following message:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Username (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Token (32 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here Mode is server started operating. (For example, in a
multi-user general purpose operating system, it could be the mode that time
when the client chooses to use during this
OWAMP-Control session. It will also server process was started.) If Accept is non-zero, Uptime
SHOULD be used for all OWAMP-Test
sessions started under control set to a string of this OWAMP-Control session. zeros. In
Mode, one or zero bits MUST authenticated and encrypted
modes, Uptime is encrypted as described in the next section, unless
Accept is non-zero. (authenticated and encrypted mode can not be set within last three bits. The first
29 bits of Mode MUST
entered unless the control connection can be zero. A initialized.)

Timestamp format is described in `Sender Behavior' section below.
The same instantiation of the server MUST ignore SHOULD report the values of same exact
Uptime value to each client in each session.

Integrity Zero Padding is treated the
first 29 bits.

In unauthenticated mode, Username, Token, same way as Integrity Zero
Padding in the next section and Client-IV beyond.

The previous transactions constitute connection setup.

3.2. OWAMP-Control Commands

In authenticated or encrypted mode (which are unused.

Otherwise, Username identical as far as
OWAMP-Control is a 16-octet indicator of which shared secret
the client wishes to use to authenticate or encrypt concerned, and Token is only differ in OWAMP-Test) all
further communications are encrypted with the
concatenation of a 16-octet challenge and a 16-octet Session-key,
encrypted using the AES (Advanced Encryption Standard) [AES] in
Cipher Block Chaining (CBC). Encryption MUST be performed CBC
mode. The client encrypts its stream using an
Initialization Vector (IV) of zero and a key value that Client-IV. The server
encrypts its stream using Server-IV.

The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Sessions, Fetch-Session. The command
Stop-Sessions is available to both the shared
secret associated with Username. (Both client and the server. (The
server can also send other messages in response to commands it
receives.)
After Start-Sessions is sent/received by the client/server, and
before it both sends and receives Stop-Sessions (order unspecified),
it is said to be conducting active measurements.

While conducting active measurements, the only command available is
Stop-Sessions.

These commands are described in detail below.

3.3. Creating Test Sessions

Individual one-way active measurement sessions are established using
a simple request/response protocol. An OWAMP client use
the same mappings from user names MAY issue zero or
more Request-Session messages to secret keys; the an OWAMP server, being
prepared which MUST respond
to conduct sessions each with more than one client, uses user
names to choose the appropriate secret key; an Accept-Session message. An Accept-Session message
MAY refuse a client would typically
have different secret keys for different servers. request.

The situation is
analogous to that format of passwords, except that secret keys, rather than
being the typical low-entropy passwords, are suitable for use as AES
keys.) The shared secret will typically be provided Request-Session message is as a passphrase;
in this case, the MD5 sum [RFC1321] follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of the passphrase (without
possible newline character(s) at the end Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of the passphrase) SHOULD be
used as a key for encryption by the client and decryption Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) or MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is immediately followed by the
server one or more schedule slot
descriptions (the passphrase also SHOULD NOT contain newlines in the
middle).

Session-key and Client-IV are generated randomly by the client.
Session-key MUST be generated with sufficient entropy not to reduce
the security of the underlying cipher. Client-IV merely needs to be
unique (i.e., it MUST never be repeated for different sessions using
the same secret key; a simple way to achieve that without the use of
cumbersome state is to generate the Client-IV strings using a
cryptographically secure pseudo-random number source: if this is
done, the first repetition of schedule slots is unlikely to occur before 2^64 sessions
with the same secret key are conducted).

The server MUST respond with specified in the following message:
`Number of Schedule Slots' field above):

These are immediately followed by Integrity Zero Padding:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Zero Padding (8 (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Unused 15-octet part

All these messages comprise one logical message: the Request-Session
command.

Above, the first octet (1) indicates that this is Request-Session
command.

IPVN is the IP version numbers for Sender and Receiver. In the case
of IP version number being 4, twelve octets follow the four-octet
IPv4 address stored in Sender Address and Receiver address. These
octets MUST be zero. The set to zero by the client and MUST ignore its
value. MBZ (MUST be zero) fields here ignored by the
server. Currently meaningful IPVN values are 4 and hereafter have 6.

Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the same
semantics: client.
The server MUST interpret any non-zero value as 1. If the party that sends value is
1, the message server is being asked to configure the corresponding agent
(sender or receiver). In this case, the corresponding Port value
SHOULD be disregarded by the server. At least one of Conf-Sender and
Conf-Receiver MUST set be 1. (Both can be set, in which case the field server
is being asked to perform a
string session between two hosts it can
configure.)

Number of zero bits; Schedule Slots, as mentioned before, specifies the party number
of slot records that interprets the message MUST
ignore the value. (This way go between the field could be used for future
extensions.)

Server-IV two blocks of Integrity Zero
Padding. It is generated randomly used by the server. In unauthenticated
mode, Server-IV sender to determine when to send test
packets (see next section).

Number of Packets is unused.

A zero value in the Accept field means number of active measurement packets to be
sent during this OWAMP-Test session (note that the both server accepts the
authentication and client
can abort the session early).

If Conf-Sender is not set, Sender Port is the UDP port OWAMP-Test
packets will be sent from. If Conf-Receiver is not set, Receiver
Port is willing the UDP port OWAMP-Test packets are requested to conduct further transactions. A
value of 1 means that be sent to.

The Sender Address and Receiver Address fields contain respectively
the server does not accept sender and receiver addresses of the authentication
provided by end points of the client or, for some other reason, Internet
path over which an OWAMP test session is not willing to
conduct further transactions requested.

SID is the session identifier. It can be used in this OWAMP-Control session. All
other values are reserved. The client MUST interpret all values of
Accept other than 0 and 1 later sessions as 1.
an argument for Fetch-Session command. It is meaningful only if
Conf-Receiver is 0. This way, other values are available
for future extensions. If a negative response the SID is sent, always generated by the server
MAY and
receiving side. See the client SHOULD close end of the connection after this message.

Uptime is a timestamp representing section for information on how
the time when SID is generated.

Padding length is the current
instantiation number of the server started operating. (For example, in a
multi-user general purpose operating system, it could octets to be appended to normal
OWAMP-Test packet (see more on padding in discussion of OWAMP-Test).

Start Time is the time when the server process was started.) If Accept session is non-zero, Uptime
SHOULD be set to be started (but not
before Start-Sessions command is issued). This timestamp is in the
same format as OWAMP-Test timestamps.

Timeout (or a string of zeros. In authenticated and encrypted
modes, Uptime loss threshold) is encrypted an interval of time (expressed as described in a
timestamp). A packet belonging to the next section, unless
Accept test session that is non-zero. (authenticated and encrypted mode can not be
entered unless being set
up by the control connection can current Request-Session command will be initialized.)

Timestamp format considered lost if
it is described in `Sender Behavior' section below.
The same instantiation not received during Timeout seconds after it is sent.

Type-P Descriptor covers only a subset of (very large) Type-P space.
If the server SHOULD report first two bits of Type-P Descriptor are 00, then subsequent 6
bits specify the same exact
Uptime requested Differentiated Services Codepoint (DSCP)
value to each client in each session.

Integrity Zero Padding is treated the same way of sent OWAMP-Test packets as Integrity Zero
Padding defined in RFC 2474. If the next section and beyond.

The previous transactions constitute connection setup.

5.2. OWAMP-Control Commands

In authenticated or encrypted mode (which
first two bits of Type-P descriptor are identical as far 01, then subsequent 16 bits
specify the requested Per Hop Behavior Identification Code (PHB ID)
as
OWAMP-Control is concerned, and only differ defined in OWAMP-Test) all
further communications are encrypted with the Session-key, using CBC
mode. The client encrypts its stream using Client-IV. The server
encrypts its stream using Server-IV.

The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Session, Fetch-Session. The command Stop-
Session is available to both RFC 2836.

Therefore, the client and value of all zeros specifies the server. (The server
can also send other messages in response to commands it receives.)

After Start-Sessions default best-effort
service.

If Conf-Sender is sent/received by the client/server, and
before it both sends and receives Stop-Session (order unspecified),
it set, Type-P Descriptor is said to be conducting active measurements.

While conducting active measurements, used to configure
the only command available is
Stop-Session.

These commands are described in detail below.

5.3. Creating Test Sessions

Individual one-way active measurement sessions are established using
a simple request/response protocol. An OWAMP client MAY issue zero or
more Request-Session messages sender to an OWAMP server, which MUST respond send packets according to each with an Accept-Session message. An Accept-Session message
MAY refuse its value. If Conf-Sender is
not set, Type-P Descriptor is a request.

The format declaration of Request-Session message is as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | how the sender will be
configured.

If Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) is set and the server doesn't recognize Type-P
Descriptor, cannot or MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| does not wish to set the corresponding
attributes on OWAMP-Test packets, it SHOULD reject the session
request. If Conf-Sender is not set, the server SHOULD accept the
session regardless of the value of Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Descriptor.

Integrity Zero Padding (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This MUST be all zeros in this and all subsequent
messages that use zero padding. The recipient of a message where
zero padding is immediately followed not zero MUST reject the message as it is an
indication of tampering with the content of the message by one or more schedule slot
descriptions (the number an
intermediary (or brokenness). If the message is part of schedule slots
OWAMP-Control, the session MUST be terminated and results
invalidated. If the message is specified part of OWAMP-Test, it MUST be
silently ignored. This will ensure data integrity. In
unauthenticated mode, Integrity Zero Padding is nothing more than a
simple check. In authenticated and encrypted modes, however, it
ensures, in the
`Number conjunction with properties of Schedule Slots' field above):

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These are immediately followed by CBC chaining mode, that
everything received before was not tampered with. For this reason,
it is important to check the Integrity Zero Padding: Padding Field as soon as
possible, so that bad data doesn't get propagated.

To each Request-Session message, an OWAMP server MUST respond with an
Accept-Session message:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Unused | Port | Integrity Zero Padding
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All these messages comprise one logical message: the Request-Session
command.

Above, the first octet (1) indicates that this is Request-Session
command.

IPVN is the IP version numbers for Sender and Receiver.
| |
| Integrity Zero Padding (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the case
of IP version number being 4, twelve octets follow the four-octet
IPv4 address stored in Sender Address and Receiver address. These
octets MUST be set to this message, zero by the client and MUST be ignored by the
server. Currently meaningful IPVN values are 4 and 6.

Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client.
The server MUST interpret any non-zero value as 1. If in the value is
1, Accept field means that the server is being asked
willing to configure the corresponding agent
(sender or receiver). In this case, conduct the corresponding Port session. A value
SHOULD be disregarded by the server. At least one of Conf-Sender and
Conf-Receiver MUST be 1. (Both can be set, in which case 1 indicates rejection of
the request. All other values are reserved.

If the server
is being asked to perform rejects a session between two hosts Request-Session command, it can
configure.)

Number of Schedule Slots, as mentioned before, specifies the number
of slot records that go between the two blocks of Integrity Zero
Padding. It is used by SHOULD not close
the sender to determine when to send test
packets (see next section).

Number TCP connection. The client MAY close it if it gets negative
response to Request-Session.

The meaning of Packets is Port in the number response depends on the values of active measurement packets to be
sent during this OWAMP-Test session (note that both server
Conf-Sender and client
can abort Conf-Receiver in the session early). query that solicited the
response. If Conf-Sender both were set, Port field is not unused. If only
Conf-Sender was set, Sender Port is the UDP port to expect OWAMP-Test packets will be sent
from. If only Conf-Receiver is not was set, Receiver Port is the UDP port to send
OWAMP-Test packets are requested to be sent to.

The Sender Address and Receiver Address fields contain respectively
the sender and receiver addresses of the end points of

If only Conf-Sender was set, SID field in the Internet
path over which an OWAMP test session response is requested. unused.
Otherwise, SID is the a unique server-generated session identifier. It
can be used in later sessions as
an argument handle to fetch the results of a session.

SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number
belonging to the generating machine, 8-octet timestamp, and 4-octet
random value. To reduce the probability of collisions, if the
generating machine has any IPv4 addresses (with the exception of
loopback), one of them SHOULD be used for Fetch-Session command. It is meaningful only SID generation, even if
Conf-Receiver all
communication is 0. IPv6-based. If it has no IPv4 addresses at all, the
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
available, it is important that SID be made unpredictable as
knowledge of SID might be used for access control.

3.4. Send Schedules

The sender and the receiver need to both know the same send schedule.
This way, when packets are lost, the SID receiver knows when they were
supposed to be sent. It is always generated by desirable to compress common schedules
and still to be able to use an arbitrary one for the
receiving side. See test sessions.
In many cases, the end schedule will consist of repeated sequences of
packets: this way, the section for information on how sequence performs some test, and the SID is generated.

Padding length test is the
repeated a number of octets to be appended times to normal
OWAMP-Test packet (see more on padding in discussion gather statistics.

To implement this, we have a schedule with a given number of OWAMP-Test).

Start Time is the time when the session is to be started (but not
before Start-Sessions command is issued). This timestamp `slots'.
Each slot has a type and a parameter. Two types are supported:
exponentially distributed pseudo-random quantity (denoted by a code
of 0) and a fixed quantity (denoted by a code of 1). The parameter
is in the
same format expressed as OWAMP-Test timestamps.

Timeout (or a loss threshold) is an interval of timestamp and specifies a time (expressed as interval. For a
timestamp). A packet belonging to the test session that
type 0 slot (exponentially distributed pseudo-random quantity) this
interval is being set
up by the current Request-Session command will be considered lost mean value (or 1/lambda if
it is not received during Timeout seconds after it the distribution density
function is sent.

Type-P Descriptor covers only a subset expressed as lambda*exp(-lambda*x) for positive values of (very large) Type-P space.
If
x). For a type 1 slot, the parameter is the first two bits of Type-P Descriptor are 00, then subsequent 6
bits specify delay itself. The
sender starts with the requested Differentiated Services Codepoint (DSCP)
value beginning of sent OWAMP-Test packets as defined in RFC 2474. If the
first two bits of Type-P descriptor are 01, then subsequent 16 bits
specify schedule, and `executes' the requested Per Hop Behavior Identification Code (PHB ID)
as defined
instructions in RFC 2836.

Therefore, the value slots: for a slot of type 0, wait exponentially
distributed time with mean of all zeros specifies the default best-effort
service.

If Conf-Sender is set, Type-P Descriptor is to be used specified parameter and then send a
test packet (and proceed to configure the sender to next slot); for a slot of type 1,
wait the specified time and send packets according a test packet (and proceed to its value. If Conf-Sender is
not set, Type-P Descriptor the
next slot). The schedule is a declaration of how circular: when there are no more slots,
the sender will be
configured.

If Conf-Sender is set returns to the first slot.

The sender and the server doesn't recognize Type-P
Descriptor, cannot or does not wish receiver must be able to set the corresponding
attributes on OWAMP-Test packets, it SHOULD reject reproducibly execute the session
request. If Conf-Sender
entire schedule (so if a packet is not set, the server SHOULD accept lost, the
session regardless receiver can still
attach a send timestamp to it). Slots of the value type 1 are trivial to
reproducibly execute. To reproducibly execute slots of Type-P Descriptor.

Integrity Zero Padding MUST type 0, we
need to be all zeros able to generate pseudo-random exponentially distributed
quantities in this and all subsequent
messages that use zero padding. The recipient of a message where
zero padding reproducible manner. The way this is not zero MUST reject the message as it accomplished is an
indication
discussed later.

Using this mechanism one can easily specify common testing scenarios.
Some examples include:

+ Poisson stream: a single slot of tampering type 0;

+ Periodic stream: a single slot of type 1;

+ Poisson stream of back-to-back packet pairs: two slots -- type 0
with a non-zero parameter and type 1 with a zero parameter.

Further, a completely arbitrary schedule can be specified (albeit
inefficiently) by making the content number of test packets equal to the message by an
intermediary (or brokenness). If
number of schedule slots. In this case, the message complete schedule is part
transmitted in advance of OWAMP-
Control, the session MUST be terminated an OWAMP-Test session.

3.5. Starting Test Sessions

Having requested one or more test sessions and results invalidated. If received affirmative
Accept-Session responses, an OWAMP client may start the message is part execution of OWAMP-Test, it MUST be silently ignored. This
will ensure data integrity. In unauthenticated mode, Integrity Zero
Padding is nothing more than
the requested test sessions by sending a simple check. In authenticated and
encrypted modes, however, it ensures, in conjunction with properties Start-Sessions message to
the server.

The format of CBC chaining mode, that everything received before was not
tampered with. For this reason, it message is important to check the as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |
+-+-+-+-+-+-+-+-+ |
| Unused (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding Field as soon as possible, so that bad data
doesn't get propagated.

To each Request-Session message, an OWAMP (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The server MUST respond with an
Accept-Session message: Control-Ack message (which SHOULD be
sent as quickly as possible). Control-Ack messages have the following
format:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Unused | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| |
+-+-+-+-+-+-+-+-+ |
| SID (16 Unused (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (12 (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this message, zero in the

If Accept field means that the server is
willing to conduct 1, the session. A value of 1 indicates rejection of Start-Sessions request was rejected; zero means
that the request. command was accepted. All other values are reserved.

If the server rejects a Request-Session command, it SHOULD not close
the TCP connection. The client MAY close it if it gets negative
response to Request-Session. The meaning of Port in the response depends on the values of Conf-
Sender and Conf-Receiver in the query that solicited the response.
If both were set, Port field is unused. If only Conf-Sender was set,
Port is the port to expect OWAMP-Test packets 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.
Otherwise, SID is a unique server-generated session identifier. It
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
belonging to the generating machine, 8-octet timestamp,
server MAY and 4-octet
random value. To reduce the probability of collisions, if client SHOULD close the
generating machine has any IPv4 addresses (with connection in the exception of
loopback), one case of them
a rejection.

The server SHOULD be used for SID generation, even if start all
communication OWAMP-Test streams immediately after it
sends the response or immediately after their specified start times,
whichever is IPv6-based. later. If the client represents a Sender, the client
SHOULD start its OWAMP-Test streams immediately after it has no IPv4 addresses at all, sees the
last 4 octets of an IPv6 address can be used instead. Note that SID
Control-Ack response from the Server (if the Start-Sessions command
was accepted) or immediately after their specified start times,
whichever is always chosen later. See more on OWAMP-Test sender behavior in a
separate section below.

3.6. Stop-Sessions

The Stop-Sessions message may be issued by either the receiver. If truly random values are not
available, it Control-Client
or the Server. The format of this command is important that SID be made unpredictable as
knowledge follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of SID might be used for access control.

5.4. Send Schedules

The sender and the receiver need to both know the same send schedule.
This way, when Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is immediately followed by 0 or more session packets are lost, the receiver knows when they were
supposed to be sent. It sent
descriptions (the number of session packets sent records is desirable to compress common schedules
and still to be able to use an arbitrary one for the test sessions.
In many cases, specified
in the schedule will consist of repeated sequences 'Number of
packets: this way, Sessions' field above):

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Packets Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All these messages comprise one logical message: the sequence performs some test, and Stop-Sessions
command.

Above, the test first octet (3) indicates that this is
repeated a number the Stop-Sessions
command.

Accept values of times to gather statistics.

To implement this, we have a schedule with 1 indicate a given number failure of `slots'.
Each slots has a type and a parameter. Two types some sort. Zero values
indicate normal (but possibly premature) completion. All other
values are supported:
exponentially distributed pseudo-random quantity (denoted by a code
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 reserved.

If Accept had a
type 0 slot (exponentially distributed pseudo-random quantity) this
interval is the mean non-zero value (or 1/lambda (from either party) results of all
OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be
considered invalid, even if the distribution density
function is expressed as lambda*exp(-lambda*x) a Fetch-Session with SID from this
session works for positive values of
x). For a type 1 slot, the parameter is different OWAMP-Control session. If Accept was
not transmitted at all (for whatever reason, including the delay itself. The
sender starts with TCP
connection used for OWAMP-Control breaking), the beginning results of all
OWAMP-Test sessions spawned by this OWAMP-control session MAY be
considered invalid.

Number of Sessions indicates the schedule, and `executes' number of session packets sent
records that immediately follow the
instructions in Stop-Sessions message.

Number of Sessions MUST contain the slots: for a slot number of type 0, wait exponentially
distributed time with mean send sessions started
by the local side of the specified parameter and then send control connection that have not been
previously terminated by a
test packet (and proceed to Stop-Sessions command (i.e., the next slot);
Control-Client MUST account for a slot of type 1,
wait each accepted Request-Session where
Conf-Receiver was set. The Control-Server MUST account for each
accepted Request-Session where Conf-Sender was set). If the
Stop-Sessions message does not account for all the specified time and send a test packet (and proceed sessions
controlled by that side, then it is to be considered invalid and the
connection SHOULD be closed and any results obtained considered
invalid.

Each session packets sent record represents one OWAMP-Test session
and contains the session identifier (SID) and the number of packets
sent in that session. For completed sessions, Session Packets Sent
will equal NumPackets from the
next slot). The schedule is circular: when there are no more slots, Request-Session. Session Packets Sent
MAY be all ones (0xFFFFFFFF); in this case, the sender returns to of the first slot.

The sender and
Stop-Sessions command could not determine the receiver must be able number of packets sent
(perhaps, due to reproducibly execute some internal error such as a process crash); this
special value SHOULD NOT be sent under normal operating conditions.

If the
entire schedule (so OWAMP-Control connection associated with an OWAMP-Test
receiver receives the (0xFFFFFFFF) special value for the Session
Packets Sent, or if a packet the OWAMP-Control connection breaks when the
Stop-Sessions command is lost, sent, the receiver can still
attach a send timestamp to it). Slots of type 1 are trivial to
reproducibly execute. To reproducibly execute slots of type 0, we
need to be able to generate pseudo-random exponentially distributed
quantities in a reproducible manner. The way this is accomplished is
discussed later.

Using this mechanism one can easily specify common testing scenarios:

+ Poisson stream: a single slot of type 0;

+ Periodic stream: a single slot of type 1;

+ Poisson stream of back-to-back packet pairs: two slots -- type 0
with a non-zero parameter and type 1 with a zero parameter.

A MAY not completely arbitrary schedule can be specified (albeit
inefficiently) by making
invalidate the number session results. It MUST discard any records of test lost
packets equal to that follow (in other words, have greater sequence number
than) the last packet that was actually received. This will help
differentiate between packet losses that occurred in the network and
the
number of schedule slots. In this case, sender crashing. When the complete schedule is
transmitted in advance results of such an OWAMP-Test session.

5.5. Starting Test Sessions

Having requested one session
or more test sessions and received affirmative
Accept-Session responses, an OWAMP client may start OWAMP-Test session that was prematurely aborted successfully
(with confirmation) are later fetched using Fetch-Session, the execution
original number of packets MUST be supplied in the requested test sessions by sending a Start-Sessions message to reproduction of
the server.

The format Request-Session command.

If a receiver of this message is as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |
+-+-+-+-+-+-+-+-+ |
| Unused (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The server MUST respond with an Control-Ack OWAMP-Test session learns through OWAMP-Control
Stop-Sessions message (which SHOULD be
sent as quickly as possible). Control-Ack messages have that the following
format:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | |
+-+-+-+-+-+-+-+-+ |
| Unused (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If Accept OWAMP-Test sender's last sequence
number is 1, lower than any sequence number actually received, the Start-Sessions request was rejected; zero means
results of the complete OWAMP-Test session MUST be invalidated.

A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control
Stop-Sessions command, MUST discard any packet records -- including
lost packet records -- with a (computed) send time that falls between
the command was accepted. All other values are reserved. The
server MAY current time minus Timeout and the client SHOULD close current time. This ensures
statistical consistency for the connection measurement of loss and duplicates in
the case event that the Timeout is greater than the time it takes for the
Stop-Sessions command to take place.

To effect complete sessions, each side of
a negative response.

The server the control connection
SHOULD start wait until all OWAMP-Test streams immediately after it
sends Sessions are complete before sending the response or immediately after their specified start times,
whichever
Stop-Sessions message. The completed time of each sessions is later. (Note that a client can effect an immediate
start by specifying in Request-Session
determined as Timeout after the scheduled time for the last sequence
number. Endpoints MAY add a Start Time in small increment to the past.) If computed
completed time for send endpoints to ensure the client represents Stop-Sessions message
reaches the receiver endpoint after Timeout.

To effect a Sender, premature stop of sessions, the client SHOULD start party that initiates this
command MUST stop its OWAMP-
Test OWAMP-Test send streams immediately after it sees to send the Control-Ack response from Session
Packets Sent values before sending this command. That party SHOULD
wait until receiving the Server.

5.6. response Stop-Sessions

The message before
stopping the receiver streams so that it can use the values from the
received Stop-Sessions message may be issued by either the Control-Client
or to validate the Server. data.

3.7. Fetch-Session

The format of this client command is as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 4 | |
+-+-+-+-+-+-+-+-+ | Accept
| Unused (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (8 End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This

Begin Seq is immediately the sequence number of the first requested packet. End
Seq is the sequence number of the last requested packet. If Begin
Seq is all zeros and End Seq is all ones, complete session is said to
be requested.

If a complete session is requested and the session is still in
progress, or has terminated in any way other than normal, the request
to fetch session results MUST be denied. If an incomplete session is
requested, all packets received so far that fall into the requested
range SHOULD be returned. Note that since no commands can be issued
between Start-Sessions and Stop-Sessions, incomplete requests can
only happen on a different OWAMP-Control connection (from the same or
different host as Control-Client).

The server MUST respond with a Control-Ack message. Again, 1 in the
Accept field means rejection of command. Zero means that data will
follow. All other values are reserved.

If Accept was 0, the server then MUST send the OWAMP-Test session
data in question, followed by 0 or more 16 octets of Integrity Zero Padding.

The OWAMP-Test session data consists of the following (concatenated):

+ A reproduction of the Request-Session command that was used to
start the session; it is modified so that actual sender and
receiver port numbers that were used by the OWAMP-Test session packets sent
descriptions (the
always appear in the reproduction.

+ The number of session packets sent packet records is specified that will follow represented as an
unsigned 4-octet integer. This number might be less than the
Number of Packets in the 'Number reproduction of Sessions' field above):

0 1 the Request-Session
command because of a session that ended prematurely; or it might
be greater because of duplicates.

+ 12 octets of Integrity Zero Padding.

+ Zero or more (as specified) packet records.

Each packet record is 25 octets, and includes 4 octets of sequence
number, 8 octets of send timestamp, 2 3 octets of send timestamp error
estimate, 8 octets of receive timestamp, and 2 octets of receive
timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6):

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Packets Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All these messages comprise one logical message: the Stop-Session
command.

Above, the first octet (3) indicates that this is the Stop-Session
command.

Accept values of 1 indicate a failure of some sort. Zero values
indicate normal (but possibly premature) completion. All other
values are reserved.

If Accept had a non-zero value (from either party) results of all
OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be
considered invalid, even if a Fetch-Session with SID from this
session works for a different OWAMP-Control session. If Accept was
not transmitted at all (for whatever reason, including 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Timestamp |
08| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp |
20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+

Packet records are sent out in the TCP
connection used for OWAMP-Control breaking), same order they are made when the
results of all
OWAMP-Test sessions spawned by this OWAMP-control session MAY be
considered invalid.

Number of Sessions indicates the number of session packets sent
records are recorded. Therefore, the data is in
arrival order.

Note that immediately follow lost packets (if any losses were detected during the Stop-Sessions message.

Number of Sessions
OWAMP-Test session) MUST contain appear in the number sequence of send sessions started
by packets. They can
appear either at the local side of point when the control connection that have not been
previously terminated by a Stop-Sessions command. (i.e. The Control-
Client MUST account for each accepted Request-Session where Conf-
Receiver was set. The Control-Server MUST account for each accepted
Request-Session where Conf-Sender loss was set.) If the Stop-Sessions
message does not account for all the send sessions controlled by that
side, then it is to be considered invalid and the connection SHOULD
be closed and detected or at any results obtained considered invalid.

Each session packets sent record represents one OWAMP-Test session
and contains the session identifier (SID) and the number of packets
sent in that session. For completed sessions, Session Packets Sent
will equal NumPackets from the Request-Session. Session Packets Sent
MAY be all ones (0xFFFFFFFF); in this case, later
point. Lost packet records are distinguished as follows:

+ A send timestamp filled with the sender of presumed send time (as computed
by the Stop-
Sessions command could not determine send schedule).

+ A send error estimate filled with Multiplier=1, Scale=64, and S=0
(see the number OWAMP-Test description for definition of packets sent
(perhaps, due to some internal these quantities
and explanation of timestamp format and error such as a process crash); this
special value SHOULD NOT be sent under estimate format).

+ A normal operating conditions.

If receive error estimate as determined by the OWAMP-Control connection associated with an OWAMP-Test
receiver receives error of the (0xFFFFFFFF) special value for
clock being used to declare the Session
Packets Sent, or packet lost (it MUST be declared
lost if it is not received Timeout after the OWAMP-Control connection breaks when presumed send time as
determined by the
Stop-Sessions command receivers clock).

+ A receive timestamp consisting of all zero bits.

+ A TTL value of 255.

The last (possibly full, possibly incomplete) block (16 octets) of
data is sent, the receiver MAY not completely
invalidate padded with zeros if necessary. (These zeros are simple
padding and should be distinguished from the session results. It MUST discard any records 16 octets of lost
packets Integrity
Zero Padding that follow (in other words, have greater sequence number
than) the last packet that was actually received. This will help
differentiate between packet losses that occurred in the network session data and conclude the response
to Fetch-Session.)

4. OWAMP-Test

This section describes OWAMP-Test protocol. It runs over UDP using
sender crashing. When the results of such an and receiver IP and port numbers negotiated during
Request-Session exchange.

As OWAMP-Control, OWAMP-Test session
or an has three modes: unauthenticated,
authenticated, and encrypted. All OWAMP-Test sessions spawned by an
OWAMP-Control session inherit its mode.

OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and
OWAMP-Test receiver can potentially all be different machines. (In a
typical case we expect that was prematurely aborted successfully
(with confirmation) are later fetched using Fetch-Session, the
original number of packets MUST there will be supplied only two machines.)

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 reproduction of sender and the Request-Session command.

If a receiver
to compute the same exact packet sending schedule independently of an
each other. These sending schedules are independent for different
OWAMP-Test session learns through OWAMP-Control
Stop-Sessions message that sessions, even if they are governed by the same
OWAMP-Control session.

Consider any OWAMP-Test sender's last sequence
number session. Once Start-Sessions exchange is lower than any sequence number actually received,
complete, the
results of sender is ready to start sending packets. Under normal
OWAMP use circumstances, the complete OWAMP-Test session MUST be invalidated.

A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control
Stop-Sessions command, MUST discard any packet records -- including
lost time to send the first packet records -- with is in the
near future (perhaps a (computed) fraction of a second away). The sender SHOULD
send time that falls between packets as close as possible to their scheduled time, with the current
following exception: if the scheduled time minus Timeout to send is in the past,
and separated from the current time. 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 ensures
statistical consistency for could happen if a time in the measurement of loss and duplicates
past was specified in the event that Request-Session command, or if the Timeout is greater than
Start-Sessions exchange took unexpectedly long, or if the time it takes for sender
could not start serving the
Stop-Sessions command OWAMP-Test session on time due to take place.

To effect complete sessions, each side
internal scheduling problems of the control connection OS. Packets in the past, but
separated from the present by less than Timeout value, SHOULD wait until all Sessions are complete before sending be sent
as quickly as possible. With normal test rates and timeout values,
the Stop-
Sessions message. The completed time number of each 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 determined
as Timeout after the scheduled time for the last sequence number.
Endpoints MAY add a small increment to actually
sent MUST have the computed completed best possible approximation of its real time
for send endpoints to ensure of
departure as its timestamp (in the Stop-Sessions message reaches packet).

4.1.2. Packet Format and Content

The sender sends the receiver endpoint after Timeout.

To effect a premature stop stream of sessions, the party that initiates this
command MUST stop its OWAMP-Test send streams to send packets with schedule as
specified in the Session
Packets Sent values before sending this Request-Session command. That party The sender SHOULD
wait until receiving the response Stop-Sessions message before
stopping the receiver streams so that it can use set the values from
TTL in IPv4 (or Hop Limit in IPv6) in the
received Stop-Sessions message UDP packet to validate the data.

5.7. Fetch-Session 255. The
format of this client command is as follows: the body of a UDP packet in the stream depends on the mode
being used.

For unauthenticated mode:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | |
+-+-+-+-+-+-+-+-+ Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (7 octets) Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SID (16 octets) |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For authenticated and encrypted modes:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Begin Seq is the sequence number of the first requested packet. End
Seq is the sequence number of the last requested packet. If Begin
Seq is all zeros and End Seq is all ones, complete session is said to
be requested.

The server MUST respond with a Control-Ack message. Again, 1 in the
Accept field means rejection of command. Zero means that data will
follow. All other values are reserved.

If Accept was 0, the server then MUST send the OWAMP-Test session
data in question, followed by 16 octets of Integrity Zero Padding. Padding (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The OWAMP-Test session data consists of the following (concatenated):

+ A reproduction format of the Request-Session command that was used to
start the session; it timestamp is modified so that actual sender and
receiver port numbers that were used by the OWAMP-Test session
always appear same as in the reproduction.

+ The number of packet records that will follow represented [RFC 1305] and is as an
follows: first 32 bits represent the unsigned 4-octet integer. This integer number might be less than the
Number of Packets in the reproduction of
seconds elapsed since 0h on 1 January 1900; next 32 bits represent
the Request-Session
command because fractional part of a session second that ended prematurely; or it might
be greater because of duplicates.

+ 12 octets of Integrity Zero Padding.

+ Zero or more (as specified) packet records.

Each packet record has elapsed since then.

So, Timestamp is 25 octets, and includes represented as follows:

0 1 2 3
0 1 2 3 4 octets of sequence
number, 5 6 7 8 octets of send timestamp, 9 0 1 2 octets of send timestamp error
estimate, 3 4 5 6 7 8 octets of receive timestamp, and 2 octets of receive
timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6): 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Error Estimate specifies the estimate of the error and
synchronization. It has the following format:

0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Timestamp |
08| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12| Send Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16| Receive Timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20| | Receive Error Estimate
|S|Z| Scale |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL Multiplier |
+-+-+-+-+-+-+-+-+

Packet records
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first bit S SHOULD be set if the party generating the timestamp
has a clock that is synchronized to UTC using an external source
(e.g., the bit should be set if GPS hardware is used and it indicates
that it has acquired current position and time or if NTP is used and
it indicates that it has synchronized to an external source, which
includes stratum 0 source, etc.); if there is no notion of external
synchronization for the time source, the bit SHOULD NOT be set. The
next bit has the same semantics as MBZ fields elsewhere: it MUST be
set to zero by the sender and ignored by everyone else. The next six
bits Scale form an unsigned integer; Multiplier is an unsigned
integer as well. They are sent out interpreted as follows: the error estimate
is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation
clarification: 2^Scale is two to the power of Scale.] Multiplier
MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be
considered corrupt and discarded.

Sequence numbers start with 0 and are incremented by 1 for each
subsequent packet.

The minimum data segment length is therefore 14 octets in
unauthenticated mode, and 32 octets in authenticated mode and
encrypted modes.

The OWAMP-Test packet layout is the same order they are made when in authenticated and
encrypted modes. The encryption operations are, however, different.
The difference is that in encrypted mode both the
results of sequence number and
the session timestamp are recorded. Therefore, the encrypted to provide maximum data is in
arrival order.

Note that lost packets (if any losses were detected during the OWAMP-
Test session) MUST appear integrity
protection while in authenticated mode the sequence of packets. They can
appear either at number is
encrypted and the point when timestamp is sent in clear text. Sending the loss was detected or at any later
point. Lost packet records are distinguished as follows:

+ A send
timestamp filled with in clear text in authenticated mode allows to reduce the presumed send
time (as computed
by the send schedule).

+ A send error estimate filled with Multiplier=1, Scale=64, and S=0
(see the OWAMP-Test description for definition of these quantities
and explanation of timestamp format and error estimate format).

+ A receive between a timestamp consisting of all zero bits.

+ A normal receive error estimate as determined is obtained by the error of the
clock being used to declare a sender and the packet lost (it MUST be declared
lost if it is not received Timeout after
shipped out. In encrypted mode, the presumed sender has to fetch the
timestamp, encrypt it, and send time as
determined by it; in authenticated mode, the receivers clock).

+ A TTL value of 255.

The last (possibly full, possibly incomplete) middle
step is removed improving accuracy (the sequence number can be
encrypted before the timestamp is fetched).

In authenticated mode, the first block (16 octets) of
data each packet is
encrypted using AES ECB mode. The key to use is padded with zeros if necessary. (These zeros are simple
padding and should be distinguished from the 16 octets of Integrity
Zero Padding that follow same key as is
used for the corresponding OWAMP-Control session data and conclude the response
to Fetch-Session.)

6. OWAMP-Test

This section describes (where it is used in
a different chaining mode). Electronic Cookbook (ECB) mode does not
involve any actual chaining; this way, lost, duplicated, or reordered
packets do not cause problems with deciphering any packet in an
OWAMP-Test protocol. It runs over UDP session.

In encrypted mode, the first two blocks (32 octets) are encrypted
using
sender and receiver IP and port numbers negotiated during Request-
Session exchange.

As OWAMP-Control, OWAMP-Test has three modes: unauthenticated,
authenticated, and encrypted. All OWAMP-Test sessions spawned by an
OWAMP-Control session inherit its AES CBC mode. The key to use is the same key as is used for
the corresponding OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and session. Each OWAMP-Test receiver can potentially all be different machines. (In packet is
encrypted as a
typical case we expect separate stream, with just one chaining operation;
chaining does not span multiple packets so that there will lost, duplicated, or
reordered packets do not cause problems.

In unauthenticated mode, no encryption is applied.

Packet Padding in OWAMP-Test SHOULD be only two machines.)

6.1. Sender Behavior

The sender sends the receiver pseudo-random (it MUST be
generated independently of any other pseudo-random numbers mentioned
in this document). However, implementations MUST provide a stream
configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros.

The time elapsed between packets with is computed according to the slot
schedule as
specified mentioned 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
format of command description. At
that point we skipped over the body issue of a UDP packet computing exponentially
distributed pseudo-random numbers in a reproducible fashion. It is
discussed later in a separate section.

4.2. Receiver Behavior

Receiver knows when the stream depends on the mode
being used.

For unauthenticated mode:

For authenticated and encrypted modes:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Integrity Zero Padding (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format of the timestamp sender will send packets. The following
parameter is the same defined: Timeout (from Request-Session). Packets that
are delayed by more than Timeout are considered lost (or `as good as in RFC 1305 and
lost'). Note that there is as
follows: first 32 bits represent the unsigned integer number never an actual assurance of loss by the
network: a `lost' packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered
within TTL seconds elapsed since 0h on 1 January 1900; next 32 bits represent or never (with TTL having a maximum value of 255).
To the fractional part best of the authors' knowledge, this requirement was never
actually implemented (and of course only a second complete and universal
implementation would ensure that has elapsed since then.

So, Timestamp is represented as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part packets don't travel for longer than
TTL seconds). In fact, in IPv6 the name of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part this field has actually
been changed to Hop Limit. Further, IPv4 specification makes no
claims about the time it takes the packet to traverse the last link
of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the path.

The Error Estimate specifies choice of a reasonable value of Timeout is a problem faced by a
user of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications (such as
interactive `one-way ping') might wish to obtain the estimate data faster than
that.

As packets are received,

+ Timestamp the received packet.

+ In authenticated or encrypted mode, decrypt first block (16
octets) of packet body.

+ Store the error packet sequence number, send time, receive time, and
synchronization. It has the following format:

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first bit S SHOULD be set if
TTL for IPv4 (or Hop Limit for IPv6) from the party generating packet IP header for
the timestamp
has a clock that is synchronized results to UTC using an external source
(e.g., the bit should be set if GPS hardware is used and it indicates
that it has acquired current position and transferred.

+ Packets not received within the Timeout are considered lost. They
are recorded with their true seqno, presumed send time, receive
time or if NTP is used consisting of a string of zero bits, and
it indicates that it has synchronized to an external source, which
includes stratum 0 source, etc.); if there is no notion TTL (or Hop Limit)
of external
synchronization for 255.

Implementations SHOULD fetch the time source, TTL/Hop Limit value from the bit SHOULD NOT be set. The
next bit has IP
header of the same semantics as MBZ fields elsewhere: packet. If an implementation does not fetch the actual
TTL value (the only good reason to not do so is inability to access
the TTL field of arriving packets), it MUST be
set to zero by record the sender and ignored by everyone else. The next six
bits Scale form an unsigned integer; Multiplier is an unsigned
integer TTL value as well. They
255.

Packets that are interpreted actually received are recorded in the order of
arrival. Lost packet records serve as follows: indications of the error estimate
is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation
clarification: 2^Scale is two send times
of lost packets. They SHOULD be placed either at the point where the
receiver learns about the loss or at any later point; in particular,
one MAY place all the records that correspond to lost packets at the power of Scale.] Multiplier
very end.

Packets that have send time in the future MUST NOT be set recorded normally,
without changing their send timestamp, unless they have to zero. If Multiplier is zero, the packet SHOULD be
considered corrupt and
discarded.

Sequence numbers start with 0 and are incremented (Send timestamps in the future would normally indicate
clocks that differ by 1 for each
subsequent packet.

The minimum more than the delay. Some data segment length is therefore 14 octets in
unauthenticated mode, and 32 octets in authenticated mode and
encrypted modes.

The OWAMP-Test packet layout is -- such as
jitter -- can be extracted even without knowledge of time difference.
For other kinds of data, the same in authenticated and
encrypted modes. The encryption operations are, however, different.
The difference adjustment is that in encrypted mode both best handled by the data
consumer on the basis of the complete information in a measurement
session as well as possibly external data.)
Packets with a sequence number and
the timestamp that was already observed (duplicate
packets) MUST be recorded normally. (Duplicate packets are encrypted sometimes
introduced by IP networks. The protocol has to provide maximum data integrity
protection while in authenticated mode be able to measure
duplication.)

If any of the sequence number following is
encrypted and true, the packet MUST be discarded:

+ Send timestamp is sent more than Timeout in clear text. Sending the
timestamp in clear text past or in authenticated mode allows to reduce the
time between a future.

+ Send timestamp is obtained differs by a sender and more than Timeout from the time when the
packet is
shipped out. should have been sent according to its seqno.

+ In authenticated or encrypted mode, any of the sender has to fetch bits of zero
padding inside the
timestamp, encrypt it, and send it; first 16 octets of packet body is non-zero.

5. Computing Exponentially Distributed Pseudo-Random Numbers

Here we describe the way exponential random quantities used in authenticated mode, the middle
step
protocol are generated. While there is removed improving accuracy (the sequence a fair number can be
encrypted before of algorithms
for generating exponential random variables, most of them rely on
having logarithmic function as a primitive, resulting in potentially
different values, depending on the timestamp particular implementation of the
math library. We use algorithm 3.4.1.S in [KNUTH], which is fetched).

In authenticated mode, free
of the above mentioned problem, and guarantees the same output on any
implementation. The algorithm belongs to the 'ziggurat' family
developed in the 1970s by G.Marsaglia, M.Sibuya and J.H.Ahrens
[ZIGG]. It replaces the use of logarithmic function by clever bit
manipulation, still producing the first block (16 octets) exponential variates on output.

5.1. High-Level Description of each packet is
encrypted using AES ECB mode. The key to use is the same key as is
used for Algorithm

For ease of exposition, the corresponding OWAMP-Control session (where it algorithm is used in
a different chaining mode). Electronic Cookbook (ECB) mode does not
involve any actual chaining; this way, lost, duplicated, or reordered
packets do not cause problems first described with deciphering any packet all
arithmetic operations being interpreted in an
OWAMP-Test session.

In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The key to use is their natural sense.
Later, exact details on data types, arithmetic, and generation of the same key as is
uniform random variates used for by the corresponding OWAMP-Control session. Each OWAMP-Test packet algorithm are given. It is
encrypted as an
almost verbatim quotation from [KNUTH], p.133.

Algorithm S: Given a separate stream, real positive number 'mu', produce an
exponential random variate with just one chaining operation;
chaining does not span multiple packets so that lost, duplicated, or
reordered packets do not cause problems.

In unauthenticated mode, no encryption is applied.

Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers mentioned mean 'mu'.

First, the constants

Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11

are computed in this document). However, implementations MUST provide a
configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros. advance. The time elapsed between packets exact values which MUST be used by all
implementations are given in the reference code (see Appendix A).
This is computed according necessary to the slot
schedule as mentioned in Request-Session command description. At insure that point we skipped over exactly the issue of computing exponentially
distributed same pseudo-random numbers in
sequences are produced by all implementations.

S1. [Get U and shift.] Generate a reproducible fashion.

7. Receiver Behavior

Receiver knows when 32-bit uniform random binary
fraction

U = (.b0 b1 b2 ... b31) [note the sender will send packets. The following
parameter decimal point]

Locate the first zero bit b_j, and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)

NOTE: in the rare case that the zero has not been found it is defined: Timeout (from Request-Session). Packets
prescribed that
are delayed by more than Timeout are considered lost (or `as good the algorithm return (mu*32*ln2).

S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and
terminate the algorithm. (Note that Q[1] = ln2.)

S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k
new uniform random binary fractions U1,...,Uk and set V <-
min(U1,...,Uk).

S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.

5.2. Data Types, Representation and Arithmetic

The high-level algorithm operates on real numbers -- typically
represented as
lost'). Note floating point numbers. This specification prescribes
that there is never an actual assurance of loss unsigned 64-bit integers be used instead.

u_int64_t integers are interpreted as real numbers by placing the
decimal point after the first 32 bits. In other words, conceptually
the interpretation is given by the
network: map:

u_int64_t u;

u |--> (double)u / (2**32)

The algorithm produces a `lost' packet might still sequence of such u_int64_t integers which is
guaranteed to be delivered at the same on any time. The
original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value implementation. Any further
interpretation (such as given by (1)) is done by the application, and
is not part of 255).
To this specification.

We specify that the best u_int64_t representations of the authors' knowledge, this requirement was never
actually implemented (and first 11 values
of course only a complete and universal
implementation would ensure that packets don't travel the Q array in the high-level algorithm be as follows:

#1 0xB17217F8,
#2 0xEEF193F7,
#3 0xFD271862,
#4 0xFF9D6DD0,
#5 0xFFF4CFD0,
#6 0xFFFEE819,
#7 0xFFFFE7FF,
#8 0xFFFFFE2B,
#9 0xFFFFFFE0,
#10 0xFFFFFFFE,
#11 0xFFFFFFFF

For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32)
= 0.693147180601954; for longer than
TTL seconds). In fact, j > 11, Q[j] is 0xFFFFFFFF

Small integer 'j' in IPv6 the name high-level algorithm is represented as
u_int64_t value j * (2**32);

Operation of this field has actually
been changed to Hop Limit. Further, IPv4 specification makes no
claims about the time it takes the packet to traverse addition is done as usual on u_int64_t numbers; however,
the last link operation of multiplication in the path. high-level algorithm should be
replaced by

(u, v) |---> (u * v) >> 32

Implementations MUST compute (u * v) exactly. For example, a
fragment of unsigned 128-bit arithmetic can be implemented for this
purpose (see sample implementation below).

5.3. Uniform Random Quantities

The choice of a reasonable value of Timeout is a problem faced by procedure for obtaining a
user sequence of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications 32-bit random numbers (such
as
interactive `one-way ping') might wish to obtain the data faster than
that.

As packets are received,

+ Timestamp 'U' in algorithm S) relies on using AES encryption in counter
mode. To describe the received packet.

+ In authenticated or encrypted mode, decrypt first block (16
octets) exact working of packet body.

+ Store the packet sequence number, send time, receive time, and the
TTL for IPv4 (or Hop Limit for IPv6) algorithm we introduce two
primitives from the packet IP header for
the results Rijndael. Their prototypes and specification are
given below, and they are assumed to be transferred.

+ Packets not received within provided by the Timeout are considered lost. They
are recorded with their true seqno, presumed send time, receive
time consisting of supporting
Rijndael implementation, such as [RIJN].

+ This function initializes a string of zero bits, and TTL (or Hop Limit)
of 255.

Implementations SHOULD fetch the TTL/Hop Limit value Rijndael key with bytes from 'seed'

void KeyInit(unsigned char seed[16]);

+ This function encrypts the IP
header of 16-octet block 'inblock' with the packet. If 'key'
returning a 16-octet encrypted block. Here 'keyInstance' is an implementation does not fetch
opaque type used to represent Rijndael keys.

void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
Algorithm Unif: given a 16-octet quantity seed, produce a sequence of
unsigned 32-bit pseudo-random uniformly distributed integers. In
OWAMP, the actual
TTL value (the only good reason to not do so is inability to access SID (session ID) from Control protocol plays the TTL field role of arriving packets), it MUST record
seed.

U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an
unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need
more random bytes?] Set i <- c mod 4. If (i == 0) set s <-
BlockEncrypt(key, c)

U3. [Increment the TTL value counter as
255.

Packets that are actually received are recorded in unsigned 16-octet quantity] c <- c + 1

U4. [Do output] Output the order i_th quartet of
arrival. Lost packet records serve octets from s starting
from high-order octets, converted to native byte order and
represented as indications of the send times
of lost packets. They SHOULD be placed either at the point where the
receiver learns about the loss or at any later point; OWPNum64 value (as in particular,
one MAY place all the records that correspond 3.b).

U5. [Loop] Go to lost packets at the
very end.

Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have step U2.

6. Security Considerations

6.1. Introduction

The goal of authenticated mode to be
discarded. (Send timestamps in the future would normally indicate
clocks that differ let one passphrase-protect service
provided by more than the delay. Some data -- such as
jitter -- a particular OWAMP-Control server. One can be extracted even without knowledge of time difference.
For other kinds imagine a
variety of data, the adjustment circumstances where this could be useful. Authenticated
mode is best handled by the data
consumer on the basis designed to prohibit theft of the complete information in a measurement
session as well as possibly external data.)
Packets service.

Additional design objective of authenticated mode was to make it
impossible for an attacker who cannot read traffic between OWAMP-Test
sender and receiver to tamper with test results in a sequence number fashion that was already observed (duplicate
packets) MUST be recorded normally. (Duplicate packets are sometimes
introduced by IP networks.
affects the measurements, but not other traffic.

The protocol has to be able to measure
duplication.)

If any goal of the following is true, the packet MUST be discarded:

+ Send timestamp encrypted mode is more than Timeout quite different: To make it hard for a
party in the past or in middle of the future.

+ Send timestamp differs by more network to make results look `better' than Timeout from the time when the
packet
they should have been sent according be. This is especially true if one of client and server
doesn't coincide with neither sender nor receiver.

Encryption of OWAMP-Control using AES CBC mode with blocks of zeros
after each message aims to its seqno.

+ In authenticated or encrypted mode, any achieve two goals: (i) to provide secrecy
of the bits exchange; (ii) to provide authentication of zero
padding inside the first 16 octets each message.

6.2. Preventing Third-Party Denial of packet body is non-zero.

8. Computing Exponentially Distributed Pseudo-Random Numbers

Here we describe Service

OWAMP-Test sessions directed at an unsuspecting party could be used
for denial of service (DoS) attacks. In unauthenticated mode servers
should limits receivers to hosts they control or to the way exponential random quantities OWAMP-Control
client.

6.3. Covert Information Channels

OWAMP-Test sessions could be used in the
protocol as covert channels of information.
Environments that are generated. While there worried about covert channels should take this
into consideration.

6.4. Requirement to Include AES in Implementations

Notice that AES in counter mode is a fair used for pseudo-random number
generation, so implementation of algorithms
for generating exponential random variables, AES MUST be included even in a
server that only supports unauthenticated mode.

6.5. Resource Use Limitations

An OWAMP server can consume resources of various kinds. The two most
important kinds of them rely on
having logarithmic function as a primitive, resulting in potentially
different values, depending on the particular resources are network capacity and memory (primary
or secondary) for storing test results.

Any implementation of OWAMP server MUST include technical mechanisms
to limit the
math library. We use algorithm 3.4.1.S in [KNUTH], which is free of the above mentioned problem, network capacity and guarantees the same output on any
implementation. The algorithm belongs to the 'ziggurat' family
developed in memory. Mechanisms for
managing the 1970s resources consumed by G.Marsaglia, M.Sibuya unauthenticated users and J.H.Ahrens
[ZIGG]. It replaces users
authenticated with a username and passphrase SHOULD be separate. The
default configuration of an implementation MUST enable these
mechanisms and set the resource use of logarithmic function by clever bit
manipulation, still producing limits to conservatively low
values.

One way to design the exponential variates on output.

8.1. High-Level Description resource limitation mechanisms is as follows:
assign each session to a user class. User classes are partially
ordered with ``includes'' relation, with one class (``all users'')
that is always present and that includes any other class. The
assignment of a session to a user class can be based on the Algorithm

For ease presence
of exposition, the algorithm is first described with all
arithmetic operations being interpreted in their natural sense.
Later, exact details on data types, arithmetic, and generation authentication of the
uniform random variates used by session, the algorithm are given. It is an
almost verbatim quotation from [KNUTH], p.133.

Algorithm S: Given user name, IP address range,
time of day, and, perhaps, other factors. Each user class would have
a real positive number 'mu', produce an
exponential random variate limit for usage of network capacity (specified in units of
bit/second) and memory for storing test results (specified in units
of octets). Along with mean 'mu'.

First, the constants

Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11

are computed in advance. The exact values which MUST limits for resource use, current use
would be used tracked by all
implementations are given in the reference code (see Appendix). This server. When a session is necessary to insure that exactly the same pseudo-random sequences
are produced requested by all implementations.

S1. [Get U and shift.] Generate a 32-bit uniform random binary
fraction

U = (.b0 b1 b2 ... b31) [note the decimal point]

Locate the first zero bit b_j, and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)

NOTE:
user in a specific user class, the rare case that the zero has not been found it is
prescribed that the algorithm return (mu*32*ln2).

S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and
terminate resources needed for this session
are computed: the algorithm. (Note that Q[1] = ln2.)

S3. [Minimize.] Find average network capacity use (based on the least k >= 2 such that U < Q[k]. Generate k
new uniform random binary fractions U1,...,Uk sending
schedule) and set V <-
min(U1,...,Uk).

S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.

8.2. Data Types, Representation and Arithmetic

The high-level algorithm operates maximum memory use (based on real numbers the number of packets
and number of octets each packet would need to be stored internally
-- typically
represented as floating point numbers. This specification prescribes note that unsigned 64-bit integers be used instead.

u_int64_t integers outgoing sessions would not require any memory use).
These resource use numbers are interpreted as real added to the current resource use
numbers by placing for the
decimal point after given user class; if such addition would take the first 32 bits. In other words, conceptually
resource use outside of the limits for the interpretation is given user class, the
session is rejected. When resources are reclaimed, corresponding
measures are subtracted from the current use. Network capacity is
reclaimed as soon as the session ends. Memory is reclaimed when the
data is deleted. For unauthenticated sessions, memory consumed by an
OWAMP-Test session SHOULD be reclaimed after the map:

u_int64_t u;

u |--> (double)u / (2**32)

The algorithm produces a sequence of such u_int64_t integers which OWAMP-Control
connection that initiated the session is
guaranteed closed (gracefully or
otherwise). For authenticated sessions, the administrator who
configures the service should be able to decide the exact policy, but
useful policy mechanisms that MAY be implemented are the ability to be
automatically reclaim memory when the same on any implementation. Any further
interpretation (such as given by (1)) data is done by the application, retrieved and
is not part of this specification.

We specify that the u_int64_t representations
ability to reclaim memory after a certain configurable (based on user
class) period of time passes after the first 11 values OWAMP-Test session terminates.

6.6. Use of the Q array Cryptographic Primitives in the high-level algorithm be as follows:

#1 0xB17217F8,
#2 0xEEF193F7,
#3 0xFD271862,
#4 0xFF9D6DD0,
#5 0xFFF4CFD0,
#6 0xFFFEE819,
#7 0xFFFFE7FF,
#8 0xFFFFFE2B,
#9 0xFFFFFFE0,
#10 0xFFFFFFFE,
#11 0xFFFFFFFF

For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32)
= 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF

Small integer 'j' OWAMP

At an early stage in designing the high-level algorithm is represented protocol, we considered using TLS
and IPsec as
u_int64_t value j * (2**32);

Operation cryptographic security mechanisms for OWAMP. The
disadvantages of addition is done those are as usual on u_int64_t numbers; however,
the operation of multiplication in the high-level algorithm should follows (not an exhaustive list):

Regarding TLS:

+ While TLS could be
replaced by

(u, v) |---> (u * v) >> 32

Implementations MUST compute (u * v) exactly. For example, a
fragment of unsigned 128-bit arithmetic can 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 implemented for this
purpose (see sample implementation below).

8.3. Uniform Random Quantities

The procedure for obtaining a sequence
(optionally) encrypted and authenticated while retaining
individual usability. Stream-based TLS is not conducive of 32-bit random numbers (such
as 'U' this.

+ Dealing with streams, does not authenticate individual messages
(even in algorithm S) relies on 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 AES encryption in counter
mode. To describe the exact working message. The solution
would thus lose some of its appeal (``just use TLS''); it would
also be much more difficult to evaluate the algorithm we introduce two
primitives from Rijndael. Their prototypes security of this
scheme with the various modes and specification are
given below, 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 they are assumed would need to be provided
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 supporting
Rijndael implementation, such as [RIJN].

+ This function initializes a Rijndael key with bytes from 'seed'

void KeyInit(unsigned char seed[16]); result (an unsigned integer) would be
quite large.

+ This function encrypts Dependent on the 16-octet block 'inblock' mode of use, one can end up with the 'key'
returning a 16-octet encrypted block. Here 'keyInstance' requirement
for certificates for all users and a PKI. Even if one is an
opaque type used to represent Rijndael keys.

void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
Algorithm Unif: given
accept that PKI is desirable, there just isn't a 16-octet quantity seed, produce usable one today.

+ TLS requires a sequence fairly large implementation. OpenSSL, for example,
is larger than our implementation of
unsigned 32-bit pseudo-random uniformly distributed integers. In
OWAMP, the SID (session ID) from Control protocol plays the role 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
seed.

U3. [Increment the counter a number of different
platforms as unsigned 16-octet quantity] c <- c possible.

+ 1

U4. [Do output] Output The deployment problems of a protocol dependent on IPsec would be
especially acute in the i_th quartet case of octets from s starting lightweight embedded devices.
Ethernet switches, DSL ``modems,'' and other such devices mostly
do not support IPsec.

+ The API for manipulation IPsec from high-order octets, converted an application is currently
poorly understood. Writing a program that needs to native byte order encrypt some
packets, authenticate some packets, and
represented as OWPNum64 value (as leave some open---for the
same destination---would become more of an exercise in 3.b).

U5. [Loop] Go IPsec
rather than IP measurement.

For the enumerated reasons, we decided to step U2.

9. Security Considerations 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 goal protocol makes use of authenticated mode the MD5 hash function to let one passphrase-protect service
provided by convert a particular OWAMP-Control server. One can imagine
user-supplied passphrase into a
variety of circumstances where this could key that will be useful. Authenticated
mode is designed used to prohibit theft encrypt a
short piece of service.

Additional design objective random data (the session key).

In this document we use cryptographic terminology of authenticated mode was to make it
impossible for an attacker who cannot read traffic between OWAMP-Test
sender [MENEZES].

It has long been suspected, and receiver to tamper with test results in a fashion has been conclusively shown recently
that
affects the measurements, but 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 traffic. design goals of MD5, namely preimage
resistance and 2nd preimage resistance.

OWAMP does not rely on any of these properties.

The goal properties of encrypted mode is quite different: To make it hard for MD5 that are necessary are as follows: (1) it's a
party
function that maps arbitrary length inputs into 128-bit outputs
[fixed-length hash function], (2) a change in the middle any bit of the network to make input
usually results look `better' than
they should be. This is especially true if one in a change of client and server
doesn't coincide with neither sender nor receiver.

Encryption a few bits of OWAMP-Control using AES CBC mode with blocks output [weakened
avalanche property], (3) many 128-bit strings have preimages [almost
surjective], and (4) the visible special structure of zeros
natural-language text possibly present in the passphrase is concealed
after each message aims 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 achieve two goals: (i) 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 provide secrecy use it because of exchange; (ii) to provide authentication lack of each message.

OWAMP-Test sessions directed at
well-documented 128-bit checksums; this specification would incur an unsuspecting party could be used
for denial of service (DoS) attacks. In unauthenticated mode servers
should limits receivers to hosts they control or
unnecessary burden precisely defining one, providing test vectors,
etc., with no advantage over MD5. Option 2, SHA-1, belongs to the OWAMP-Control
client.

OWAMP-Test sessions could
MD4 family that appears to be used as covert channels under suspicion in light of information.
Environments that are worried about covert channels should take this
into consideration.

Notice recent
developments. To avoid creating an impression that AES any potential
future changes in counter mode is used for pseudo-random number
generation, so implementation the status of AES MUST be included even SHA-1 can affect the status of OWAMP
we chose not to use it. Option 3 would result in a
server that only supports unauthenticated mode.

9.1. An OWAMP server can consume resources hash function
that, with the current state of various kinds. The two
most important kinds knowledge, would probably be one of resources are network capacity and memory
(primary or secondary)
the most cryptographically sound. Our requirements 1-4 from the
preceding paragraph, however, do not call for storing test results.

Any implementation of OWAMP server MUST include technical mechanisms a cryptographically
sound hash function. Just as with CRC-128, this specification would
need to limit define the use of network capacity hash function and memory. Mechanisms 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
managing this application, as the resources consumed by unauthenticated users and users
authenticated with hash is computed on a username and passphrase SHOULD be separate.
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
default configuration Use of an implementation MUST enable these
mechanisms and set 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 resource use limits to conservatively low
values.

One way to design first
block, it is unimportant for the resource limitation mechanisms purposes of CBC-MAC authentication
(it should also be noted that with its 128-bit block size, AES is as follows:
assign each session
more resistant to a user class. User classes are partially
ordered with ``includes'' relation, codebook attacks than ciphers with one class (``all users'')
that shorter blocks;
we use random IV anyway).

Integrity zero padding, when decrypted, MUST be zero. It is always present and that includes any other class. crucial
to check for this before using the message, otherwise existential
forgery becomes possible. The
assignment of a session complete message for which integrity
zero padding is decrypted to a user class can non-zero MUST be based on the presence
of authentication discarded (for both
short messages consisting of a few blocks and potentially long
messages, such as a response to the session, the user name, IP address range,
time of day, and, perhaps, other factors. Each user class would Fetch-Session command).

Since OWAMP messages can have
a limit for usage different numbers of network capacity (specified blocks,
existential forgery attack described in units example 9.62 of
bit/second) and memory for storing test results (specified in units [MENEZES]
becomes a concern. To prevent it (and to simplify implementation),
the length of octets). Along with any message becomes known after decrypting the limits for resource use, current use
would be tracked first
block of it.

A special case is the first (fixed-length) message sent by the server. When a session
client. There, the token is requested by a
user concatenation of the 128-bit challenge
(transmitted by the server in a specific user class, the resources needed for this clear) and a 128-bit session
are computed: key
(generated randomly by the average network capacity use (based on client, encrypted with AES-CBC with IV=0.
Since IV=0, the sending
schedule) and challenge (a single cipher block) is simply encrypted
with the maximum memory use (based secret key. Therefore, we rely on the number of packets
and number resistance of octets each packet would need AES to
chosen plaintext attacks (as the challenge could be stored internally
-- note substituted by an
attacker). It should be noted that outgoing sessions would not require any memory use).
These resource use numbers are added to the current resource use
numbers for number of blocks of chosen
plaintext an attacker can have encrypted with the given user class; if such addition would take secret key is
limited by the
resource use outside number of sessions the limits for client wants to initiate. An
attacker who knows the given user class, encryption of a server's challenge can produce
an existential forgery of the session is rejected. When resources are reclaimed, corresponding
measures are subtracted from the current use. Network capacity is
reclaimed as soon as key and thus disrupt the
session; however, any attacker can disrupt a session ends. Memory by corrupting
the protocol messages in an arbitrary fashion, therefore no new
threat is reclaimed when created here; nevertheless, we require that the
data 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 deleted. For unauthenticated sessions, memory consumed by enough even for an
OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control
connection implausibly
busy server that initiated 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 is closed (gracefully or
otherwise). For authenticated sessions, key by modifying the administrator who
configures second half of the service should be able to decide
client's token while leaving the exact policy, but
useful policy mechanisms that MAY first part intact. This forgery,
however, would be implemented are immediately discovered by the ability to
automatically reclaim memory client when the data is retrieved and the
ability to reclaim memory after a certain configurable (based
integrity zero padding on user
class) period the server's next message (acceptance or
rejection of time passes after the OWAMP-Test session terminates.

10. connection) does not verify.

7. IANA Considerations

IANA is requested to allocate a well-known TCP port number for OWAMP-
Control the
OWAMP-Control part of the OWAMP protocol.

11.

8. Internationalization Considerations

The protocol does not carry any information in a natural language.

12. Appendix A: Sample Implementation protocol does not carry any information in a natural language.

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 Exponential Deviate Computation this appendix only serves for
illustrative purposes.

/*
** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization).
** 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 arithmetic we described.

** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example)
** unsigned char seed[16];

** OWPrand_context next;

** (initialize state)
** OWPrand_context_init(&next, seed);

** (generate a sequence of exponential variates)
** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/

#include <stdlib.h>

typedef u_int64_t u_int64_t;

/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12

#define BIT31 0x80000000UL /* see See if first bit in the lower
32 bits is zero zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)

#define EXP2POW32 0x100000000ULL

typedef struct OWPrand_context {
unsigned char counter[16]; /* 16-octet counter Counter (network byte order) order). */
keyInstance key; /* key used Key to encrypt the counter. */
unsigned char out[16]; /* the The encrypted block is kept there. block. */
} OWPrand_context;

/*
** The array has been computed according to the formula:
**
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
**
** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation
** produce the same sequences.
*/
static u_int64_t Q[K] = {
0, /* Placeholder - so array indices start from 1. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};

/* this element represents ln2 */
#define LN2 Q[1]

/*
** Convert an unsigned 32-bit integer into a u_int64_t number.. number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}

/*
** Arithmetic functions on u_int64_t numbers.
*/

/*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}

/*
** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH] [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];

int i, j;
u_int64_t k, t, ret;

xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);

for (j = 0; j < 4; j++)
w[j] = 0;

for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}

ret = w[2];
ret <<= 32;
return w[1] + ret;
}

/*
** Seed the random number generator using a 16-byte quantity 'seed'
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/

void
OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
{
int i;

/* Initialize the key */
rijndaelKeyInit(next->key, seed);

/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}

/*
** Random number generating functions.
*/

/*
** 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
** U2-U4 of the algorithm Unif.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;

/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);

/* Step U3. Increment next.counter as a 16-octet single
quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--)
if (++next->counter[j])
break;

/* Step U4. Do output. The last 4 bytes of ret now contain the
random integer in network byte order */
buf = &next->out[4*i];
for(j=0;j<4;j++){
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}

/*
** Generate a mean 1 an exponential deviate. deviate with mean 1.
*/
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;

/* Step S1. Get U and shift */
U = OWPunif_rand64(next);

while ((U & BIT31) && (j < 32)){ 32)) { /* shift Shift until find first '0' 0. */
U <<= 1;
j++;
}
/* remove Remove the '0' itself 0 itself. */
U <<= 1;

U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);

/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);

/* Step S3. Minimize. */
for (k = 2; k < K; k++)
if (U < Q[k])
break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++){ i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}

/* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}

13.

10. Appendix B: Test Vectors for Exponential Deviates

It is important that the test schedules generated by different
implementations from identical inputs be identical. The non-trivial
part is the generation of pseudo-random exponentially distributed
deviates. To aid implementors in verifying interoperability, several
test vectors are provided. For each of the four given 128-bit values
of SID represented as hexadecimal numbers, 1,000,000 exponentially
distributed 64-bit deviates are generated as described above. As
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
implementation MUST produce exactly these hexadecimal numbers. To
aid in the verification of the conversion of these numbers to values
of delay in seconds, approximate values are given (assuming
lambda=1). An implementation SHOULD produce delay values in seconds
that are close to the ones given below.

SID = 0x2872979303ab47eeac028dab3829dab2
SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)

SID = 0x0102030405060708090a0b0c0d0e0f00
SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)

SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)

SID = 0xfeed0feed1feed2feed3feed4feed5ab
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)

14.

11. Normative References

[AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/

[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
Implementation and Analysis', RFC 1305, March 1992.

[RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321,
April 1992.

[RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3',
RFC 2026, October 1996.

[RFC2119] S. Bradner, `Key words for use in RFCs to Indicate
Requirement Levels', RFC 2119, March 1997.

[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for
IP Performance Metrics' RFC 2330, May 1998.

[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers', RFC 2474, December 1998.

[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay
Metric for IPPM', RFC 2679, September 1999.

[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet
Loss Metric for IPPM', RFC 2680, September 1999.

[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior
Identification Codes', RFC 2836, May 2000.

15.

12. Informative References

[ZIGG] G. Marsaglia, M. Sibuya Sibuya, and J.H. J. H. Ahrens, Communications of
ACM, 15 (1972), 876-877 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
edition, 1998 1998.

[RIJN] Reference ANSI C implementation of Rijndael
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip

[RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/.

[RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay
Measurements Using Test-Traffic', Spring 1998 Dutch Unix User
Group Meeting, http://www.ripe.net/test-
traffic/Talks/9805_nluug.ps.gz.
http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz.

[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.

[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An
Infrastructure for Network Performance Measurements',
Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm

16.

13. Authors' Addresses

Stanislav Shalunov <shalunov@internet2.edu>
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>
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Email: ben@internet2.edu
SIP: ben@internet2.edu

Anatoly Karp <ankarp@yahoo.com>
4710 Regent St Apt 81B
Madison, WI 53705
Telephone: +1-608-347-6255
Email: ankarp@charter.net
Jeff W. Boote <boote@internet2.edu>
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Email: boote@internet2.edu
SIP: boote@internet2.edu

Matthew J. Zekauskas <matt@internet2.edu>
Internet2
3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108
Email: matt@internet2.edu

Intellectual Property

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: January February 2005