idnits 2.17.1 draft-ietf-ippm-owdp-09.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 245 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 135 has weird spacing: '...eceiver the ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7224 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2680' is mentioned on line 51, but not defined ** Obsolete undefined reference: RFC 2680 (Obsoleted by RFC 7680) -- Looks like a reference, but probably isn't: '1' on line 1576 -- Looks like a reference, but probably isn't: '16' on line 1485 == Missing Reference: 'Loop' is mentioned on line 1355, but not defined == Missing Reference: 'K' is mentioned on line 1498, but not defined -- Looks like a reference, but probably isn't: '4' on line 1544 -- Looks like a reference, but probably isn't: '2' on line 1574 -- Looks like a reference, but probably isn't: '0' on line 1553 -- Looks like a reference, but probably isn't: '15' on line 1616 -- Looks like a reference, but probably isn't: '1000000' on line 1707 == Unused Reference: 'RFC1305' is defined on line 1714, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1720, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1723, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 1726, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1736, but no explicit reference was found in the text == Unused Reference: 'RFC2836' is defined on line 1739, but no explicit reference was found in the text == Unused Reference: 'RIPE-NLUUG' is defined on line 1756, but no explicit reference was found in the text == Unused Reference: 'SURVEYOR-INET' is defined on line 1763, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 2836 (Obsoleted by RFC 3140) Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stanislav Shalunov 3 Internet Draft Benjamin Teitelbaum 4 Expiration Date: January 2005 Anatoly Karp 5 Jeff W. Boote 6 Matthew J. Zekauskas 7 Internet2 8 July 2004 10 A One-way Active Measurement Protocol (OWAMP) 11 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft shadow directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This memo provides information for the Internet community. This memo 35 does not specify an Internet standard of any kind. Distribution of 36 this memo is unlimited. 38 2. Abstract 40 With growing availability of good time sources to network nodes, it 41 becomes increasingly possible to measure one-way IP performance 42 metrics with high precision. To do so in an interoperable manner, a 43 common protocol for such measurements is required. The One-Way 44 Active Measurement Protocol (OWAMP) can measure one-way delay, as 45 well as other unidirectional characteristics, such as one-way loss. 47 3. Motivation and Goals 49 The IETF IP Performance Metrics (IPPM) working group has proposed 50 draft standard metrics for one-way packet delay [RFC2679] and loss 51 [RFC 2680] across Internet paths. Although there are now several 52 measurement platforms that implement collection of these metrics 53 [SURVEYOR], [RIPE], there is not currently a standard that would 54 permit initiation of test streams or exchange of packets to collect 55 singleton metrics in an interoperable manner. 57 With the increasingly wide availability of affordable global 58 positioning system (GPS) and CDMA based time sources, hosts 59 increasingly have available to them very accurate time 60 sources--either directly or through their proximity to NTP primary 61 (stratum 1) time servers. By standardizing a technique for 62 collecting IPPM one-way active measurements, we hope to create an 63 environment where IPPM metrics may be collected across a far broader 64 mesh of Internet paths than is currently possible. One particularly 65 compelling vision is of widespread deployment of open OWAMP servers 66 that would make measurement of one-way delay as commonplace as 67 measurement of round-trip time using an ICMP-based tool like ping. 69 Additional design goals of OWAMP include being hard to detect and 70 manipulate, security, logical separation of control and test 71 functionality, and support for small test packets. 73 OWAMP test traffic is hard to detect, because it is simply a stream 74 of UDP packets from and to negotiated port numbers with potentially 75 nothing static in the packets (size is negotiated, too). 76 Additionally, OWAMP supports an encrypted mode, that further obscures 77 the traffic, at the same time making it impossible to alter 78 timestamps undetectably. 80 Security features include optional authentication and/or encryption 81 of control and test messages. These features may be useful to 82 prevent unauthorized access to results or man-in-the-middle attackers 83 who attempt to provide special treatment to OWAMP test streams or who 84 attempt to modify sender-generated timestamps to falsify test 85 results. 87 3.1. Relationship of Test and Control Protocols 89 OWAMP actually consists of two inter-related protocols: OWAMP-Control 90 and OWAMP-Test. OWAMP-Control is used to initiate, start and stop 91 test sessions and fetch their results, while OWAMP-Test is used to 92 exchange test packets between two measurement nodes. 94 Although OWAMP-Test may be used in conjunction with a control 95 protocol other than OWAMP-Control, the authors have deliberately 96 chosen to include both protocols in the same draft to encourage the 97 implementation and deployment of OWAMP-Control as a common 98 denominator control protocol for one-way active measurements. Having 99 a complete and open one-way active measurement solution that is 100 simple to implement and deploy is crucial to assuring a future in 101 which inter-domain one-way active measurement could become as 102 commonplace as ping. We neither anticipate nor recommend that OWAMP- 103 Control form the foundation of a general purpose extensible 104 measurement and monitoring control protocol. 106 OWAMP-Control is designed to support the negotiation of one-way 107 active measurement sessions and results retrieval in a 108 straightforward manner. At session initiation, there is a negotiation 109 of sender and receiver addresses and port numbers, session start 110 time, session length, test packet size, the mean Poisson sampling 111 interval for the test stream, and some attributes of the very general 112 RFC 2330 notion of `packet type', including packet size and per-hop 113 behavior (PHB) [RFC2474], which could be used to support the 114 measurement of one-way active across diff-serv networks. 115 Additionally, OWAMP-Control supports per-session encryption and 116 authentication for both test and control traffic, measurement servers 117 which may act as proxies for test stream endpoints, and the exchange 118 of a seed value for the pseudo-random Poisson process that describes 119 the test stream generated by the sender. 121 We believe that OWAMP-Control can effectively support one-way active 122 measurement in a variety of environments, from publicly accessible 123 measurement `beacons' running on arbitrary hosts to network 124 monitoring deployments within private corporate networks. If 125 integration with SNMP or proprietary network management protocols is 126 required, gateways may be created. 128 3.2. Logical Model 130 Several roles are logically separated to allow for broad flexibility 131 in use. Specifically, we define: 133 Session-Sender the sending endpoint of an OWAMP-Test session; 135 Session-Receiver the receiving endpoint of an OWAMP-Test session; 137 Server an end system that manages one or more OWAMP-Test 138 sessions, is capable of configuring per-session 139 state in session endpoints, and is capable of 140 returning the results of a test session; 142 Control-Client an end system that initiates requests for 143 OWAMP-Test sessions, triggers the start of a set 144 of sessions, and may trigger their termination; 146 Fetch-Client an end system that initiates requests to fetch 147 the results of completed OWAMP-Test sessions; 149 One possible scenario of relationships between these roles is shown 150 below. 152 +----------------+ +------------------+ 153 | Session-Sender |--OWAMP-Test-->| Session-Receiver | 154 +----------------+ +------------------+ 155 ^ ^ 156 | | 157 | | 158 | | 159 | +----------------+<----------------+ 160 | | Server |<-------+ 161 | +----------------+ | 162 | ^ | 163 | | | 164 | OWAMP-Control OWAMP-Control 165 | | | 166 v v v 167 +----------------+ +-----------------+ 168 | Control-Client | | Fetch-Client | 169 +----------------+ +-----------------+ 171 (Unlabeled links in the figure are unspecified by this draft and may 172 be proprietary protocols.) 174 Different logical roles can be played by the same host. For example, 175 in the figure above, there could actually be only two hosts: one 176 playing the roles of Control-Client, Fetch-Client, and Session- 177 Sender, and the other playing the roles of Server and Session- 178 Receiver. This is shown below. 180 +-----------------+ +------------------+ 181 | Control-Client |<--OWAMP-Control-->| Server | 182 | Fetch-Client | | | 183 | Session-Sender |---OWAMP-Test----->| Session-Receiver | 184 +-----------------+ +------------------+ 186 Finally, because many Internet paths include segments that transport 187 IP over ATM, delay and loss measurements can include the effects of 188 ATM segmentation and reassembly (SAR). Consequently, OWAMP has been 189 designed to allow for small test packets that would fit inside the 190 payload of a single ATM cell (this is only achieved in 191 unauthenticated and encrypted modes). 193 4. Protocol Overview 195 As described above, OWAMP consists of two inter-related protocols: 196 OWAMP-Control and OWAMP-Test. The former is layered over TCP and is 197 used to initiate and control measurement sessions and to fetch their 198 results. The latter protocol is layered over UDP and is used to send 199 singleton measurement packets along the Internet path under test. 201 The initiator of the measurement session establishes a TCP connection 202 to a well-known port on the target point and this connection remains 203 open for the duration of the OWAMP-Test sessions. IANA will be 204 requested to allocate a well-known port number for OWAMP-Control 205 sessions. An OWAMP server SHOULD listen to this well-known port. 207 OWAMP-Control messages are transmitted only before OWAMP-Test 208 sessions are actually started and after they complete (with the 209 possible exception of an early Stop-Session message). 211 The OWAMP-Control and OWAMP-Test protocols support three modes of 212 operation: unauthenticated, authenticated, and encrypted. The 213 authenticated or encrypted modes require endpoints to possess a 214 shared secret. 216 All multi-octet quantities defined in this document are represented 217 as unsigned integers in network byte order unless specified 218 otherwise. 220 5. OWAMP-Control 222 Each type of OWAMP-Control message has a fixed length. The recipient 223 will know the full length of a message after examining first 16 224 octets of it. No message is shorter than 16 octets. 226 If the full message is not received within 30 minutes after it is 227 expected, connection SHOULD be dropped. 229 5.1. Connection Setup 231 Before either a Control-Client or a Fetch-Client can issue commands 232 of a Server, it must establish a connection to the server. 234 First, a client opens a TCP connection to the server on a well-known 235 port. The server responds with a server greeting: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 | Unused (12 octets) | 242 | | 243 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Modes | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 | Challenge (16 octets) | 248 | | 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 The following mode values are meaningful: 1 for unauthenticated, 2 253 for authenticated, 4 for encrypted. The value of the Modes field 254 sent by the server is the bit-wise OR of the mode values that it is 255 willing to support during this session. Thus, last three bits of the 256 Modes 32-bit value are used. The first 29 bits MUST be zero. A 257 client MUST ignore the values in the first 29 bits of the Modes 258 value. (This way, the bits are available for future protocol 259 extensions. This is the only intended extension mechanism.) 261 Challenge is a random sequence of octets generated by the server; it 262 is used subsequently by the client to prove possession of a shared 263 secret in a manner prescribed below. 265 If Modes value is zero, the server doesn't wish to communicate with 266 the client and MAY close the connection immediately. The client 267 SHOULD close the connection if it gets a greeting with Modes equal to 268 zero. The client MAY close the connection if the client's desired 269 mode is unavailable. 271 Otherwise, the client MUST respond with the following message: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Mode | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 . . 280 . Username (16 octets) . 281 . . 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 . . 286 . Token (32 octets) . 287 . . 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 . . 292 . Client-IV (16 octets) . 293 . . 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Here Mode is the mode that the client chooses to use during this 298 OWAMP-Control session. It will also be used for all OWAMP-Test 299 sessions started under control of this OWAMP-Control session. In 300 Mode, one or zero bits MUST be set within last three bits. The first 301 29 bits of Mode MUST be zero. A server MUST ignore the values of the 302 first 29 bits. 304 In unauthenticated mode, Username, Token, and Client-IV are unused. 306 Otherwise, Username is a 16-octet indicator of which shared secret 307 the client wishes to use to authenticate or encrypt and Token is the 308 concatenation of a 16-octet challenge and a 16-octet Session-key, 309 encrypted using the AES (Advanced Encryption Standard) [AES] in 310 Cipher Block Chaining (CBC). Encryption MUST be performed using an 311 Initialization Vector (IV) of zero and a key value that is the shared 312 secret associated with Username. (Both the server and the client use 313 the same mappings from user names to secret keys; the server, being 314 prepared to conduct sessions with more than one client, uses user 315 names to choose the appropriate secret key; a client would typically 316 have different secret keys for different servers. The situation is 317 analogous to that of passwords, except that secret keys, rather than 318 being the typical low-entropy passwords, are suitable for use as AES 319 keys.) The shared secret will typically be provided as a passphrase; 320 in this case, the MD5 sum [RFC1321] of the passphrase (without 321 possible newline character(s) at the end of the passphrase) SHOULD be 322 used as a key for encryption by the client and decryption by the 323 server (the passphrase also SHOULD NOT contain newlines in the 324 middle). 326 Session-key and Client-IV are generated randomly by the client. 327 Session-key MUST be generated with sufficient entropy not to reduce 328 the security of the underlying cipher. Client-IV merely needs to be 329 unique (i.e., it MUST never be repeated for different sessions using 330 the same secret key; a simple way to achieve that without the use of 331 cumbersome state is to generate the Client-IV strings using a 332 cryptographically secure pseudo-random number source: if this is 333 done, the first repetition is unlikely to occur before 2^64 sessions 334 with the same secret key are conducted). 336 The server MUST respond with the following message: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 | Unused, MBZ (15 octets) | 343 | | 344 | +-+-+-+-+-+-+-+-+ 345 | | Accept | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 | Server-IV (16 octets) | 349 | | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Uptime (Timestamp) | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Integrity Zero Padding (8 octets) | 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 The Unused 15-octet part MUST be zero. The client MUST ignore its 360 value. MBZ (MUST be zero) fields here and hereafter have the same 361 semantics: the party that sends the message MUST set the field to a 362 string of zero bits; the party that interprets the message MUST 363 ignore the value. (This way the field could be used for future 364 extensions.) 366 Server-IV is generated randomly by the server. In unauthenticated 367 mode, Server-IV is unused. 369 A zero value in the Accept field means that the server accepts the 370 authentication and is willing to conduct further transactions. A 371 value of 1 means that the server does not accept the authentication 372 provided by the client or, for some other reason, is not willing to 373 conduct further transactions in this OWAMP-Control session. All 374 other values are reserved. The client MUST interpret all values of 375 Accept other than 0 and 1 as 1. This way, other values are available 376 for future extensions. If a negative response is sent, the server 377 MAY and the client SHOULD close the connection after this message. 379 Uptime is a timestamp representing the time when the current 380 instantiation of the server started operating. (For example, in a 381 multi-user general purpose operating system, it could be the time 382 when the server process was started.) If Accept is non-zero, Uptime 383 SHOULD be set to a string of zeros. In authenticated and encrypted 384 modes, Uptime is encrypted as described in the next section, unless 385 Accept is non-zero. (authenticated and encrypted mode can not be 386 entered unless the control connection can be initialized.) 388 Timestamp format is described in `Sender Behavior' section below. 389 The same instantiation of the server SHOULD report the same exact 390 Uptime value to each client in each session. 392 Integrity Zero Padding is treated the same way as Integrity Zero 393 Padding in the next section and beyond. 395 The previous transactions constitute connection setup. 397 5.2. OWAMP-Control Commands 399 In authenticated or encrypted mode (which are identical as far as 400 OWAMP-Control is concerned, and only differ in OWAMP-Test) all 401 further communications are encrypted with the Session-key, using CBC 402 mode. The client encrypts its stream using Client-IV. The server 403 encrypts its stream using Server-IV. 405 The following commands are available for the client: Request-Session, 406 Start-Sessions, Stop-Session, Fetch-Session. The command Stop- 407 Session is available to both the client and the server. (The server 408 can also send other messages in response to commands it receives.) 410 After Start-Sessions is sent/received by the client/server, and 411 before it both sends and receives Stop-Session (order unspecified), 412 it is said to be conducting active measurements. 414 While conducting active measurements, the only command available is 415 Stop-Session. 417 These commands are described in detail below. 419 5.3. Creating Test Sessions 421 Individual one-way active measurement sessions are established using 422 a simple request/response protocol. An OWAMP client MAY issue zero or 423 more Request-Session messages to an OWAMP server, which MUST respond 424 to each with an Accept-Session message. An Accept-Session message 425 MAY refuse a request. 427 The format of Request-Session message is as follows: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Number of Schedule Slots | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Number of Packets | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Sender Port | Receiver Port | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Sender Address | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | | 443 | Sender Address (cont.) or MBZ | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Receiver Address | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 | Receiver Address (cont.) or MBZ | 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 | SID (16 octets) | 454 | | 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Padding Length | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Start Time | 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Timeout | 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type-P Descriptor | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | MBZ | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 | Integrity Zero Padding (16 octets) | 472 | | 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 This is immediately followed by one or more schedule slot 477 descriptions (the number of schedule slots is specified in the 478 `Number of Schedule Slots' field above): 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Slot Type | | 484 +-+-+-+-+-+-+-+-+ MBZ | 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Slot Parameter (Timestamp) | 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 These are immediately followed by Integrity Zero Padding: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | 497 | Integrity Zero Padding (16 octets) | 498 | | 499 | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 All these messages comprise one logical message: the Request-Session 503 command. 505 Above, the first octet (1) indicates that this is Request-Session 506 command. 508 IPVN is the IP version numbers for Sender and Receiver. In the case 509 of IP version number being 4, twelve octets follow the four-octet 510 IPv4 address stored in Sender Address and Receiver address. These 511 octets MUST be set to zero by the client and MUST be ignored by the 512 server. Currently meaningful IPVN values are 4 and 6. 514 Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. 515 The server MUST interpret any non-zero value as 1. If the value is 516 1, the server is being asked to configure the corresponding agent 517 (sender or receiver). In this case, the corresponding Port value 518 SHOULD be disregarded by the server. At least one of Conf-Sender and 519 Conf-Receiver MUST be 1. (Both can be set, in which case the server 520 is being asked to perform a session between two hosts it can 521 configure.) 523 Number of Schedule Slots, as mentioned before, specifies the number 524 of slot records that go between the two blocks of Integrity Zero 525 Padding. It is used by the sender to determine when to send test 526 packets (see next section). 528 Number of Packets is the number of active measurement packets to be 529 sent during this OWAMP-Test session (note that both server and client 530 can abort the session early). 532 If Conf-Sender is not set, Sender Port is the UDP port OWAMP-Test 533 packets will be sent from. If Conf-Receiver is not set, Receiver 534 Port is the UDP port OWAMP-Test packets are requested to be sent to. 536 The Sender Address and Receiver Address fields contain respectively 537 the sender and receiver addresses of the end points of the Internet 538 path over which an OWAMP test session is requested. 540 SID is the session identifier. It can be used in later sessions as 541 an argument for Fetch-Session command. It is meaningful only if 542 Conf-Receiver is 0. This way, the SID is always generated by the 543 receiving side. See the end of the section for information on how 544 the SID is generated. 546 Padding length is the number of octets to be appended to normal 547 OWAMP-Test packet (see more on padding in discussion of OWAMP-Test). 549 Start Time is the time when the session is to be started (but not 550 before Start-Sessions command is issued). This timestamp is in the 551 same format as OWAMP-Test timestamps. 553 Timeout (or a loss threshold) is an interval of time (expressed as a 554 timestamp). A packet belonging to the test session that is being set 555 up by the current Request-Session command will be considered lost if 556 it is not received during Timeout seconds after it is sent. 558 Type-P Descriptor covers only a subset of (very large) Type-P space. 559 If the first two bits of Type-P Descriptor are 00, then subsequent 6 560 bits specify the requested Differentiated Services Codepoint (DSCP) 561 value of sent OWAMP-Test packets as defined in RFC 2474. If the 562 first two bits of Type-P descriptor are 01, then subsequent 16 bits 563 specify the requested Per Hop Behavior Identification Code (PHB ID) 564 as defined in RFC 2836. 566 Therefore, the value of all zeros specifies the default best-effort 567 service. 569 If Conf-Sender is set, Type-P Descriptor is to be used to configure 570 the sender to send packets according to its value. If Conf-Sender is 571 not set, Type-P Descriptor is a declaration of how the sender will be 572 configured. 574 If Conf-Sender is set and the server doesn't recognize Type-P 575 Descriptor, cannot or does not wish to set the corresponding 576 attributes on OWAMP-Test packets, it SHOULD reject the session 577 request. If Conf-Sender is not set, the server SHOULD accept the 578 session regardless of the value of Type-P Descriptor. 580 Integrity Zero Padding MUST be all zeros in this and all subsequent 581 messages that use zero padding. The recipient of a message where 582 zero padding is not zero MUST reject the message as it is an 583 indication of tampering with the content of the message by an 584 intermediary (or brokenness). If the message is part of OWAMP- 585 Control, the session MUST be terminated and results invalidated. If 586 the message is part of OWAMP-Test, it MUST be silently ignored. This 587 will ensure data integrity. In unauthenticated mode, Integrity Zero 588 Padding is nothing more than a simple check. In authenticated and 589 encrypted modes, however, it ensures, in conjunction with properties 590 of CBC chaining mode, that everything received before was not 591 tampered with. For this reason, it is important to check the 592 Integrity Zero Padding Field as soon as possible, so that bad data 593 doesn't get propagated. 595 To each Request-Session message, an OWAMP server MUST respond with an 596 Accept-Session message: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Accept | Unused | Port | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 603 | | 604 | SID (16 octets) | 605 | | 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 | Integrity Zero Padding (12 octets) | 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 In this message, zero in the Accept field means that the server is 614 willing to conduct the session. A value of 1 indicates rejection of 615 the request. All other values are reserved. 617 If the server rejects a Request-Session command, it SHOULD not close 618 the TCP connection. The client MAY close it if it gets negative 619 response to Request-Session. 621 The meaning of Port in the response depends on the values of Conf- 622 Sender and Conf-Receiver in the query that solicited the response. 623 If both were set, Port field is unused. If only Conf-Sender was set, 624 Port is the port to expect OWAMP-Test packets from. If only Conf- 625 Receiver was set, Port is the port to send OWAMP-Test packets to. 627 If only Conf-Sender was set, SID field in the response is unused. 628 Otherwise, SID is a unique server-generated session identifier. It 629 can be used later as handle to fetch the results of a session. 631 SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number 632 belonging to the generating machine, 8-octet timestamp, and 4-octet 633 random value. To reduce the probability of collisions, if the 634 generating machine has any IPv4 addresses (with the exception of 635 loopback), one of them SHOULD be used for SID generation, even if all 636 communication is IPv6-based. If it has no IPv4 addresses at all, the 637 last 4 octets of an IPv6 address can be used instead. Note that SID 638 is always chosen by the receiver. If truly random values are not 639 available, it is important that SID be made unpredictable as 640 knowledge of SID might be used for access control. 642 5.4. Send Schedules 644 The sender and the receiver need to both know the same send schedule. 645 This way, when packets are lost, the receiver knows when they were 646 supposed to be sent. It is desirable to compress common schedules 647 and still to be able to use an arbitrary one for the test sessions. 648 In many cases, the schedule will consist of repeated sequences of 649 packets: this way, the sequence performs some test, and the test is 650 repeated a number of times to gather statistics. 652 To implement this, we have a schedule with a given number of `slots'. 653 Each slots has a type and a parameter. Two types are supported: 654 exponentially distributed pseudo-random quantity (denoted by a code 655 of 0) and a fixed quantity (denoted by a code of 1). The parameter 656 is expressed as a timestamp and specifies a time interval. For a 657 type 0 slot (exponentially distributed pseudo-random quantity) this 658 interval is the mean value (or 1/lambda if the distribution density 659 function is expressed as lambda*exp(-lambda*x) for positive values of 660 x). For a type 1 slot, the parameter is the delay itself. The 661 sender starts with the beginning of the schedule, and `executes' the 662 instructions in the slots: for a slot of type 0, wait exponentially 663 distributed time with mean of the specified parameter and then send a 664 test packet (and proceed to the next slot); for a slot of type 1, 665 wait the specified time and send a test packet (and proceed to the 666 next slot). The schedule is circular: when there are no more slots, 667 the sender returns to the first slot. 669 The sender and the receiver must be able to reproducibly execute the 670 entire schedule (so if a packet is lost, the receiver can still 671 attach a send timestamp to it). Slots of type 1 are trivial to 672 reproducibly execute. To reproducibly execute slots of type 0, we 673 need to be able to generate pseudo-random exponentially distributed 674 quantities in a reproducible manner. The way this is accomplished is 675 discussed later. 677 Using this mechanism one can easily specify common testing scenarios: 679 + Poisson stream: a single slot of type 0; 681 + Periodic stream: a single slot of type 1; 683 + Poisson stream of back-to-back packet pairs: two slots -- type 0 684 with a non-zero parameter and type 1 with a zero parameter. 686 A completely arbitrary schedule can be specified (albeit 687 inefficiently) by making the number of test packets equal to the 688 number of schedule slots. In this case, the complete schedule is 689 transmitted in advance of an OWAMP-Test session. 691 5.5. Starting Test Sessions 693 Having requested one or more test sessions and received affirmative 694 Accept-Session responses, an OWAMP client may start the execution of 695 the requested test sessions by sending a Start-Sessions message to 696 the server. 698 The format of this message is as follows: 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | 2 | | 704 +-+-+-+-+-+-+-+-+ | 705 | Unused (15 octets) | 706 | | 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | | 710 | Integrity Zero Padding (16 octets) | 711 | | 712 | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 The server MUST respond with an Control-Ack message (which SHOULD be 716 sent as quickly as possible). Control-Ack messages have the following 717 format: 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Accept | | 723 +-+-+-+-+-+-+-+-+ | 724 | Unused (15 octets) | 725 | | 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | | 729 | Integrity Zero Padding (16 octets) | 730 | | 731 | | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 If Accept is 1, the Start-Sessions request was rejected; zero means 735 that the command was accepted. All other values are reserved. The 736 server MAY and the client SHOULD close the connection in the case of 737 a negative response. 739 The server SHOULD start all OWAMP-Test streams immediately after it 740 sends the response or immediately after their specified start times, 741 whichever is later. (Note that a client can effect an immediate 742 start by specifying in Request-Session a Start Time in the past.) If 743 the client represents a Sender, the client SHOULD start its OWAMP- 744 Test streams immediately after it sees the Control-Ack response from 745 the Server. 747 5.6. Stop-Sessions 749 The Stop-Sessions message may be issued by either the Control-Client 750 or the Server. The format of this command is as follows: 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | 3 | Accept | Unused | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Number of Sessions | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Unused (8 octets) | 760 | | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 | Integrity Zero Padding (16 octets) | 764 | | 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 This is immediately followed by 0 or more session packets sent 769 descriptions (the number of session packets sent records is specified 770 in the 'Number of Sessions' field above): 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 775 | | 776 | SID (16 octets) | 777 | | 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Session Packets Sent | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | 783 | Integrity Zero Padding (12 octets) | 784 | | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 All these messages comprise one logical message: the Stop-Session 788 command. 790 Above, the first octet (3) indicates that this is the Stop-Session 791 command. 793 Accept values of 1 indicate a failure of some sort. Zero values 794 indicate normal (but possibly premature) completion. All other 795 values are reserved. 797 If Accept had a non-zero value (from either party) results of all 798 OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be 799 considered invalid, even if a Fetch-Session with SID from this 800 session works for a different OWAMP-Control session. If Accept was 801 not transmitted at all (for whatever reason, including the TCP 802 connection used for OWAMP-Control breaking), the results of all 803 OWAMP-Test sessions spawned by this OWAMP-control session MAY be 804 considered invalid. 806 Number of Sessions indicates the number of session packets sent 807 records that immediately follow the Stop-Sessions message. 809 Number of Sessions MUST contain the number of send sessions started 810 by the local side of the control connection that have not been 811 previously terminated by a Stop-Sessions command. (i.e. The Control- 812 Client MUST account for each accepted Request-Session where Conf- 813 Receiver was set. The Control-Server MUST account for each accepted 814 Request-Session where Conf-Sender was set.) If the Stop-Sessions 815 message does not account for all the send sessions controlled by that 816 side, then it is to be considered invalid and the connection SHOULD 817 be closed and any results obtained considered invalid. 819 Each session packets sent record represents one OWAMP-Test session 820 and contains the session identifier (SID) and the number of packets 821 sent in that session. For completed sessions, Session Packets Sent 822 will equal NumPackets from the Request-Session. Session Packets Sent 823 MAY be all ones (0xFFFFFFFF); in this case, the sender of the Stop- 824 Sessions command could not determine the number of packets sent 825 (perhaps, due to some internal error such as a process crash); this 826 special value SHOULD NOT be sent under normal operating conditions. 828 If the OWAMP-Control connection associated with an OWAMP-Test 829 receiver receives the (0xFFFFFFFF) special value for the Session 830 Packets Sent, or if the OWAMP-Control connection breaks when the 831 Stop-Sessions command is sent, the receiver MAY not completely 832 invalidate the session results. It MUST discard any records of lost 833 packets that follow (in other words, have greater sequence number 834 than) the last packet that was actually received. This will help 835 differentiate between packet losses that occurred in the network and 836 the sender crashing. When the results of such an OWAMP-Test session 837 or an OWAMP-Test session that was prematurely aborted successfully 838 (with confirmation) are later fetched using Fetch-Session, the 839 original number of packets MUST be supplied in the reproduction of 840 the Request-Session command. 842 If a receiver of an OWAMP-Test session learns through OWAMP-Control 843 Stop-Sessions message that the OWAMP-Test sender's last sequence 844 number is lower than any sequence number actually received, the 845 results of the complete OWAMP-Test session MUST be invalidated. 847 A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control 848 Stop-Sessions command, MUST discard any packet records -- including 849 lost packet records -- with a (computed) send time that falls between 850 the current time minus Timeout and the current time. This ensures 851 statistical consistency for the measurement of loss and duplicates in 852 the event that the Timeout is greater than the time it takes for the 853 Stop-Sessions command to take place. 855 To effect complete sessions, each side of the control connection 856 SHOULD wait until all Sessions are complete before sending the Stop- 857 Sessions message. The completed time of each sessions is determined 858 as Timeout after the scheduled time for the last sequence number. 859 Endpoints MAY add a small increment to the computed completed time 860 for send endpoints to ensure the Stop-Sessions message reaches the 861 receiver endpoint after Timeout. 863 To effect a premature stop of sessions, the party that initiates this 864 command MUST stop its OWAMP-Test send streams to send the Session 865 Packets Sent values before sending this command. That party SHOULD 866 wait until receiving the response Stop-Sessions message before 867 stopping the receiver streams so that it can use the values from the 868 received Stop-Sessions message to validate the data. 870 5.7. Fetch-Session 872 The format of this client command is as follows: 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | 4 | | 878 +-+-+-+-+-+-+-+-+ | 879 | Unused (7 octets) | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Begin Seq | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | End Seq | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | | 886 | SID (16 octets) | 887 | | 888 | | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | 891 | Integrity Zero Padding (16 octets) | 892 | | 893 | | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Begin Seq is the sequence number of the first requested packet. End 897 Seq is the sequence number of the last requested packet. If Begin 898 Seq is all zeros and End Seq is all ones, complete session is said to 899 be requested. 901 If a complete session is requested and the session is still in 902 progress, or has terminated in any way other than normal, the request 903 to fetch session results MUST be denied. If an incomplete session is 904 requested, all packets received so far that fall into the requested 905 range SHOULD be returned. Note that since no commands can be issued 906 between Start-Sessions and Stop-Sessions, incomplete requests can 907 only happen on a different OWAMP-Control connection (from the same or 908 different host as Control-Client). 910 The server MUST respond with a Control-Ack message. Again, 1 in the 911 Accept field means rejection of command. Zero means that data will 912 follow. All other values are reserved. 914 If Accept was 0, the server then MUST send the OWAMP-Test session 915 data in question, followed by 16 octets of Integrity Zero Padding. 917 The OWAMP-Test session data consists of the following (concatenated): 919 + A reproduction of the Request-Session command that was used to 920 start the session; it is modified so that actual sender and 921 receiver port numbers that were used by the OWAMP-Test session 922 always appear in the reproduction. 924 + The number of packet records that will follow represented as an 925 unsigned 4-octet integer. This number might be less than the 926 Number of Packets in the reproduction of the Request-Session 927 command because of a session that ended prematurely; or it might 928 be greater because of duplicates. 930 + 12 octets of Integrity Zero Padding. 932 + Zero or more (as specified) packet records. 934 Each packet record is 25 octets, and includes 4 octets of sequence 935 number, 8 octets of send timestamp, 2 octets of send timestamp error 936 estimate, 8 octets of receive timestamp, and 2 octets of receive 937 timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6): 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 00| Seq Number | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 04| Send Timestamp | 945 08| | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 12| Send Error Estimate | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 949 16| Receive Timestamp | 950 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 20| | Receive Error Estimate | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 24| TTL | 954 +-+-+-+-+-+-+-+-+ 956 Packet records are sent out in the same order they are made when the 957 results of the session are recorded. Therefore, the data is in 958 arrival order. 960 Note that lost packets (if any losses were detected during the OWAMP- 961 Test session) MUST appear in the sequence of packets. They can 962 appear either at the point when the loss was detected or at any later 963 point. Lost packet records are distinguished as follows: 965 + A send timestamp filled with the presumed send time (as computed 966 by the send schedule). 968 + A send error estimate filled with Multiplier=1, Scale=64, and S=0 969 (see the OWAMP-Test description for definition of these quantities 970 and explanation of timestamp format and error estimate format). 972 + A receive timestamp consisting of all zero bits. 974 + A normal receive error estimate as determined by the error of the 975 clock being used to declare the packet lost (it MUST be declared 976 lost if it is not received Timeout after the presumed send time as 977 determined by the receivers clock). 979 + A TTL value of 255. 981 The last (possibly full, possibly incomplete) block (16 octets) of 982 data is padded with zeros if necessary. (These zeros are simple 983 padding and should be distinguished from the 16 octets of Integrity 984 Zero Padding that follow the session data and conclude the response 985 to Fetch-Session.) 987 6. OWAMP-Test 989 This section describes OWAMP-Test protocol. It runs over UDP using 990 sender and receiver IP and port numbers negotiated during Request- 991 Session exchange. 993 As OWAMP-Control, OWAMP-Test has three modes: unauthenticated, 994 authenticated, and encrypted. All OWAMP-Test sessions spawned by an 995 OWAMP-Control session inherit its mode. 997 OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and 998 OWAMP-Test receiver can potentially all be different machines. (In a 999 typical case we expect that there will be only two machines.) 1001 6.1. Sender Behavior 1003 The sender sends the receiver a stream of packets with schedule as 1004 specified in the Request-Session command. The sender SHOULD set the 1005 TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The 1006 format of the body of a UDP packet in the stream depends on the mode 1007 being used. 1009 For unauthenticated mode: 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Sequence Number | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Timestamp | 1017 | | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Error Estimate | | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1021 | | 1022 . . 1023 . Packet Padding . 1024 . . 1025 | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 For authenticated and encrypted modes: 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Sequence Number | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | | 1036 | Integrity Zero Padding (12 octets) | 1037 | | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Timestamp | 1040 | | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Error Estimate | | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1044 | Integrity Zero Padding (6 octets) | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | | 1047 . . 1048 . Packet Padding . 1049 . . 1050 | | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 The format of the timestamp is the same as in RFC 1305 and is as 1054 follows: first 32 bits represent the unsigned integer number of 1055 seconds elapsed since 0h on 1 January 1900; next 32 bits represent 1056 the fractional part of a second that has elapsed since then. 1058 So, Timestamp is represented as follows: 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Integer part of seconds | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Fractional part of seconds | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 The Error Estimate specifies the estimate of the error and 1069 synchronization. It has the following format: 1071 0 1 1072 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 |S|Z| Scale | Multiplier | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 The first bit S SHOULD be set if the party generating the timestamp 1078 has a clock that is synchronized to UTC using an external source 1079 (e.g., the bit should be set if GPS hardware is used and it indicates 1080 that it has acquired current position and time or if NTP is used and 1081 it indicates that it has synchronized to an external source, which 1082 includes stratum 0 source, etc.); if there is no notion of external 1083 synchronization for the time source, the bit SHOULD NOT be set. The 1084 next bit has the same semantics as MBZ fields elsewhere: it MUST be 1085 set to zero by the sender and ignored by everyone else. The next six 1086 bits Scale form an unsigned integer; Multiplier is an unsigned 1087 integer as well. They are interpreted as follows: the error estimate 1088 is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation 1089 clarification: 2^Scale is two to the power of Scale.] Multiplier 1090 MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be 1091 considered corrupt and discarded. 1093 Sequence numbers start with 0 and are incremented by 1 for each 1094 subsequent packet. 1096 The minimum data segment length is therefore 14 octets in 1097 unauthenticated mode, and 32 octets in authenticated mode and 1098 encrypted modes. 1100 The OWAMP-Test packet layout is the same in authenticated and 1101 encrypted modes. The encryption operations are, however, different. 1102 The difference is that in encrypted mode both the sequence number and 1103 the timestamp are encrypted to provide maximum data integrity 1104 protection while in authenticated mode the sequence number is 1105 encrypted and the timestamp is sent in clear text. Sending the 1106 timestamp in clear text in authenticated mode allows to reduce the 1107 time between a timestamp is obtained by a sender and the packet is 1108 shipped out. In encrypted mode, the sender has to fetch the 1109 timestamp, encrypt it, and send it; in authenticated mode, the middle 1110 step is removed improving accuracy (the sequence number can be 1111 encrypted before the timestamp is fetched). 1113 In authenticated mode, the first block (16 octets) of each packet is 1114 encrypted using AES ECB mode. The key to use is the same key as is 1115 used for the corresponding OWAMP-Control session (where it is used in 1116 a different chaining mode). Electronic Cookbook (ECB) mode does not 1117 involve any actual chaining; this way, lost, duplicated, or reordered 1118 packets do not cause problems with deciphering any packet in an 1119 OWAMP-Test session. 1121 In encrypted mode, the first two blocks (32 octets) are encrypted 1122 using AES CBC mode. The key to use is the same key as is used for 1123 the corresponding OWAMP-Control session. Each OWAMP-Test packet is 1124 encrypted as a separate stream, with just one chaining operation; 1125 chaining does not span multiple packets so that lost, duplicated, or 1126 reordered packets do not cause problems. 1128 In unauthenticated mode, no encryption is applied. 1130 Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be 1131 generated independently of any other pseudo-random numbers mentioned 1132 in this document). However, implementations MUST provide a 1133 configuration parameter, an option, or a different means of making 1134 Packet Padding consist of all zeros. 1136 The time elapsed between packets is computed according to the slot 1137 schedule as mentioned in Request-Session command description. At 1138 that point we skipped over the issue of computing exponentially 1139 distributed pseudo-random numbers in a reproducible fashion. 1141 7. Receiver Behavior 1143 Receiver knows when the sender will send packets. The following 1144 parameter is defined: Timeout (from Request-Session). Packets that 1145 are delayed by more than Timeout are considered lost (or `as good as 1146 lost'). Note that there is never an actual assurance of loss by the 1147 network: a `lost' packet might still be delivered at any time. The 1148 original specification for IPv4 required that packets be delivered 1149 within TTL seconds or never (with TTL having a maximum value of 255). 1150 To the best of the authors' knowledge, this requirement was never 1151 actually implemented (and of course only a complete and universal 1152 implementation would ensure that packets don't travel for longer than 1153 TTL seconds). In fact, in IPv6 the name of this field has actually 1154 been changed to Hop Limit. Further, IPv4 specification makes no 1155 claims about the time it takes the packet to traverse the last link 1156 of the path. 1158 The choice of a reasonable value of Timeout is a problem faced by a 1159 user of OWAMP protocol, not by an implementor. A value such as two 1160 minutes is very safe. Note that certain applications (such as 1161 interactive `one-way ping') might wish to obtain the data faster than 1162 that. 1164 As packets are received, 1166 + Timestamp the received packet. 1168 + In authenticated or encrypted mode, decrypt first block (16 1169 octets) of packet body. 1171 + Store the packet sequence number, send time, receive time, and the 1172 TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for 1173 the results to be transferred. 1175 + Packets not received within the Timeout are considered lost. They 1176 are recorded with their true seqno, presumed send time, receive 1177 time consisting of a string of zero bits, and TTL (or Hop Limit) 1178 of 255. 1180 Implementations SHOULD fetch the TTL/Hop Limit value from the IP 1181 header of the packet. If an implementation does not fetch the actual 1182 TTL value (the only good reason to not do so is inability to access 1183 the TTL field of arriving packets), it MUST record the TTL value as 1184 255. 1186 Packets that are actually received are recorded in the order of 1187 arrival. Lost packet records serve as indications of the send times 1188 of lost packets. They SHOULD be placed either at the point where the 1189 receiver learns about the loss or at any later point; in particular, 1190 one MAY place all the records that correspond to lost packets at the 1191 very end. 1193 Packets that have send time in the future MUST be recorded normally, 1194 without changing their send timestamp, unless they have to be 1195 discarded. (Send timestamps in the future would normally indicate 1196 clocks that differ by more than the delay. Some data -- such as 1197 jitter -- can be extracted even without knowledge of time difference. 1198 For other kinds of data, the adjustment is best handled by the data 1199 consumer on the basis of the complete information in a measurement 1200 session as well as possibly external data.) 1201 Packets with a sequence number that was already observed (duplicate 1202 packets) MUST be recorded normally. (Duplicate packets are sometimes 1203 introduced by IP networks. The protocol has to be able to measure 1204 duplication.) 1206 If any of the following is true, the packet MUST be discarded: 1208 + Send timestamp is more than Timeout in the past or in the future. 1210 + Send timestamp differs by more than Timeout from the time when the 1211 packet should have been sent according to its seqno. 1213 + In authenticated or encrypted mode, any of the bits of zero 1214 padding inside the first 16 octets of packet body is non-zero. 1216 8. Computing Exponentially Distributed Pseudo-Random Numbers 1218 Here we describe the way exponential random quantities used in the 1219 protocol are generated. While there is a fair number of algorithms 1220 for generating exponential random variables, most of them rely on 1221 having logarithmic function as a primitive, resulting in potentially 1222 different values, depending on the particular implementation of the 1223 math library. We use algorithm 3.4.1.S in [KNUTH], which is free 1224 of the above mentioned problem, and guarantees the same output on any 1225 implementation. The algorithm belongs to the 'ziggurat' family 1226 developed in the 1970s by G.Marsaglia, M.Sibuya and J.H.Ahrens 1227 [ZIGG]. It replaces the use of logarithmic function by clever bit 1228 manipulation, still producing the exponential variates on output. 1230 8.1. High-Level Description of the Algorithm 1232 For ease of exposition, the algorithm is first described with all 1233 arithmetic operations being interpreted in their natural sense. 1234 Later, exact details on data types, arithmetic, and generation of the 1235 uniform random variates used by the algorithm are given. It is an 1236 almost verbatim quotation from [KNUTH], p.133. 1238 Algorithm S: Given a real positive number 'mu', produce an 1239 exponential random variate with mean 'mu'. 1241 First, the constants 1243 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 1245 are computed in advance. The exact values which MUST be used by all 1246 implementations are given in the reference code (see Appendix). This 1247 is necessary to insure that exactly the same pseudo-random sequences 1248 are produced by all implementations. 1250 S1. [Get U and shift.] Generate a 32-bit uniform random binary 1251 fraction 1253 U = (.b0 b1 b2 ... b31) [note the decimal point] 1255 Locate the first zero bit b_j, and shift off the leading (j+1) bits, 1256 setting U <- (.b_{j+1} ... b31) 1258 NOTE: in the rare case that the zero has not been found it is 1259 prescribed that the algorithm return (mu*32*ln2). 1261 S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and 1262 terminate the algorithm. (Note that Q[1] = ln2.) 1264 S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k 1265 new uniform random binary fractions U1,...,Uk and set V <- 1266 min(U1,...,Uk). 1268 S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. 1270 8.2. Data Types, Representation and Arithmetic 1272 The high-level algorithm operates on real numbers -- typically 1273 represented as floating point numbers. This specification prescribes 1274 that unsigned 64-bit integers be used instead. 1276 u_int64_t integers are interpreted as real numbers by placing the 1277 decimal point after the first 32 bits. In other words, conceptually 1278 the interpretation is given by the map: 1280 u_int64_t u; 1282 u |--> (double)u / (2**32) 1284 The algorithm produces a sequence of such u_int64_t integers which is 1285 guaranteed to be the same on any implementation. Any further 1286 interpretation (such as given by (1)) is done by the application, and 1287 is not part of this specification. 1289 We specify that the u_int64_t representations of the first 11 values 1290 of the Q array in the high-level algorithm be as follows: 1292 #1 0xB17217F8, 1293 #2 0xEEF193F7, 1294 #3 0xFD271862, 1295 #4 0xFF9D6DD0, 1296 #5 0xFFF4CFD0, 1297 #6 0xFFFEE819, 1298 #7 0xFFFFE7FF, 1299 #8 0xFFFFFE2B, 1300 #9 0xFFFFFFE0, 1301 #10 0xFFFFFFFE, 1302 #11 0xFFFFFFFF 1304 For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) 1305 = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF 1307 Small integer 'j' in the high-level algorithm is represented as 1308 u_int64_t value j * (2**32); 1310 Operation of addition is done as usual on u_int64_t numbers; however, 1311 the operation of multiplication in the high-level algorithm should be 1312 replaced by 1314 (u, v) |---> (u * v) >> 32 1316 Implementations MUST compute (u * v) exactly. For example, a 1317 fragment of unsigned 128-bit arithmetic can be implemented for this 1318 purpose (see sample implementation below). 1320 8.3. Uniform Random Quantities 1322 The procedure for obtaining a sequence of 32-bit random numbers (such 1323 as 'U' in algorithm S) relies on using AES encryption in counter 1324 mode. To describe the exact working of the algorithm we introduce two 1325 primitives from Rijndael. Their prototypes and specification are 1326 given below, and they are assumed to be provided by the supporting 1327 Rijndael implementation, such as [RIJN]. 1329 + This function initializes a Rijndael key with bytes from 'seed' 1331 void KeyInit(unsigned char seed[16]); 1333 + This function encrypts the 16-octet block 'inblock' with the 'key' 1334 returning a 16-octet encrypted block. Here 'keyInstance' is an 1335 opaque type used to represent Rijndael keys. 1337 void BlockEncrypt(keyInstance key, unsigned char inblock[16]); 1339 Algorithm Unif: given a 16-octet quantity seed, produce a sequence of 1340 unsigned 32-bit pseudo-random uniformly distributed integers. In 1341 OWAMP, the SID (session ID) from Control protocol plays the role of 1342 seed. 1344 U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an 1345 unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need 1346 more random bytes?] Set i <- c mod 4. If (i == 0) set s <- 1347 BlockEncrypt(key, c) 1349 U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1 1351 U4. [Do output] Output the i_th quartet of octets from s starting 1352 from high-order octets, converted to native byte order and 1353 represented as OWPNum64 value (as in 3.b). 1355 U5. [Loop] Go to step U2. 1357 9. Security Considerations 1359 The goal of authenticated mode to let one passphrase-protect service 1360 provided by a particular OWAMP-Control server. One can imagine a 1361 variety of circumstances where this could be useful. Authenticated 1362 mode is designed to prohibit theft of service. 1364 Additional design objective of authenticated mode was to make it 1365 impossible for an attacker who cannot read traffic between OWAMP-Test 1366 sender and receiver to tamper with test results in a fashion that 1367 affects the measurements, but not other traffic. 1369 The goal of encrypted mode is quite different: To make it hard for a 1370 party in the middle of the network to make results look `better' than 1371 they should be. This is especially true if one of client and server 1372 doesn't coincide with neither sender nor receiver. 1374 Encryption of OWAMP-Control using AES CBC mode with blocks of zeros 1375 after each message aims to achieve two goals: (i) to provide secrecy 1376 of exchange; (ii) to provide authentication of each message. 1378 OWAMP-Test sessions directed at an unsuspecting party could be used 1379 for denial of service (DoS) attacks. In unauthenticated mode servers 1380 should limits receivers to hosts they control or to the OWAMP-Control 1381 client. 1383 OWAMP-Test sessions could be used as covert channels of information. 1384 Environments that are worried about covert channels should take this 1385 into consideration. 1387 Notice that AES in counter mode is used for pseudo-random number 1388 generation, so implementation of AES MUST be included even in a 1389 server that only supports unauthenticated mode. 1391 9.1. An OWAMP server can consume resources of various kinds. The two 1392 most important kinds of resources are network capacity and memory 1393 (primary or secondary) for storing test results. 1395 Any implementation of OWAMP server MUST include technical mechanisms 1396 to limit the use of network capacity and memory. Mechanisms for 1397 managing the resources consumed by unauthenticated users and users 1398 authenticated with a username and passphrase SHOULD be separate. The 1399 default configuration of an implementation MUST enable these 1400 mechanisms and set the resource use limits to conservatively low 1401 values. 1403 One way to design the resource limitation mechanisms is as follows: 1404 assign each session to a user class. User classes are partially 1405 ordered with ``includes'' relation, with one class (``all users'') 1406 that is always present and that includes any other class. The 1407 assignment of a session to a user class can be based on the presence 1408 of authentication of the session, the user name, IP address range, 1409 time of day, and, perhaps, other factors. Each user class would have 1410 a limit for usage of network capacity (specified in units of 1411 bit/second) and memory for storing test results (specified in units 1412 of octets). Along with the limits for resource use, current use 1413 would be tracked by the server. When a session is requested by a 1414 user in a specific user class, the resources needed for this session 1415 are computed: the average network capacity use (based on the sending 1416 schedule) and the maximum memory use (based on the number of packets 1417 and number of octets each packet would need to be stored internally 1418 -- note that outgoing sessions would not require any memory use). 1419 These resource use numbers are added to the current resource use 1420 numbers for the given user class; if such addition would take the 1421 resource use outside of the limits for the given user class, the 1422 session is rejected. When resources are reclaimed, corresponding 1423 measures are subtracted from the current use. Network capacity is 1424 reclaimed as soon as the session ends. Memory is reclaimed when the 1425 data is deleted. For unauthenticated sessions, memory consumed by an 1426 OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control 1427 connection that initiated the session is closed (gracefully or 1428 otherwise). For authenticated sessions, the administrator who 1429 configures the service should be able to decide the exact policy, but 1430 useful policy mechanisms that MAY be implemented are the ability to 1431 automatically reclaim memory when the data is retrieved and the 1432 ability to reclaim memory after a certain configurable (based on user 1433 class) period of time passes after the OWAMP-Test session terminates. 1435 10. IANA Considerations 1437 IANA is requested to allocate a well-known TCP port number for OWAMP- 1438 Control part of the OWAMP protocol. 1440 11. Internationalization Considerations 1442 The protocol does not carry any information in a natural language. 1444 12. Appendix A: Sample Implementation of Exponential Deviate Computation 1446 /* 1447 ** Example usage: generate a stream of exponential (mean 1) 1448 ** random quantities (ignoring error checking during initialization). 1449 ** If a variate with some mean mu other than 1 is desired, the output 1450 ** of this algorithm can be multiplied by mu according to the rules 1451 ** of arithmetic we described. 1453 ** Assume that a 16-octet 'seed' has been initialized 1454 ** (as the shared secret in OWAMP, for example) 1455 ** unsigned char seed[16]; 1457 ** OWPrand_context next; 1459 ** (initialize state) 1460 ** OWPrand_context_init(&next, seed); 1462 ** (generate a sequence of exponential variates) 1463 ** while (1) { 1464 ** u_int64_t num = OWPexp_rand64(&next); 1465 1466 ... 1467 ** } 1468 */ 1470 #include 1472 typedef u_int64_t u_int64_t; 1474 /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ 1475 #define K 12 1477 #define BIT31 0x80000000UL /* see if first bit in the lower 1478 32 bits is zero */ 1479 #define MASK32(n) ((n) & 0xFFFFFFFFUL) 1480 #define EXP2POW32 0x100000000ULL 1482 typedef struct OWPrand_context { 1483 unsigned char counter[16]; /* 16-octet counter (network byte order) */ 1484 keyInstance key; /* key used to encrypt the counter. */ 1485 unsigned char out[16]; /* the encrypted block is kept there. */ 1486 } OWPrand_context; 1488 /* 1489 ** The array has been computed according to the formula: 1490 ** 1491 ** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) 1492 ** 1493 ** as described in algorithm S. (The values below have been 1494 ** multiplied by 2^32 and rounded to the nearest integer.) 1495 ** These exact values MUST be used so that different implementation 1496 ** produce the same sequences. 1497 */ 1498 static u_int64_t Q[K] = { 1499 0, /* Placeholder - so array indices start from 1. */ 1500 0xB17217F8, 1501 0xEEF193F7, 1502 0xFD271862, 1503 0xFF9D6DD0, 1504 0xFFF4CFD0, 1505 0xFFFEE819, 1506 0xFFFFE7FF, 1507 0xFFFFFE2B, 1508 0xFFFFFFE0, 1509 0xFFFFFFFE, 1510 0xFFFFFFFF 1511 }; 1513 /* this element represents ln2 */ 1514 #define LN2 Q[1] 1516 /* 1517 ** Convert an unsigned 32-bit integer into a u_int64_t number.. 1518 */ 1519 u_int64_t 1520 OWPulong2num64(u_int32_t a) 1521 { 1522 return ((u_int64_t)1 << 32) * a; 1523 } 1525 /* 1526 ** Arithmetic functions on u_int64_t numbers. 1527 */ 1528 /* 1529 ** Addition. 1530 */ 1531 u_int64_t 1532 OWPnum64_add(u_int64_t x, u_int64_t y) 1533 { 1534 return x + y; 1535 } 1537 /* 1538 ** Multiplication. Allows overflow. Straightforward implementation 1539 ** of Algorithm 4.3.1.M (p.268) from [KNUTH] 1540 */ 1541 u_int64_t 1542 OWPnum64_mul(u_int64_t x, u_int64_t y) 1543 { 1544 unsigned long w[4]; 1545 u_int64_t xdec[2]; 1546 u_int64_t ydec[2]; 1548 int i, j; 1549 u_int64_t k, t, ret; 1551 xdec[0] = MASK32(x); 1552 xdec[1] = MASK32(x>>32); 1553 ydec[0] = MASK32(y); 1554 ydec[1] = MASK32(y>>32); 1556 for (j = 0; j < 4; j++) 1557 w[j] = 0; 1559 for (j = 0; j < 2; j++) { 1560 k = 0; 1561 for (i = 0; ; ) { 1562 t = k + (xdec[i]*ydec[j]) + w[i + j]; 1563 w[i + j] = t%EXP2POW32; 1564 k = t/EXP2POW32; 1565 if (++i < 2) 1566 continue; 1567 else { 1568 w[j + 2] = k; 1569 break; 1570 } 1571 } 1572 } 1574 ret = w[2]; 1575 ret <<= 32; 1576 return w[1] + ret; 1577 } 1579 /* 1580 ** Seed the random number generator using a 16-byte quantity 'seed' 1581 ** (== the session ID in OWAMP). This function implements step U1 1582 ** of algorithm Unif. 1583 */ 1585 void 1586 OWPrand_context_init(OWPrand_context *next, unsigned char *seed) 1587 { 1588 int i; 1590 /* Initialize the key */ 1591 rijndaelKeyInit(next->key, seed); 1593 /* Initialize the counter with zeros */ 1594 memset(next->out, 0, 16); 1595 for (i = 0; i < 16; i++) 1596 next->counter[i] = 0UL; 1597 } 1599 /* 1600 ** Random number generating functions. 1601 */ 1603 /* 1604 ** Generate and return a 32-bit uniform random string (saved in the less 1605 ** significant half of the u_int64_t). This function implements steps U2-U4 1606 ** of the algorithm Unif. 1607 */ 1608 u_int64_t 1609 OWPunif_rand64(OWPrand_context *next) 1610 { 1611 int j; 1612 u_int8_t *buf; 1613 u_int64_t ret = 0; 1615 /* step U2 */ 1616 u_int8_t i = next->counter[15] & (u_int8_t)3; 1617 if (!i) 1618 rijndaelEncrypt(next->key, next->counter, next->out); 1620 /* Step U3. Increment next.counter as a 16-octet single quantity 1621 in network byte order for AES counter mode. */ 1623 for (j = 15; j >= 0; j--) 1624 if (++next->counter[j]) 1625 break; 1627 /* Step U4. Do output. The last 4 bytes of ret now contain the 1628 random integer in network byte order */ 1629 buf = &next->out[4*i]; 1630 for(j=0;j<4;j++){ 1631 ret <<= 8; 1632 ret += *buf++; 1633 } 1634 return ret; 1635 } 1637 /* 1638 ** Generate a mean 1 exponential deviate. 1639 */ 1640 u_int64_t 1641 OWPexp_rand64(OWPrand_context *next) 1642 { 1644 unsigned long i, k; 1645 u_int32_t j = 0; 1646 u_int64_t U, V, J, tmp; 1648 /* Step S1. Get U and shift */ 1649 U = OWPunif_rand64(next); 1651 while ((U & BIT31) && (j < 32)){ /* shift until find first '0' */ 1652 U <<= 1; 1653 j++; 1654 } 1655 /* remove the '0' itself */ 1656 U <<= 1; 1658 U = MASK32(U); /* Keep only the fractional part. */ 1659 J = OWPulong2num64(j); 1661 /* Step S2. Immediate acceptance? */ 1662 if (U < LN2) /* return (j*ln2 + U) */ 1663 return OWPnum64_add(OWPnum64_mul(J, LN2), U); 1665 /* Step S3. Minimize. */ 1666 for (k = 2; k < K; k++) 1667 if (U < Q[k]) 1668 break; 1669 V = OWPunif_rand64(next); 1670 for (i = 2; i <= k; i++){ 1671 tmp = OWPunif_rand64(next); 1672 if (tmp < V) 1673 V = tmp; 1674 } 1676 /* Step S4. Return (j+V)*ln2 */ 1677 return OWPnum64_mul(OWPnum64_add(J, V), LN2); 1678 } 1680 13. Appendix B: Test Vectors for Exponential Deviates 1682 It is important that the test schedules generated by different 1683 implementations from identical inputs be identical. The non-trivial 1684 part is the generation of pseudo-random exponentially distributed 1685 deviates. To aid implementors in verifying interoperability, several 1686 test vectors are provided. For each of the four given 128-bit values 1687 of SID represented as hexadecimal numbers, 1,000,000 exponentially 1688 distributed 64-bit deviates are generated as described above. As 1689 they are generated, they are all added to each other. The sum of all 1690 1,000,000 deviates is given as a hexadecimal number for each SID. An 1691 implementation MUST produce exactly these hexadecimal numbers. To 1692 aid in the verification of the conversion of these numbers to values 1693 of delay in seconds, approximate values are given (assuming 1694 lambda=1). An implementation SHOULD produce delay values in seconds 1695 that are close to the ones given below. 1697 SID = 0x2872979303ab47eeac028dab3829dab2 1698 SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds) 1700 SID = 0x0102030405060708090a0b0c0d0e0f00 1701 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds) 1703 SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef 1704 SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) 1706 SID = 0xfeed0feed1feed2feed3feed4feed5ab 1707 SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) 1709 14. Normative References 1711 [AES] Advanced Encryption Standard (AES), 1712 http://csrc.nist.gov/encryption/aes/ 1714 [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, 1715 Implementation and Analysis', RFC 1305, March 1992. 1717 [RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321, 1718 April 1992. 1720 [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', 1721 RFC 2026, October 1996. 1723 [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate 1724 Requirement Levels', RFC 2119, March 1997. 1726 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for 1727 IP Performance Metrics' RFC 2330, May 1998. 1729 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of 1730 the Differentiated Services Field (DS Field) in the IPv4 and 1731 IPv6 Headers', RFC 2474, December 1998. 1733 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay 1734 Metric for IPPM', RFC 2679, September 1999. 1736 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet 1737 Loss Metric for IPPM', RFC 2680, September 1999. 1739 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior 1740 Identification Codes', RFC 2836, May 2000. 1742 15. Informative References 1744 [ZIGG] G. Marsaglia, M. Sibuya and J.H. Ahrens, Communications of 1745 ACM, 15 (1972), 876-877 1747 [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd 1748 edition, 1998 1750 [RIJN] Reference ANSI C implementation of Rijndael 1751 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip 1753 [RIPE] RIPE NCC Test-Traffic Measurements home, 1754 http://www.ripe.net/test-traffic/. 1756 [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay 1757 Measurements Using Test-Traffic', Spring 1998 Dutch Unix User 1758 Group Meeting, http://www.ripe.net/test- 1759 traffic/Talks/9805_nluug.ps.gz. 1761 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 1763 [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An 1764 Infrastructure for Network Performance Measurements', 1765 Proceedings of INET'99, June 1999. 1766 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 1768 16. Authors' Addresses 1770 Stanislav Shalunov 1772 Benjamin Teitelbaum 1774 Anatoly Karp 1776 Jeff Boote 1778 Matthew J. Zekauskas 1780 Expiration date: January 2005