| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begin Seq is the sequence number of the first requested packet. End
Seq is the sequence number of the last requested packet. If Begin
Seq is all zeros and End Seq is all ones, complete session is said to
be requested.
If a complete session is requested and the session is still in
progress or has terminated in any way other than normally, 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 Fetch-Ack message. The format of this
server response 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command.
The server MUST specify zero for all remaining fields if Accept is
non-zero. The client MUST ignore all remaining fields (except for
the HMAC) if Accept is non-zero. The full list of available Accept
values is described in Section 3.3, "Values of the Accept Field".
Finished is non-zero if the OWAMP-Test session has terminated.
Next Seqno indicates the next sequence number that would have been
sent from this send session. For completed sessions, this will equal
NumPackets from the Request-Session. This information is only
available if the session has terminated. If Finished is zero, then
Next Seqno MUST be set to zero by the server.
Number of Skip Ranges indicates the number of holes that actually
occurred in the sending process. This information is only available
if the session has terminated. If Finished is zero, then Skip Ranges
MUST be set to zero by the server.
Number of Records is the number of packet records that fall within
the requested range. 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.
If Accept was non-zero, this concludes the response to the Fetch-
Session message. If Accept was 0, the server then MUST immediately
send the OWAMP-Test session data in question.
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
always appear in the reproduction.
+ Zero or more (as specified) Skip Range descriptions. The last
(possibly full, possibly incomplete) block (16 octets) of Skip
Range descriptions is padded with zeros, if necessary.
+ 16 octets of HMAC.
+ Zero or more (as specified) packet records. The last (possibly
full, possibly incomplete) block (16 octets) of data is padded
with zeros, if necessary.
+ 16 octets of HMAC.
Skip Range descriptions are simply two sequence numbers that,
together, indicate a range of packets that were not sent:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Range descriptions should be sent out in order, as sorted by
First Seqno. If any Skip Ranges overlap or are out of order, the
session data is to be considered invalid and the connection SHOULD be
closed and any results obtained considered invalid.
Each packet record is 25 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, 2 octets of receive
timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop
Limit in IPv6:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08| Send Timestamp |
12| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp |
20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+
Packet records are sent out in the same order the actual packets were
received. 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 as follows:
+ A send timestamp filled with 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 normal receive error estimate as determined by the error of the
clock being used to declare the packet lost. (It is declared lost
if it is not received by the Timeout after the presumed send time,
as determined by the receiver’s clock.)
+ A receive timestamp consisting of all zero bits.
+ A TTL value of 255.
4. OWAMP-Test
This section describes OWAMP-Test protocol. It runs over UDP, using
sender and receiver IP and port numbers negotiated during the
Request-Session exchange.
As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated,
authenticated, and encrypted. All OWAMP-Test sessions that are
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 there will be 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 sender and the receiver
to compute the same exact packet sending schedule independently of
each other. These sending schedules are independent for different
OWAMP-Test sessions, even if they are governed by the same OWAMP-
Control session.
Consider any OWAMP-Test session. Once Start-Sessions exchange is
complete, the sender is ready to start sending packets. Under normal
OWAMP use circumstances, the time to send the first packet is in the
near future (perhaps a fraction of a second away). The sender SHOULD
send packets as close as possible to their scheduled time, with the
following exception: if the scheduled time to send is in the past,
and is separated from the present by more than Timeout time, the
sender MUST NOT send the packet. (Indeed, such a packet would be
considered lost by the receiver anyway.) The sender MUST keep track
of which packets it does not send. It will use this to tell the
receiver what packets were not sent by setting Skip Ranges in the
Stop-Sessions message from the sender to the receiver upon completion
of the test. The Skip Ranges are also sent to a Fetch-Client as part
of the session data results. These holes in the sending schedule can
happen if a time in the past was specified in the Request-Session
command, or if the Start-Sessions exchange took unexpectedly long, or
if the sender could not start serving the OWAMP-Test session on time
due to internal scheduling problems of the OS. Packets that are in
the past but are separated from the present by less than Timeout
value SHOULD be sent as quickly as possible. With normal test rates
and timeout values, the number of packets in such a burst is limited.
Nevertheless, hosts SHOULD NOT intentionally schedule sessions so
that such bursts of packets occur.
Regardless of any scheduling delays, each packet that is actually
sent MUST have the best possible approximation of its real time of
departure as its timestamp (in the packet).
4.1.2. OWAMP-Test Packet Format and Content
The sender sends the receiver a stream of packets with the schedule
specified in the Request-Session command. The sender SHOULD set the
TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The
format of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in [RFC1305] and is as
follows: the first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; the next 32 bits
represent the fractional part of a second 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 of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, 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 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 zero and are incremented by one for each
subsequent packet.
The minimum data segment length is, therefore, 14 octets in
unauthenticated mode, and 48 octets in both authenticated mode and
encrypted modes.
The OWAMP-Test packet layout is the same in authenticated and
encrypted modes. The encryption and authentication operations are,
however, different. The difference is that in encrypted mode both
the sequence number and the timestamp are protected to provide
maximum data confidentiality and integrity protection, whereas in
authenticated mode the sequence number is protected while the
timestamp is sent in clear text. Sending the timestamp in clear text
in authenticated mode allows one to reduce the time between when a
timestamp is obtained by a sender and when 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,
potentially improving accuracy (the sequence number can be encrypted
and authenticated before the timestamp is fetched).
In authenticated mode, the first block (16 octets) of each packet is
encrypted using AES Electronic Cookbook (ECB) mode.
Similarly to each OWAMP-Control session, each OWAMP-Test session has
two keys: an AES Session-key and an HMAC Session-key. However, there
is a difference in how the keys are obtained: in the case of OWAMP-
Control, the keys are generated by the client and communicated (as
part of the Token) during connection setup as part of Set-Up-Response
message; in the case of OWAMP-Test, described here, the keys are
derived from the OWAMP-Control keys and the SID.
The OWAMP-Test AES Session-key is obtained as follows: the OWAMP-
Control AES Session-key (the same AES Session-key as is used for the
corresponding OWAMP-Control session, where it is used in a different
chaining mode) is encrypted, using AES, with the 16-octet session
identifier (SID) as the key; this is a single-block ECB encryption;
its result is the OWAMP-Test AES Session-key to use in encrypting
(and decrypting) the packets of the particular OWAMP-Test session.
Note that all of OWAMP-Test AES Session-key, OWAMP-Control AES
Session-key, and the SID are comprised of 16 octets.
The OWAMP-Test HMAC Session-key is obtained as follows: the OWAMP-
Control HMAC Session-key (the same HMAC Session-key as is used for
the corresponding OWAMP-Control session) is encrypted, using AES,
with the 16-octet session identifier (SID) as the key; this is a
two-block CBC encryption, always performed with IV=0; its result is
the OWAMP-Test HMAC Session-key to use in authenticating the packets
of the particular OWAMP-Test session. Note that all of OWAMP-Test
HMAC Session-key and OWAMP-Control HMAC Session-key are comprised of