draft-ietf-ippm-owdp-04.txt   draft-ietf-ippm-owdp-05.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Expiration Date: December 2002 Benjamin Teitelbaum Expiration Date: February 2003 Benjamin Teitelbaum
Advanced Network & Services and Internet2 Advanced Network & Services and Internet2
Matthew J. Zekauskas Matthew J. Zekauskas
Advanced Network & Services Advanced Network & Services
June 2002 August 2002
A One-way Active Measurement Protocol A One-way Active Measurement Protocol
<draft-ietf-ippm-owdp-04.txt> <draft-ietf-ippm-owdp-05.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
Security features include optional authentication and/or encryption Security features include optional authentication and/or encryption
of control and test messages. These features may be useful to of control and test messages. These features may be useful to
prevent unauthorized access to results or man-in-the-middle attackers prevent unauthorized access to results or man-in-the-middle attackers
who attempt to provide special treatment to OWAMP test streams or who who attempt to provide special treatment to OWAMP test streams or who
attempt to modify sender-generated timestamps to falsify test attempt to modify sender-generated timestamps to falsify test
results. results.
2.1. Relationship of Test and Control Protocols 2.1. Relationship of Test and Control Protocols
OWAMP actually consists of two inter-related protocols: OWAMP-Control OWAMP actually consists of two inter-related protocols: OWAMP-Control
and OWAMP-Test. OWAMP-Control is used to initiate, start, stop and and OWAMP-Test. OWAMP-Control is used to initiate, start and stop
retrieve test sessions, while OWAMP-Test is used to exchange test test sessions and fetch their results, while OWAMP-Test is used to
packets between two measurement nodes. exchange test packets between two measurement nodes.
Although OWAMP-Test may be used in conjunction with a control Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, the authors have deliberately protocol other than OWAMP-Control, the authors have deliberately
chosen to include both protocols in the same draft to encourage the chosen to include both protocols in the same draft to encourage the
implementation and deployment of OWAMP-Control as a common implementation and deployment of OWAMP-Control as a common
denominator control protocol for one-way active measurements. Having denominator control protocol for one-way active measurements. Having
a complete and open one-way active measurement solution that is a complete and open one-way active measurement solution that is
simple to implement and deploy is crucial to assuring a future in simple to implement and deploy is crucial to assuring a future in
which inter-domain one-way active measurement could become as which inter-domain one-way active measurement could become as
commonplace as ping. We neither anticipate nor recommend that OWAMP- commonplace as ping. We neither anticipate nor recommend that OWAMP-
Control form the foundation of a general purpose extensible Control form the foundation of a general purpose extensible
measurement and monitoring control protocol. measurement and monitoring control protocol.
OWAMP-Control is designed to support the negotiation of one-way OWAMP-Control is designed to support the negotiation of one-way
active measurement sessions and results retrieval in a active measurement sessions and results retrieval in a
straightforward manner. At session initiation, there is a negotiation straightforward manner. At session initiation, there is a negotiation
of sender and receiver addresses and port numbers, session start of sender and receiver addresses and port numbers, session start
time, session length, test packet size, the mean Poisson sampling time, session length, test packet size, the mean Poisson sampling
interval for the test stream, and some attributes of the very general interval for the test stream, and some attributes of the very general
RFC 2330 notion of "packet type", including packet size and per-hop RFC 2330 notion of `packet type', including packet size and per-hop
behavior (PHB) [RFC2474], which could be used to support the behavior (PHB) [RFC2474], which could be used to support the
measurement of one-way active across diff-serv networks. measurement of one-way active across diff-serv networks.
Additionally, OWAMP-Control supports per-session encryption and Additionally, OWAMP-Control supports per-session encryption and
authentication for both test and control traffic, measurement servers authentication for both test and control traffic, measurement servers
which may act as proxies for test stream endpoints, and the exchange which may act as proxies for test stream endpoints, and the exchange
of a seed value for the pseudo-random Poisson process that describes of a seed value for the pseudo-random Poisson process that describes
the test stream generated by the sender. the test stream generated by the sender.
We believe that OWAMP-Control can effectively support one-way active We believe that OWAMP-Control can effectively support one-way active
measurement in a variety of environments, from publicly accessible measurement in a variety of environments, from publicly accessible
measurement "beacons" running on arbitrary hosts to network measurement `beacons' running on arbitrary hosts to network
monitoring deployments within private corporate networks. If monitoring deployments within private corporate networks. If
integration with SNMP or proprietary network management protocols is integration with SNMP or proprietary network management protocols is
required, gateways may be created. required, gateways may be created.
2.2. Logical Model 2.2. Logical Model
Several roles are logically separated to allow for broad flexibility Several roles are logically separated to allow for broad flexibility
in use. Specifically, we define: in use. Specifically, we define:
Session-Sender the sending endpoint of an OWAMP-Test session; Session-Sender the sending endpoint of an OWAMP-Test session;
skipping to change at page 3, line 48 skipping to change at page 3, line 48
Server an end system that manages one or more OWAMP-Test Server an end system that manages one or more OWAMP-Test
sessions, is capable of configuring per-session sessions, is capable of configuring per-session
state in session endpoints, and is capable of state in session endpoints, and is capable of
returning the results of a test session; returning the results of a test session;
Control-Client an end system that initiates requests for Control-Client an end system that initiates requests for
OWAMP-Test sessions, triggers the start of a set OWAMP-Test sessions, triggers the start of a set
of sessions, and may trigger their termination; of sessions, and may trigger their termination;
Retrieve-Client an end system that initiates requests to retrieve Fetch-Client an end system that initiates requests to fetch
the results of completed OWAMP-Test sessions; the results of completed OWAMP-Test sessions;
One possible scenario of relationships between these roles is shown One possible scenario of relationships between these roles is shown
below. below.
+----------------+ +------------------+ +----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver | | Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+ +----------------+ +------------------+
^ ^ ^ ^
| | | |
| | | |
| | | |
| +----------------+<----------------+ | +----------------+<----------------+
| | Server |<-------+ | | Server |<-------+
| +----------------+ | | +----------------+ |
| ^ | | ^ |
| | | | | |
| OWAMP-Control OWAMP-Control | OWAMP-Control OWAMP-Control
| | | | | |
v v v v v v
+----------------+ +-----------------+ +----------------+ +-----------------+
| Control-Client | | Retrieve-Client | | Control-Client | | Fetch-Client |
+----------------+ +-----------------+ +----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this draft and may (Unlabeled links in the figure are unspecified by this draft and may
be proprietary protocols.) be proprietary protocols.)
Different logical roles can be played by the same host. For example, Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Retrieve-Client, and Session- playing the roles of Control-Client, Fetch-Client, and Session-
Sender, and the other playing the roles of Server and Session- Sender, and the other playing the roles of Server and Session-
Receiver. This is shown below. Receiver. This is shown below.
+-----------------+ +------------------+ +-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server | | Control-Client |<--OWAMP-Control-->| Server |
| Retrieve-Client | | | | Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver | | Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+ +-----------------+ +------------------+
Finally, because many Internet paths include segments that transport Finally, because many Internet paths include segments that transport
IP over ATM, delay and loss measurements can include the effects of IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWAMP has been ATM segmentation and reassembly (SAR). Consequently, OWAMP has been
designed to allow for small test packets that would fit inside the designed to allow for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in payload of a single ATM cell (this is only achieved in
unauthenticated and encrypted modes). unauthenticated and encrypted modes).
skipping to change at page 5, line 43 skipping to change at page 5, line 43
Each type of OWAMP-Control message has a fixed length. The recipient Each type of OWAMP-Control message has a fixed length. The recipient
will know the full length of a message after examining first 16 will know the full length of a message after examining first 16
octets of it. No message is shorter than 16 octets. octets of it. No message is shorter than 16 octets.
If the full message is not received within 30 minutes after it is If the full message is not received within 30 minutes after it is
expected, connection SHOULD be dropped. expected, connection SHOULD be dropped.
4.1. Connection Setup 4.1. Connection Setup
Before either a Control-Client or a Retrieve-Client can issue Before either a Control-Client or a Fetch-Client can issue commands
commands of a Server, it must establish a connection to the server. of a Server, it must establish a connection to the server.
First, a client opens a TCP connection to the server on a well-known First, a client opens a TCP connection to the server on a well-known
port. The server responds with a server greeting: port. The server responds with a server greeting:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Unused (12 octets) | | Unused (12 octets) |
| | | |
skipping to change at page 8, line 46 skipping to change at page 8, line 46
4.2. OWAMP-Control Commands 4.2. OWAMP-Control Commands
In authenticated or encrypted mode (which are identical as far as In authenticated or encrypted mode (which are identical as far as
OWAMP-Control is concerned, and only differ in OWAMP-Test) all OWAMP-Control is concerned, and only differ in OWAMP-Test) all
further communications are encrypted with the Session-key, using CBC further communications are encrypted with the Session-key, using CBC
mode. The client encrypts its stream using Client-IV. The server mode. The client encrypts its stream using Client-IV. The server
encrypts its stream using Server-IV. encrypts its stream using Server-IV.
The following commands are available for the client: Request-Session, The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Session, Retrieve-Session. The command Stop- Start-Sessions, Stop-Session, Fetch-Session. The command Stop-
Session is available to both client and server. Session is available to both client and server.
After Start-Sessions is sent/received by the client/server, and After Start-Sessions is sent/received by the client/server, and
before it both sends and receives Stop-Session (order unspecified), before it both sends and receives Stop-Session (order unspecified),
it is said to be conducting active measurements. it is said to be conducting active measurements.
While conducting active measurements, the only command available is While conducting active measurements, the only command available is
Stop-Session. Stop-Session.
These commands are described in detail below. These commands are described in detail below.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
a simple request/response protocol. An OWAMP client MAY issue zero or a simple request/response protocol. An OWAMP client MAY issue zero or
more Request-Session messages to an OWAMP server, which MUST respond more Request-Session messages to an OWAMP server, which MUST respond
to each with an Accept-Session message. An Accept-Session message to each with an Accept-Session message. An Accept-Session message
MAY refuse a request. MAY refuse a request.
The format of Request-Session message is as follows: The format of Request-Session message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |IPVN-S | IPVN-R| Conf-Sender | Conf-Receiver | | 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address | | Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address (cont.) or Unused |
| | | |
| Sender Address (cont.) or MBZ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address | | Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address (cont.) or Unused |
| | | |
| Receiver Address (cont.) or MBZ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inv-Lambda |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length | | Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time | | Start Time |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor | | Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |
| | | |
| Zero Padding (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here the first octet (1) indicates that this is Request-Session This is immediately followed by one or more schedule slot
descriptions (the number of schedule slots is specified in the
`Number 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 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 (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages comprise one logical message: the Request-Session
command. command.
IPVN-S and IPVN-R are IP version numbers for Sender and Receiver. In Above, the first octet (1) indicates that this is Request-Session
the case of IP version number being 4, twelve unused octets follow command.
the four-octet address.
IPVN is the IP version numbers for Sender and Receiver. In the case
of IP version number being 4, twelve unused octets follow the four-
octet address. Currently meaningful values are 4 and 6.
Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is
being asked to configure the corresponding agent (sender or being asked to configure the corresponding agent (sender or
receiver). In this case, the corresponding Port value SHOULD be receiver). In this case, the corresponding Port value SHOULD be
disregarded by the server. At least one of Conf-Sender and Conf- disregarded by the server. At least one of Conf-Sender and Conf-
Receiver MUST be 1. (Both can be set, in which case the server is Receiver MUST be 1. (Both can be set, in which case the server is
being asked to perform a session between two hosts it can configure.) being asked to perform a session between two hosts it can configure.)
The Sender Address and Receiver Address fields contain respectively Number of Schedule Slots, as mentioned before, specifies the number
the sender and receiver addresses of the end points of the Internet of slot records that go between the two blocks of Integrity Zero
path over which an OWAMP test session is requested. Padding. It is used by the sender to determine when to send test
packets (see next section).
Number of Packets is the number of active measurement packets to be
sent during this OWAMP-Test session (note that both server and client
can abort the session early).
If Conf-Sender is not set, Sender Port is the UDP port OWAMP-Test 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 packets will be sent from. If Conf-Receiver is not set, Receiver
Port is the UDP port OWAMP-Test packets are requested to be sent to. Port is the UDP port OWAMP-Test packets are requested to be sent to.
SID is the session identifier. It can be used in later sessions as The Sender Address and Receiver Address fields contain respectively
an argument for Retrieve-Session command. It is meaningful only if the sender and receiver addresses of the end points of the Internet
Conf-Receiver is 1. path over which an OWAMP test session is requested.
The field Inv-Lambda is an unsigned integer and is the scaled
reciprocal of rate (in microseconds) at which the Poisson test stream
is to be generated. This allows the average Poisson sampling
interval for the requested test session to be set to between 1
microsecond and over an hour.
The value Packets is the number of active measurement packets to be SID is the session identifier. It can be used in later sessions as
sent during this OWAMP-Test session (note that both server and client an argument for Fetch-Session command. It is meaningful only if
can abort the session early). Conf-Receiver is 0. This way, the SID is always generated by the
receiving side. See the end of the section for information on how
the SID is generated.
Padding length is the number of octets to be appended to normal Padding length is the number of octets to be appended to normal
OWAMP-Test packet (see more on padding in discussion of OWAMP-Test). OWAMP-Test packet (see more on padding in discussion of OWAMP-Test).
Start Time is the time when the session is to be started (but not Start Time is the time when the session is to be started (but not
before Start-Sessions command is issued). This timestamp is in the before Start-Sessions command is issued). This timestamp is in the
same format as OWAMP-Test timestamps. same format as OWAMP-Test timestamps.
Timeout is an interval of time (expressed as a timestamp). A packet
belonging to the test session that is being set up by the current
Request-Session command will be considered lost if it is not received
during Timeout seconds after it is sent.
Type-P Descriptor covers only a subset of (very large) Type-P space. Type-P Descriptor covers only a subset of (very large) Type-P space.
If the first two bits of Type-P Descriptor are 00, then subsequent 6 If the first two bits of Type-P Descriptor are 00, then subsequent 6
bits specify the requested Differentiated Services Codepoint (DSCP) bits specify the requested Differentiated Services Codepoint (DSCP)
value of sent OWAMP-Test packets as defined in RFC 2474. If the value 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 first two bits of Type-P descriptor are 01, then subsequent 16 bits
specify the requested Per Hop Behavior Identification Code (PHB ID) specify the requested Per Hop Behavior Identification Code (PHB ID)
as defined in RFC 2836. as defined in RFC 2836.
Therefore, the value of all zeros specifies the default best-effort Therefore, the value of all zeros specifies the default best-effort
service. service.
skipping to change at page 12, line 14 skipping to change at page 13, line 7
the sender to send packets according to its value. If Conf-Sender is the sender to send packets according to its value. If Conf-Sender is
not set, Type-P Descriptor is a declaration of how the sender will be not set, Type-P Descriptor is a declaration of how the sender will be
configured. configured.
If Conf-Sender is set and the server doesn't recognize Type-P If Conf-Sender is set and the server doesn't recognize Type-P
Descriptor, cannot or does not wish to set the corresponding Descriptor, cannot or does not wish to set the corresponding
attributes on OWAMP-Test packets, it SHOULD reject the session attributes on OWAMP-Test packets, it SHOULD reject the session
request. If Conf-Sender is not set, the server SHOULD accept the request. If Conf-Sender is not set, the server SHOULD accept the
session regardless of the value of Type-P Descriptor. session regardless of the value of Type-P Descriptor.
Zero Padding MUST be all zeros in this and all subsequent messages Integrity Zero Padding MUST be all zeros in this and all subsequent
that use zero padding. The recipient of a message where zero padding messages that use zero padding. The recipient of a message where
is not zero MUST reject the message as it is an indication of zero padding is not zero MUST reject the message as it is an
tampering with the content of the message by an intermediary (or indication of tampering with the content of the message by an
brokenness). If the message is part of OWAMP-Control, the session intermediary (or brokenness). If the message is part of OWAMP-
MUST be terminated and results invalidated. If the message is part Control, the session MUST be terminated and results invalidated. If
of OWAMP-Test, it MUST be silently ignored. This will ensure data the message is part of OWAMP-Test, it MUST be silently ignored. This
integrity. 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 conjuction with properties
of CBC chaining mode, that everything received before was not
tampered with. For this reason, it is important to check the
Integrity Zero 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 To each Request-Session message, an OWAMP server MUST respond with an
Accept-Session message: Accept-Session message:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Unused | Port | | Accept | Unused | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (12 octets) | | Integrity Zero Padding (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zero in the Accept field means that the server is willing to conduct In this message, zero in the Accept field means that the server is
the session. A value of 1 indicates rejection of the request. All willing to conduct the session. A value of 1 indicates rejection of
other values are reserved. the request. All other values are reserved.
If the server rejects a Request-Session command, it SHOULD not close If the server rejects a Request-Session command, it SHOULD not close
the TCP connection. The client MAY close it if it gets negative the TCP connection. The client MAY close it if it gets negative
response to Request-Session. response to Request-Session.
The meaning of Port depend on the values of Conf-Sender and Conf- The meaning of Port in the response depends on the values of Conf-
Receiver in the query that solicited the response. If both were set, Sender and Conf-Receiver in the query that solicited the response.
Port field is unused. If only Conf-Sender was set, Port is the port If both were set, Port field is unused. If only Conf-Sender was set,
to expect OWAMP-Test packets from. If only Conf-Receiver was set, Port is the port to expect OWAMP-Test packets from. If only Conf-
Port is the port to send OWAMP-Test packets to. Receiver was set, Port is the port to send OWAMP-Test packets to.
If only Conf-Sender was set, SID is unused. Otherwise, SID is a If only Conf-Sender was set, SID field in the response is unused.
unique server-generated session identifier. It can be used later as Otherwise, SID is a unique server-generated session identifier. It
handle to retrieve the results of a session. can be used later as handle to fetch the results of a session.
SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number
belonging to the generating machine, 8-octet timestamp, and 4-octet belonging to the generating machine, 8-octet timestamp, and 4-octet
random value. Note that SID is always chosen by the receiver. 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 SID generation, even if all
communication is IPv6-based. If it has no IPv4 addresses at all, the
last 4 octets of an IPv6 address can be used instead. Note that SID
is always chosen by the receiver. If truely random values are not
available, it is important that SID be made unpredictable as
knowledge of SID might be used for access control.
4.4. Starting Test Sessions 4.4. Send Schedules
The sender and the receiver need to both know the same send schedule.
This way, when packets are lost, the receiver knows when they were
sent. It is desirable to compress common schedules and still to be
able to use an arbitrary one for the test sessions. In many cases,
the schedule will consist of repeated sequences of packets: this way,
the sequence performs some test, and the test is repeated a number of
times to gather statistics.
To implement this, we have a schedule with a given number of `slots'.
Each slots has a type and a parameter. Two types are supported:
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 a
type 0 slot (exponentially distributed pseudo-random quantity) this
interval is the mean value (or 1/lambda if the distribution density
function is expressed as lambda*exp(-lambda*x) for positive values of
x). For a type 1 slot, the parameter is the delay itself. The
sender starts with the beginning of the schedule, and `executes' the
instructions in the slots: for a slot of type 0, wait exponentially
distributed time with mean of the specified parameter and then send a
test packet (and proceed to the next slot); for a slot of type 1,
wait the specified time and send a test packet (and proceed to the
next slot). The schedule is circular: when there are no more slots,
the sender returns to the first slot.
Slots of type 1 can be trivially reproduceably executed by both the
sender and the receiver (so if a packet is lost, the receiver can
still attach a send timestamp to it). To reproduceable execute slots
of type 0, we need to be able to generate pseudo-random exponentially
distributed quantities is a reproduceable 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 completely arbitrary schedule can be specified (albeit
inefficiently) by making the number of test packets equal to the
number of schedule slots. In this case, the complete schedule is
transmitted in advance of an OWAMP-Test session.
4.5. Starting Test Sessions
Having requested one or more test sessions and received affirmative Having requested one or more test sessions and received affirmative
Accept-Session responses, an OWAMP client may start the execution of Accept-Session responses, an OWAMP client may start the execution of
the requested test sessions by sending a Start-Sessions message to the requested test sessions by sending a Start-Sessions message to
the server. the server.
The format of this message is as follows: The format of this message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | | | 2 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (15 octets) | | Unused (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Integrity Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Control-Ack message (which SHOULD be The server MUST respond with an Control-Ack message (which SHOULD be
sent as quickly as possible). Control-Ack messages have the following sent as quickly as possible). Control-Ack messages have the following
format: format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | | | Accept | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (15 octets) | | Unused (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Integrity Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is 1, the Start-Sessions request was rejected; zero means If Accept is 1, the Start-Sessions request was rejected; zero means
that the command was accepted. All other values are reserved. The that the command was accepted. All other values are reserved. The
server MAY and the client SHOULD close the connection in the case of server MAY and the client SHOULD close the connection in the case of
a negative response. a negative response.
The server SHOULD start all OWAMP-Test streams immediately after it The server SHOULD start all OWAMP-Test streams immediately after it
sends the response or immediately after their specified start times, sends the response or immediately after their specified start times,
whichever is later. (Note that a client can effect an immediate whichever is later. (Note that a client can effect an immediate
start by specifying in Request-Session a Start Time in the past.) If start by specifying in Request-Session a Start Time in the past.) If
the client represents a Sender, the client SHOULD start its OWAMP- the client represents a Sender, the client SHOULD start its OWAMP-
Test streams immediately after it sees the Control-Ack response from Test streams immediately after it sees the Control-Ack response from
the Server. the Server.
4.5. Stop-Sessions 4.6. Stop-Sessions
The Stop-Sessions message may be issued by either the Control-Client The Stop-Sessions message may be issued by either the Control-Client
or the Server. The format of this command is as follows: or the Server. The format of this command is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | | | 3 | Accept | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Unused (14 octets) | | Unused (14 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Integrity Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normally, the client SHOULD send this command after the OWAMP-Test Normally, the client SHOULD send this command after the OWAMP-Test
streams have completed. However, either client or server MAY send it streams have completed. However, either client or server MAY send it
prematurely. prematurely.
Value of 1 of Accept indicates a failure of some sort. Zero values Value of 1 of Accept indicates a failure of some sort. Zero values
indicates normal (but possibly premature) completion. All other indicates normal (but possibly premature) completion. All other
values are reserved. If Accept had non-zero value (from either values are reserved. If Accept had non-zero value (from either
party), or if it was not transmitted at all (for whatever reason, party), or if it was not transmitted at all (for whatever reason,
including TCP connection used for OWAMP-Control breaking), results of including TCP connection used for OWAMP-Control breaking), results of
all OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD all OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD
be considered invalid, even if Retrieve-Session with SID from this be considered invalid, even if Fetch-Session with SID from this
session works during a different OWAMP-Control session. session works during a different OWAMP-Control session.
If an OWAMP-Test receiver finishes recording packets of a session and
the OWAMP-Control end of connection associated with the receiver
(probably the receiver itself) sends a Stop-Sessions command that
receives no response within a reasonable communication timeout, or if
the OWAMP-Control connection breaks when the Stop-Sessions command is
sent, the receiver MAY not completely invalidate the session results,
but it MUST discard any records of lost packets 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 occured in the network and the sender crashing. When the
results of such an OWAMP-Test session or an OWAMP-Session that was
prematurely aborted successfully (with confirmation) are later
fetched using Fetch-Session, the original number of packets MUST be
supplied in the reproduction of the Request-Session command.
The party that receives this command MUST stop its OWAMP-Test streams The party that receives this command MUST stop its OWAMP-Test streams
and respond with a Stop-Sessions message. Any non-zero value in and respond with a Stop-Sessions message. Any non-zero value in
Accept field means something went wrong. A zero value means OWAMP- Accept field means something went wrong. A zero value means OWAMP-
Test streams have been successfully stopped. Test streams have been successfully stopped.
4.6. Retrieve-Session 4.7. Fetch-Session
The format of this client command is as follows: The format of this client command is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | | | 4 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (17 octets) | | Unused (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq | | Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq | | End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Integrity Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begin Seq is the sequence number of the first requested packet. End 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 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 Seq is all zeros and End Seq is all ones, complete session is said to
be requested. be requested.
If a complete session is requested and the session is still in If a complete session is requested and the session is still in
progress, or has terminated in any way other than normal, the request progress, or has terminated in any way other than normal, the request
to retrieve session results MUST be denied. If an incomplete session to fetch session results MUST be denied. If an incomplete session is
is requested, all packets received so far that fall into the requested, all packets received so far that fall into the requested
requested range SHOULD be returned. 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 The server MUST respond with a Control-Ack message. Again, 1 in the
Accept field means rejection of command. Zero means that data will Accept field means rejection of command. Zero means that data will
follow. All other values are reserved. follow. All other values are reserved.
If Accept was 0, the server then MUST send the OWAMP-Test session If Accept was 0, the server then MUST send the OWAMP-Test session
data in question, followed by 16 octets of zero padding. data in question, followed by 16 octets of Integrity Zero Padding.
The transmission starts with 4 octets that contain the number of The OWAMP-Test session data consists of the following (concatenated):
records that will follow, each record representing one received
packet. This is followed by 4 octets of Type-P Descriptor and 8
octets of zero padding.
Each packet is represented with 20 octets, and includes 4 octets of + A reproduction of the Request-Session command that was used to
sequence number, 8 octets of send timestamp, and 8 octets of receive start the session; it is modified so that actual sender and
timestamp. receiver port numbers that were used by the OWAMP-Test session
always appear in the reproduction.
+ The number of packet records that will follow represented as an
unsigned 4-octet integer. This number might be less than the
Number of Packets in the reproduction of 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 24 octets, and includes 4 octets of sequence
number, 8 octets of send timestamp, 2 octets of send timestamp error
estimate, 8 octets of receive timestamp, and 2 octets of receive
timestamp error estimate (in this order). Packet records are sent
out in the same order they are made when the results of the session
are recorded. Therefore, the data is in arrival order.
Note that lost packets (if any losses were detected during the OWAMP-
Test session) MUST appear in the sequence of packets. They can
appear either at the point when the loss was detected or at any later
point. Lost packet records are distinguished by the receive
timestamp consisting of a string of zero bits and an error estimate
with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for
definition of these quantities and explanation of timestamp format
and error estimate format).
The last (possibly full, possibly incomplete) block (16 octets) of The last (possibly full, possibly incomplete) block (16 octets) of
data is padded with zeros if necessary. A zero padding consisting of data is padded with zeros if necessary. (These zeros are simple
16 octets is then appended. padding and should be distinguished from the 16 octets of Integrity
Zero Padding that follow the session data and conclude the response
to Fetch-Session.)
5. OWAMP-Test 5. OWAMP-Test
This section describes OWAMP-Test protocol. It runs over UDP using This section describes OWAMP-Test protocol. It runs over UDP using
sender and receiver IP and port numbers negotiated during Session- sender and receiver IP and port numbers negotiated during Session-
Prepare exchange. Prepare exchange.
As OWAMP-Control, OWAMP-Test has three modes: unauthenticated, As OWAMP-Control, OWAMP-Test has three modes: unauthenticated,
authenticated, and encrypted. All OWAMP-Test sessions spawned by an authenticated, and encrypted. All OWAMP-Test sessions spawned by an
OWAMP-Control session inherit its mode. OWAMP-Control session inherit its mode.
skipping to change at page 17, line 39 skipping to change at page 20, line 25
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. . . .
. Packet padding (0-65515 octets) . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated mode: For authenticated and encrypted modes:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (12 octets) | | Integrity Zero Padding (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Error Estimate | |
. . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. Packet padding (0-65503 octets) . | Integrity Zero Padding (6 octets) |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For encrypted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet padding (0-65511 octets) . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is influenced by RFC 1305 and is as The format of the timestamp is the same as in RFC 1305 and is as
follows: first 32 bits represent the unsigned integer number of follows: first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; next 24 bits represent seconds elapsed since 0h on 1 January 1900; next 32 bits represent
the fractional part of a second that has elapsed since then (so, the fractional part of a second that has elapsed since then.
first 56 bits of the timestamp would be the same as the corresponding
bits of NTP v3 timestamp). The remaining octet specifies
synchronization and precision. The first bit is set if the party
generating the timestamp has a clock that is synchronized to an
external source (e.g., the bit should be set if GPS hardware is used
and it indicates that it has acquired current position and time or if
NTP is used and it indicates that it has synchronized to an external
source, which includes stratum 0 source, etc.); if there is no notion
of external synchronization for the time source (e.g., a cesium
oscillator is used directly), the bit SHOULD be set. The next bit is
currently unused and may be set to an arbitrary value. The remaining
six bits form an unsigned integer, which is the number of bits in the
time-specifying main part of the timestamp that the party generating
timestamp believes to be correct (this should be set conservatively).
When generating a timestamp, one MUST ensure that this number falls
into the range from 0 to 56; when interpreting a timestamp, one MUST
treat numbers in the range 57 to 63 identically to the number 56.
More rigorous semantics of precision indicators are out of scope of
OWAMP, but may be negotiated out-of-band.
So, timestamp is represented as follows: So, Timestamp is represented as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds | | Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |S|U| Prec | | Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where S is the synchronization bit, U is currently unused, and Prec
is the unsigned integer in the range from 0 to 56 discussed above. The Error Estimate specifies the estimate of the error 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 is 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 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 Sequence numbers start with 0 and are incremented by 1 for each
subsequent packet. subsequent packet.
The minimum data segment length is therefore 12 octets in The minimum data segment length is therefore 14 octets in
unauthenticated mode, 24 octets in authenticated mode, and 16 octets unauthenticated mode, and 32 octets in authenticated mode and
in encrypted mode. encrypted modes.
In authenticated and encrypted mode, the first block (16 octets) of The OWAMP-Test packet layout is the same in authenticated and
each packet is encrypted using AES ECB mode. encrypted modes. The encryption operations are, however, different.
The difference is that in encrypted mode both the sequence number and
the timestamp are encrypted to provide maximum data integrity
protection while in authenticated mode the sequence number is
encrypted and the timestamp is sent in cleartext. Sending the
timestamp in cleartext in authenticated mode allows to reduce the
time between a timestamp is obtained by a sender and the packet is
shipped out. In encrypted mode, the sender has to fetch the
timestamp, encrypt it, and send it; in authenticated mode, the 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 each packet is
encrypted using AES ECB mode. The key to use is the same key as is
used for the corresponding OWAMP-Control session (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 decyphering any packet 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 the same key as is used for
the corresponding OWAMP-Control session. Each OWAMP-Test packet is
encrypted as a separate stream, 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. In unauthenticated mode, no encryption is applied.
The time elapsed between packets is pseudo-random, with exponential Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
distribution (resulting in a Poisson stream of packets). As generated independently of any other pseudo-random numbers mentioned
suggested in RFC 2330, the ith sampling interval Ei may be computed in this document). However, implementations MUST provide a
using inverse transform: configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros.
Ei = -ln(Ui) * Inv-Lambda The time elapsed between packets is computed according to the slot
schedule as mentioned in Request-Session command description. At
that point we skipped over the issue of computing exponentially
distributed pseudo-random numbers in a repreduceable fashion.
where Ui is uniformly distributed between 0 and 1 and lambda is the 6. Computing Exponentially Distributed Pseudo-Random Numbers
desired mean time between packets.
[This section will describe the method based on the ziggurat
algorithm to generate exponentially distributed PRNs without any
machine-dependent operations (no floating point is used).]
Pseudo-random stream of bits is obtained using AES with SID as the Pseudo-random stream of bits is obtained using AES with SID as the
key, running in counter mode (first encrypted block is 0, second key, running in counter mode (first encrypted block is 0, second
encrypted block is 1 in network octet order, etc.) Each block of 64 encrypted block is 1 in network octet order, etc.) Each block of 64
bits is used to obtain one pseudo-random number uniformly distributed bits is used to obtain one pseudo-random number uniformly distributed
between 0 and 1. If the bits are Bj (j=1..64, numbered left to between 0 and 1. If the bits are Bj (j=1..64, numbered left to
right), the resulting value is right), the resulting value is
U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64} U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64}
The parameter lambda is has the value requested in the Request- 6.1. Receiver Behavior
Session message of the OWAMP-Control negotiation that spawned the
session.
The logarithm and division in the formula above MUST be computed
using IEEE 754 standard floating point arithmetic. [HELP WANTED!:
Someone with a stronger background in numerical analysis to specify
how to compute the sampling intervals precisely and portably!]
Finally, Packet Padding SHOULD be pseudo-random (generated
independently of any other pseudo-random numbers mentioned in this
document). However, implementations MUST provide a configuration
parameter, an option, or a different means of making Packet Padding
consist of all zeros.
5.2. Receiver Behavior
Receiver knows when the sender will send packets. The following Receiver knows when the sender will send packets. The following
parameter is defined: loss threshold. It SHOULD be 10 minutes and parameter is defined: Timeout (from Request-Session). Packets that
MAY be more, but not more than 60 minutes. are delayed by more that Timeout are considered lost (or `as good as
lost'). Note that there is never an actual assurance of loss by the
network: a `lost' packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value of 255).
To the best of the authors' knowledge, this requirement was never
actually implemented (and of course only a complete and universal
implementation would ensure that packets don't travel for longer than
TTL seconds). Further, IPv4 specification makes no claims about the
time it takes the packet to traverse the last link of the path.
The choice of a reasonable value of Timeout is a problem faced by a
user of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications (such as
interactive `one-way ping') might wish to obtain the data faster than
that.
As packets are received, As packets are received,
+ Timestamp the received packet. + Timestamp the received packet.
+ In authenticated or encrypted mode, decrypt first block (16 + In authenticated or encrypted mode, decrypt first block (16
octets) of packet body. octets) of packet body.
+ Store the packet sequence number, send times, and receive times + Store the packet sequence number, send times, and receive times
for the results to be transferred. for the results to be transferred.
+ Packets not received within the loss threshold are considered + Packets not received within the Timeout are considered lost. They
lost. They are recorded with their seqno, presumed send time, and are recorded with their seqno, presumed send time, and receive
receive time consisting of a string of zero bits. time consisting of a string of zero bits.
Packets that are actually received are recorded in the order of
arrival. Lost packet records serve as indications of the send times
of lost packets. They SHOULD be placed either at the point where the
receiver learns about the loss or at any later point; in particular,
one MAY place all the records that correspond to lost packets at the
very end.
Packets that have send time in the future MUST be recorded normally, Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have to be without changing their send timestamp, unless they have to be
discarded. discarded. (Send timestamps in the future would normally indicate
clocks that differ by more than the delay. Some data -- such as
jitter -- can be extracted even without knowledge of time difference.
For other kinds of data, the adjustment is best handled by the data
consumer on the basis of the complete information in a measurement
session as well as possibly external data.)
Packets with a sequence number that was already observed (duplicate
packets) MUST be recorded normally. (Duplicate packets are sometimes
introduced by IP networks. The protocol has to be able to measure
duplication.)
If any of the following is true, packet MUST be discarded: If any of the following is true, packet MUST be discarded:
+ Send timestamp is more than loss threshold in the past or in the + Send timestamp is more than Timeout in the past or in the future.
future.
+ Send timestamp differs by more than loss threshold from the time + Send timestamp differs by more than Timeout from the time when the
when the packet should have been sent according to its seqno. packet should have been sent according to its seqno.
+ In authenticated or encrypted mode, any of the bits of zero + In authenticated or encrypted mode, any of the bits of zero
padding inside the first 16 octets of packet body is non-zero. padding inside the first 16 octets of packet body is non-zero.
6. Security Considerations 7. Security Considerations
The goal of authenticated mode to let one passphrase-protect service The goal of authenticated mode to let one passphrase-protect service
provided by a particular OWAMP-Control server. One can imagine a provided by a particular OWAMP-Control server. One can imagine a
variety of circumstances where this could be useful. Authenticated variety of circumstances where this could be useful. Authenticated
mode is designed to prohibit theft of service. mode is designed to prohibit theft of service.
Additional design objective of authenticated mode was to make it Additional design objective of authenticated mode was to make it
impossible for an attacker who cannot read traffic between OWAMP-Test impossible for an attacker who cannot read traffic between OWAMP-Test
sender and receiver to tamper with test results in a fashion that sender and receiver to tamper with test results in a fashion that
affects the measurements, but not other traffic. affects the measurements, but not other traffic.
The goal of encrypted mode is quite different: To make it hard for a The goal of encrypted mode is quite different: To make it hard for a
party in the middle of the network to make results look "better" than party in the middle of the network to make results look `better' than
they should be. This is especially true if one of client and server they should be. This is especially true if one of client and server
doesn't coincide with neither sender nor receiver. doesn't coincide with neither sender nor receiver.
Encryption of OWAMP-Control using AES CBC mode with blocks of zeros Encryption of OWAMP-Control using AES CBC mode with blocks of zeros
after each message aims to achieve two goals: (i) to provide secrecy after each message aims to achieve two goals: (i) to provide secrecy
of exchange; (ii) to provide authentication of each message. of exchange; (ii) to provide authentication of each message.
OWAMP-Test sessions directed at an unsuspecting party could be used OWAMP-Test sessions directed at an unsuspecting party could be used
for denial of service (DoS) attacks. In unauthenticated mode servers for denial of service (DoS) attacks. In unauthenticated mode servers
should limits receivers to hosts they control or to the OWAMP-Control should limits receivers to hosts they control or to the OWAMP-Control
client. client.
OWAMP-Test sessions could be used as covert channels of information. OWAMP-Test sessions could be used as covert channels of information.
Environments that are worried about covert channels should take this Environments that are worried about covert channels should take this
into consideration. into consideration.
Notice that AES in counter mode is used for pseudo-random number Notice that AES in counter mode is used for pseudo-random number
generation, so implementation of AES MUST be included even in a generation, so implementation of AES MUST be included even in a
server that only supports unauthenticated mode. server that only supports unauthenticated mode.
7. References 8. IANA Considerations
IANA is requested to allocate a well-known TCP port number for OWAMP-
Control part of the OWAMP protocol.
9. Internationalization Considerations
The protocol does not carry any information in a natural language.
10. Normative References
[AES] Advanced Encryption Standard (AES), [AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/ http://csrc.nist.gov/encryption/aes/
[RFC1305]D. Mills, "Network Time Protocol (Version 3) Specification, [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992. Implementation and Analysis', RFC 1305, March 1992.
[RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC [RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321,
1321, April 1992. April 1992.
[RFC2026]S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3',
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC2119]S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels', RFC 2119, March 1997.
[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for
for IP Performance Metrics" RFC 2330, May 1998. IP Performance Metrics' RFC 2330, May 1998.
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of
of the Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998. IPv6 Headers', RFC 2474, December 1998.
[RFC2679]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay
Metric for IPPM", RFC 2679, September 1999. Metric for IPPM', RFC 2679, September 1999.
[RFC2680]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999. Loss Metric for IPPM', RFC 2680, September 1999.
[RFC2836]S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior
Identification Codes", RFC 2836, May 2000. Identification Codes', RFC 2836, May 2000.
11. Informative References
[RIPE] RIPE NCC Test-Traffic Measurements home, [RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/. http://www.ripe.net/test-traffic/.
[RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay
Measurements Using Test-Traffic", Spring 1998 Dutch Unix User Measurements Using Test-Traffic', Spring 1998 Dutch Unix User
Group Meeting, http://www.ripe.net/test- Group Meeting, http://www.ripe.net/test-
traffic/Talks/9805_nluug.ps.gz. traffic/Talks/9805_nluug.ps.gz.
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
[SURVEYOR-INET]S. Kalidindi and M. Zekauskas, "Surveyor: An [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An
Infrastructure for Network Performance Measurements", Infrastructure for Network Performance Measurements',
Proceedings of INET'99, June 1999. Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
8. Authors' Addresses 12. Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2 / UCAID Internet2 / UCAID
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1182 Phone: +1 914 765 1182
EMail: shalunov@internet2.edu EMail: shalunov@internet2.edu
skipping to change at page 23, line 34 skipping to change at page 27, line 43
Matthew J. Zekauskas Matthew J. Zekauskas
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1112 Phone: +1 914 765 1112
EMail: matt@advanced.org EMail: matt@advanced.org
Expiration date: December 2002 Expiration date: February 2003
 End of changes. 

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