idnits 2.17.1 draft-ietf-ippm-owdp-08.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 (May 2004) is 7284 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 1495 -- Looks like a reference, but probably isn't: '16' on line 1403 == Missing Reference: 'Loop' is mentioned on line 1316, but not defined == Missing Reference: 'K' is mentioned on line 1416, but not defined -- Looks like a reference, but probably isn't: '4' on line 1463 -- Looks like a reference, but probably isn't: '2' on line 1493 -- Looks like a reference, but probably isn't: '0' on line 1472 -- Looks like a reference, but probably isn't: '15' on line 1534 -- Looks like a reference, but probably isn't: '1000000' on line 1623 == Unused Reference: 'RFC1305' is defined on line 1630, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1636, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1639, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 1642, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1652, but no explicit reference was found in the text == Unused Reference: 'RFC2836' is defined on line 1655, but no explicit reference was found in the text == Unused Reference: 'RIPE-NLUUG' is defined on line 1672, but no explicit reference was found in the text == Unused Reference: 'SURVEYOR-INET' is defined on line 1679, 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: November 2004 Anatoly Karp 5 Jeff W. Boote 6 Matthew J. Zekauskas 7 Internet2 8 May 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. The shared secret will typically be 313 provided as a passphrase; in this case, the MD5 sum [RFC1321] of the 314 passphrase (without possible newline character(s) at the end of the 315 passphrase) SHOULD be used as a key for encryption by the client and 316 decryption by the server (the passphrase also SHOULD NOT contain 317 newlines in the middle). 319 Session-key and Client-IV are generated randomly by the client. 321 The server MUST respond with the following message: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 | Unused, MBZ (15 octets) | 328 | | 329 | +-+-+-+-+-+-+-+-+ 330 | | Accept | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 | Server-IV (16 octets) | 334 | | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Uptime (Timestamp) | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Integrity Zero Padding (8 octets) | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 The Unused 15-octet part MUST be zero. The client MUST ignore its 345 value. 347 Server-IV is generated randomly by the server. In unauthenticated 348 mode, Server-IV is unused. 350 A zero value in the Accept field means that the server accepts the 351 authentication and is willing to conduct further transactions. A 352 value of 1 means that the server does not accept the authentication 353 provided by the client or, for some other reason, is not willing to 354 conduct further transactions in this OWAMP-Control session. All 355 other values are reserved. The client MUST interpret all values of 356 Accept other than 0 and 1 as 1. This way, other values are available 357 for future extensions. If a negative response is sent, the server 358 MAY and the client SHOULD close the connection after this message. 360 Uptime is a timestamp representing the time when the current 361 instantiation of the server started operating. (For example, in a 362 multi-user general purpose operating system, it could be the time 363 when the server process was started.) If Accept is non-zero, Uptime 364 SHOULD be set to a string of zeros. In authenticated and encrypted 365 modes, Uptime is encrypted as described in the next section, unless 366 Accept is non-zero. (authenticated and encrypted mode can not be 367 entered unless the control connection can be initialized.) 368 Timestamp format is described in `Sender Behavior' section below. 369 The same instantiation of the server SHOULD report the same exact 370 Uptime value to each client in each session. 372 Integrity Zero Padding is treated the same way as Integrity Zero 373 Padding in the next section and beyond. 375 The previous transactions constitute connection setup. 377 5.2. OWAMP-Control Commands 379 In authenticated or encrypted mode (which are identical as far as 380 OWAMP-Control is concerned, and only differ in OWAMP-Test) all 381 further communications are encrypted with the Session-key, using CBC 382 mode. The client encrypts its stream using Client-IV. The server 383 encrypts its stream using Server-IV. 385 The following commands are available for the client: Request-Session, 386 Start-Sessions, Stop-Session, Fetch-Session. The command Stop- 387 Session is available to both the client and the server. (The server 388 can also send other messages in response to commands it receives.) 390 After Start-Sessions is sent/received by the client/server, and 391 before it both sends and receives Stop-Session (order unspecified), 392 it is said to be conducting active measurements. 394 While conducting active measurements, the only command available is 395 Stop-Session. 397 These commands are described in detail below. 399 5.3. Creating Test Sessions 401 Individual one-way active measurement sessions are established using 402 a simple request/response protocol. An OWAMP client MAY issue zero or 403 more Request-Session messages to an OWAMP server, which MUST respond 404 to each with an Accept-Session message. An Accept-Session message 405 MAY refuse a request. 407 The format of Request-Session message is as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Number of Schedule Slots | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Number of Packets | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Sender Port | Receiver Port | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Sender Address | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 | Sender Address (cont.) or MBZ | 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Receiver Address | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | | 429 | Receiver Address (cont.) or MBZ | 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 | SID (16 octets) | 434 | | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Padding Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Start Time | 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Timeout | 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type-P Descriptor | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | MBZ | 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 | Integrity Zero Padding (16 octets) | 452 | | 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 This is immediately followed by one or more schedule slot 457 descriptions (the number of schedule slots is specified in the 458 `Number of Schedule Slots' field above): 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Slot Type | | 464 +-+-+-+-+-+-+-+-+ MBZ | 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Slot Parameter (Timestamp) | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 These are immediately followed by Integrity Zero Padding: 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 | Integrity Zero Padding (16 octets) | 478 | | 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 All these messages comprise one logical message: the Request-Session 483 command. 485 Above, the first octet (1) indicates that this is Request-Session 486 command. 488 IPVN is the IP version numbers for Sender and Receiver. In the case 489 of IP version number being 4, twelve octets follow the four-octet 490 IPv4 address stored in Sender Address and Receiver address. These 491 octets MUST be set to zero by the client and MUST be ignored by the 492 server. Currently meaningful IPVN values are 4 and 6. 494 Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. 495 The server MUST interpret any non-zero value as 1. If the value is 496 1, the server is being asked to configure the corresponding agent 497 (sender or receiver). In this case, the corresponding Port value 498 SHOULD be disregarded by the server. At least one of Conf-Sender and 499 Conf-Receiver MUST be 1. (Both can be set, in which case the server 500 is being asked to perform a session between two hosts it can 501 configure.) 503 Number of Schedule Slots, as mentioned before, specifies the number 504 of slot records that go between the two blocks of Integrity Zero 505 Padding. It is used by the sender to determine when to send test 506 packets (see next section). 508 Number of Packets is the number of active measurement packets to be 509 sent during this OWAMP-Test session (note that both server and client 510 can abort the session early). 512 If Conf-Sender is not set, Sender Port is the UDP port OWAMP-Test 513 packets will be sent from. If Conf-Receiver is not set, Receiver 514 Port is the UDP port OWAMP-Test packets are requested to be sent to. 516 The Sender Address and Receiver Address fields contain respectively 517 the sender and receiver addresses of the end points of the Internet 518 path over which an OWAMP test session is requested. 520 SID is the session identifier. It can be used in later sessions as 521 an argument for Fetch-Session command. It is meaningful only if 522 Conf-Receiver is 0. This way, the SID is always generated by the 523 receiving side. See the end of the section for information on how 524 the SID is generated. 526 Padding length is the number of octets to be appended to normal 527 OWAMP-Test packet (see more on padding in discussion of OWAMP-Test). 529 Start Time is the time when the session is to be started (but not 530 before Start-Sessions command is issued). This timestamp is in the 531 same format as OWAMP-Test timestamps. 533 Timeout (or a loss threshold) is an interval of time (expressed as a 534 timestamp). A packet belonging to the test session that is being set 535 up by the current Request-Session command will be considered lost if 536 it is not received during Timeout seconds after it is sent. 538 Type-P Descriptor covers only a subset of (very large) Type-P space. 539 If the first two bits of Type-P Descriptor are 00, then subsequent 6 540 bits specify the requested Differentiated Services Codepoint (DSCP) 541 value of sent OWAMP-Test packets as defined in RFC 2474. If the 542 first two bits of Type-P descriptor are 01, then subsequent 16 bits 543 specify the requested Per Hop Behavior Identification Code (PHB ID) 544 as defined in RFC 2836. 546 Therefore, the value of all zeros specifies the default best-effort 547 service. 549 If Conf-Sender is set, Type-P Descriptor is to be used to configure 550 the sender to send packets according to its value. If Conf-Sender is 551 not set, Type-P Descriptor is a declaration of how the sender will be 552 configured. 554 If Conf-Sender is set and the server doesn't recognize Type-P 555 Descriptor, cannot or does not wish to set the corresponding 556 attributes on OWAMP-Test packets, it SHOULD reject the session 557 request. If Conf-Sender is not set, the server SHOULD accept the 558 session regardless of the value of Type-P Descriptor. 560 Integrity Zero Padding MUST be all zeros in this and all subsequent 561 messages that use zero padding. The recipient of a message where 562 zero padding is not zero MUST reject the message as it is an 563 indication of tampering with the content of the message by an 564 intermediary (or brokenness). If the message is part of OWAMP- 565 Control, the session MUST be terminated and results invalidated. If 566 the message is part of OWAMP-Test, it MUST be silently ignored. This 567 will ensure data integrity. In unauthenticated mode, Integrity Zero 568 Padding is nothing more than a simple check. In authenticated and 569 encrypted modes, however, it ensures, in conjunction with properties 570 of CBC chaining mode, that everything received before was not 571 tampered with. For this reason, it is important to check the 572 Integrity Zero Padding Field as soon as possible, so that bad data 573 doesn't get propagated. 575 To each Request-Session message, an OWAMP server MUST respond with an 576 Accept-Session message: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Accept | Unused | Port | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 583 | | 584 | SID (16 octets) | 585 | | 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 | Integrity Zero Padding (12 octets) | 590 | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 In this message, zero in the Accept field means that the server is 594 willing to conduct the session. A value of 1 indicates rejection of 595 the request. All other values are reserved. 597 If the server rejects a Request-Session command, it SHOULD not close 598 the TCP connection. The client MAY close it if it gets negative 599 response to Request-Session. 601 The meaning of Port in the response depends on the values of Conf- 602 Sender and Conf-Receiver in the query that solicited the response. 603 If both were set, Port field is unused. If only Conf-Sender was set, 604 Port is the port to expect OWAMP-Test packets from. If only Conf- 605 Receiver was set, Port is the port to send OWAMP-Test packets to. 607 If only Conf-Sender was set, SID field in the response is unused. 608 Otherwise, SID is a unique server-generated session identifier. It 609 can be used later as handle to fetch the results of a session. 611 SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number 612 belonging to the generating machine, 8-octet timestamp, and 4-octet 613 random value. To reduce the probability of collisions, if the 614 generating machine has any IPv4 addresses (with the exception of 615 loopback), one of them SHOULD be used for SID generation, even if all 616 communication is IPv6-based. If it has no IPv4 addresses at all, the 617 last 4 octets of an IPv6 address can be used instead. Note that SID 618 is always chosen by the receiver. If truly random values are not 619 available, it is important that SID be made unpredictable as 620 knowledge of SID might be used for access control. 622 5.4. Send Schedules 624 The sender and the receiver need to both know the same send schedule. 625 This way, when packets are lost, the receiver knows when they were 626 sent. It is desirable to compress common schedules and still to be 627 able to use an arbitrary one for the test sessions. In many cases, 628 the schedule will consist of repeated sequences of packets: this way, 629 the sequence performs some test, and the test is repeated a number of 630 times to gather statistics. 632 To implement this, we have a schedule with a given number of `slots'. 633 Each slots has a type and a parameter. Two types are supported: 634 exponentially distributed pseudo-random quantity (denoted by a code 635 of 0) and a fixed quantity (denoted by a code of 1). The parameter 636 is expressed as a timestamp and specifies a time interval. For a 637 type 0 slot (exponentially distributed pseudo-random quantity) this 638 interval is the mean value (or 1/lambda if the distribution density 639 function is expressed as lambda*exp(-lambda*x) for positive values of 640 x). For a type 1 slot, the parameter is the delay itself. The 641 sender starts with the beginning of the schedule, and `executes' the 642 instructions in the slots: for a slot of type 0, wait exponentially 643 distributed time with mean of the specified parameter and then send a 644 test packet (and proceed to the next slot); for a slot of type 1, 645 wait the specified time and send a test packet (and proceed to the 646 next slot). The schedule is circular: when there are no more slots, 647 the sender returns to the first slot. 649 The sender and the receiver must be able to reproducibly execute the 650 entire schedule (so if a packet is lost, the receiver can still 651 attach a send timestamp to it). Slots of type 1 are trivial to 652 reproducibly execute. To reproducibly execute slots of type 0, we 653 need to be able to generate pseudo-random exponentially distributed 654 quantities in a reproducible manner. The way this is accomplished is 655 discussed later. 657 Using this mechanism one can easily specify common testing scenarios: 659 + Poisson stream: a single slot of type 0; 661 + Periodic stream: a single slot of type 1; 663 + Poisson stream of back-to-back packet pairs: two slots -- type 0 664 with a non-zero parameter and type 1 with a zero parameter. 666 A completely arbitrary schedule can be specified (albeit 667 inefficiently) by making the number of test packets equal to the 668 number of schedule slots. In this case, the complete schedule is 669 transmitted in advance of an OWAMP-Test session. 671 5.5. Starting Test Sessions 673 Having requested one or more test sessions and received affirmative 674 Accept-Session responses, an OWAMP client may start the execution of 675 the requested test sessions by sending a Start-Sessions message to 676 the server. 678 The format of this message is as follows: 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | 2 | | 684 +-+-+-+-+-+-+-+-+ | 685 | Unused (15 octets) | 686 | | 687 | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 | Integrity Zero Padding (16 octets) | 691 | | 692 | | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 The server MUST respond with an Control-Ack message (which SHOULD be 696 sent as quickly as possible). Control-Ack messages have the following 697 format: 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Accept | | 703 +-+-+-+-+-+-+-+-+ | 704 | Unused (15 octets) | 705 | | 706 | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | | 709 | Integrity Zero Padding (16 octets) | 710 | | 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 If Accept is 1, the Start-Sessions request was rejected; zero means 715 that the command was accepted. All other values are reserved. The 716 server MAY and the client SHOULD close the connection in the case of 717 a negative response. 719 The server SHOULD start all OWAMP-Test streams immediately after it 720 sends the response or immediately after their specified start times, 721 whichever is later. (Note that a client can effect an immediate 722 start by specifying in Request-Session a Start Time in the past.) If 723 the client represents a Sender, the client SHOULD start its OWAMP- 724 Test streams immediately after it sees the Control-Ack response from 725 the Server. 727 5.6. Stop-Sessions 729 The Stop-Sessions message may be issued by either the Control-Client 730 or the Server. The format of this command is as follows: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | 3 | Accept | Unused | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Number of Sessions | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Unused (8 octets) | 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | | 743 | Integrity Zero Padding (16 octets) | 744 | | 745 | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 This is immediately followed by 0 or more session packets sent 749 descriptions (the number of session packets sent records is specified 750 in the 'Number of Sessions' field above): 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 | | 756 | SID (16 octets) | 757 | | 758 | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Session Packets Sent | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 | Integrity Zero Padding (12 octets) | 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 All these messages comprise one logical message: the Stop-Session 768 command. 770 Above, the first octet (3) indicates that this is the Stop-Session 771 command. 773 Accept values of 1 indicate a failure of some sort. Zero values 774 indicate normal (but possibly premature) completion. All other 775 values are reserved. 777 If Accept had a non-zero value (from either party) results of all 778 OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be 779 considered invalid, even if a Fetch-Session with SID from this 780 session works for a different OWAMP-Control session. If Accept was 781 not transmitted at all (for whatever reason, including the TCP 782 connection used for OWAMP-Control breaking), the results of all 783 OWAMP-Test sessions spawned by this OWAMP-control session MAY be 784 considered invalid. 786 Number of Sessions indicates the number of session packets sent 787 records that immediately follow the Stop-Sessions message. 789 Number of Sessions MUST contain the number of send sessions started 790 by the local side of the control connection that have not been 791 previously terminated by a Stop-Sessions command. (i.e. The Control- 792 Client MUST account for each accepted Request-Session where Conf- 793 Receiver was set. The Control-Server MUST account for each accepted 794 Request-Session where Conf-Sender was set.) If the Stop-Sessions 795 message does not account for all the send sessions controlled by that 796 side, then it is to be considered invalid and the connection SHOULD 797 be closed and any results obtained considered invalid. 799 Each session packets sent record represents one OWAMP-Test session 800 and contains the session identifier (SID) and the number of packets 801 sent in that session. For completed sessions, Session Packets Sent 802 will equal NumPackets from the Request-Session. Session Packets Sent 803 MAY be all ones (0xFFFFFFFF); in this case, the sender of the Stop- 804 Sessions command could not determine the number of packets sent 805 (perhaps, due to some internal error such as a process crash); this 806 special value SHOULD NOT be sent under normal operating conditions. 808 If the OWAMP-Control connection associated with an OWAMP-Test 809 receiver receives the (0xFFFFFFFF) special value for the Session 810 Packets Sent, or if the OWAMP-Control connection breaks when the 811 Stop-Sessions command is sent, the receiver MAY not completely 812 invalidate the session results. It MUST discard any records of lost 813 packets that follow (in other words, have greater sequence number 814 than) the last packet that was actually received. This will help 815 differentiate between packet losses that occurred in the network and 816 the sender crashing. When the results of such an OWAMP-Test session 817 or an OWAMP-Test session that was prematurely aborted successfully 818 (with confirmation) are later fetched using Fetch-Session, the 819 original number of packets MUST be supplied in the reproduction of 820 the Request-Session command. 822 If a receiver of an OWAMP-Test session learns through OWAMP-Control 823 Stop-Sessions message that the OWAMP-Test sender's last sequence 824 number is lower than any sequence number actually received, the 825 results of the complete OWAMP-Test session MUST be invalidated. 827 A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control 828 Stop-Sessions command, MUST discard any packet records -- including 829 lost packet records -- with a (computed) send time that falls between 830 the current time minus timeout and the current time. This ensures 831 statistical consistency for the measurement of loss and duplicates in 832 the event that the timeout is greater than the time it takes for the 833 Stop-Sessions command to take place. 835 To effect complete sessions, each side of the control connection 836 SHOULD wait until all Sessions are complete before sending the Stop- 837 Sessions message. The completed time of each sessions is determined 838 as Timeout after the scheduled time for the last sequence number. 839 Endpoints MAY add a small increment to the computed completed time 840 for send endpoints to ensure the Stop-Sessions message reaches the 841 receiver endpoint after Timeout. 843 To effect a premature stop of sessions, the party that initiates this 844 command MUST stop its OWAMP-Test send streams to send the Session 845 Packets Sent values before sending this command. That party SHOULD 846 wait until receiving the response Stop-Sessions message before 847 stopping the receiver streams so that it can use the values from the 848 received Stop-Sessions message to validate the data. 850 5.7. Fetch-Session 852 The format of this client command is as follows: 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | 4 | | 858 +-+-+-+-+-+-+-+-+ | 859 | Unused (7 octets) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Begin Seq | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | End Seq | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | 866 | SID (16 octets) | 867 | | 868 | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | | 871 | Integrity Zero Padding (16 octets) | 872 | | 873 | | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Begin Seq is the sequence number of the first requested packet. End 877 Seq is the sequence number of the last requested packet. If Begin 878 Seq is all zeros and End Seq is all ones, complete session is said to 879 be requested. 881 If a complete session is requested and the session is still in 882 progress, or has terminated in any way other than normal, the request 883 to fetch session results MUST be denied. If an incomplete session is 884 requested, all packets received so far that fall into the requested 885 range SHOULD be returned. Note that since no commands can be issued 886 between Start-Sessions and Stop-Sessions, incomplete requests can 887 only happen on a different OWAMP-Control connection (from the same or 888 different host as Control-Client). 890 The server MUST respond with a Control-Ack message. Again, 1 in the 891 Accept field means rejection of command. Zero means that data will 892 follow. All other values are reserved. 894 If Accept was 0, the server then MUST send the OWAMP-Test session 895 data in question, followed by 16 octets of Integrity Zero Padding. 897 The OWAMP-Test session data consists of the following (concatenated): 899 + A reproduction of the Request-Session command that was used to 900 start the session; it is modified so that actual sender and 901 receiver port numbers that were used by the OWAMP-Test session 902 always appear in the reproduction. 904 + The number of packet records that will follow represented as an 905 unsigned 4-octet integer. This number might be less than the 906 Number of Packets in the reproduction of the Request-Session 907 command because of a session that ended prematurely; or it might 908 be greater because of duplicates. 910 + 12 octets of Integrity Zero Padding. 912 + Zero or more (as specified) packet records. 914 Each packet record is 25 octets, and includes 4 octets of sequence 915 number, 8 octets of send timestamp, 2 octets of send timestamp error 916 estimate, 8 octets of receive timestamp, and 2 octets of receive 917 timestamp error estimate and 1 octet of TTL (in this order): 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 00| Seq Number | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 04| Send Timestamp | 925 08| | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 12| Send Error Estimate | | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 929 16| Receive Timestamp | 930 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 20| | Receive Error Estimate | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 24| TTL | 934 +-+-+-+-+-+-+-+-+ 936 Packet records are sent out in the same order they are made when the 937 results of the session are recorded. Therefore, the data is in 938 arrival order. 940 Note that lost packets (if any losses were detected during the OWAMP- 941 Test session) MUST appear in the sequence of packets. They can 942 appear either at the point when the loss was detected or at any later 943 point. Lost packet records are distinguished by the receive 944 timestamp consisting of a string of zero bits and an error estimate 945 with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for 946 definition of these quantities and explanation of timestamp format 947 and error estimate format). 949 The last (possibly full, possibly incomplete) block (16 octets) of 950 data is padded with zeros if necessary. (These zeros are simple 951 padding and should be distinguished from the 16 octets of Integrity 952 Zero Padding that follow the session data and conclude the response 953 to Fetch-Session.) 955 6. OWAMP-Test 957 This section describes OWAMP-Test protocol. It runs over UDP using 958 sender and receiver IP and port numbers negotiated during Request- 959 Session exchange. 961 As OWAMP-Control, OWAMP-Test has three modes: unauthenticated, 962 authenticated, and encrypted. All OWAMP-Test sessions spawned by an 963 OWAMP-Control session inherit its mode. 965 OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and 966 OWAMP-Test receiver can potentially all be different machines. (In a 967 typical case we expect that there will be only two machines.) 969 6.1. Sender Behavior 971 The sender sends the receiver a stream of packets with schedule as 972 specified in the Request-Session command. The sender SHOULD set the 973 TTL in the UDP packet to 255. The format of the body of a UDP packet 974 in the stream depends on the mode being used. 976 For unauthenticated mode: 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Sequence Number | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Timestamp | 984 | | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Error Estimate | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 988 | | 989 . . 990 . Packet Padding . 991 . . 992 | | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 For authenticated and encrypted modes: 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Sequence Number | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | | 1003 | Integrity Zero Padding (12 octets) | 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Timestamp | 1007 | | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Error Estimate | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1011 | Integrity Zero Padding (6 octets) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | | 1014 . . 1015 . Packet Padding . 1016 . . 1017 | | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 The format of the timestamp is the same as in RFC 1305 and is as 1021 follows: first 32 bits represent the unsigned integer number of 1022 seconds elapsed since 0h on 1 January 1900; next 32 bits represent 1023 the fractional part of a second that has elapsed since then. 1025 So, Timestamp is represented as follows: 1026 0 1 2 3 1027 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 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Integer part of seconds | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Fractional part of seconds | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 The Error Estimate specifies the estimate of the error and 1035 synchronization. It has the following format: 1037 0 1 1038 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 |S|Z| Scale | Multiplier | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 The first bit S SHOULD be set if the party generating the timestamp 1044 has a clock that is synchronized to UTC using an external source 1045 (e.g., the bit should be set if GPS hardware is used and it indicates 1046 that it has acquired current position and time or if NTP is used and 1047 it indicates that it has synchronized to an external source, which 1048 includes stratum 0 source, etc.); if there is no notion of external 1049 synchronization for the time source, the bit SHOULD NOT be set. The 1050 next bit has the same semantics as MBZ fields elsewhere: it MUST be 1051 set to zero by the sender and ignored by everyone else. The next six 1052 bits Scale form an unsigned integer; Multiplier is an unsigned 1053 integer as well. They are interpreted as follows: the error estimate 1054 is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation 1055 clarification: 2^Scale is two to the power of Scale.] Multiplier 1056 MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be 1057 considered corrupt and discarded. 1059 Sequence numbers start with 0 and are incremented by 1 for each 1060 subsequent packet. 1062 The minimum data segment length is therefore 14 octets in 1063 unauthenticated mode, and 32 octets in authenticated mode and 1064 encrypted modes. 1066 The OWAMP-Test packet layout is the same in authenticated and 1067 encrypted modes. The encryption operations are, however, different. 1068 The difference is that in encrypted mode both the sequence number and 1069 the timestamp are encrypted to provide maximum data integrity 1070 protection while in authenticated mode the sequence number is 1071 encrypted and the timestamp is sent in clear text. Sending the 1072 timestamp in clear text in authenticated mode allows to reduce the 1073 time between a timestamp is obtained by a sender and the packet is 1074 shipped out. In encrypted mode, the sender has to fetch the 1075 timestamp, encrypt it, and send it; in authenticated mode, the middle 1076 step is removed improving accuracy (the sequence number can be 1077 encrypted before the timestamp is fetched). 1079 In authenticated mode, the first block (16 octets) of each packet is 1080 encrypted using AES ECB mode. The key to use is the same key as is 1081 used for the corresponding OWAMP-Control session (where it is used in 1082 a different chaining mode). Electronic Cookbook (ECB) mode does not 1083 involve any actual chaining; this way, lost, duplicated, or reordered 1084 packets do not cause problems with deciphering any packet in an 1085 OWAMP-Test session. 1087 In encrypted mode, the first two blocks (32 octets) are encrypted 1088 using AES CBC mode. The key to use is the same key as is used for 1089 the corresponding OWAMP-Control session. Each OWAMP-Test packet is 1090 encrypted as a separate stream, with just one chaining operation; 1091 chaining does not span multiple packets so that lost, duplicated, or 1092 reordered packets do not cause problems. 1094 In unauthenticated mode, no encryption is applied. 1096 Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be 1097 generated independently of any other pseudo-random numbers mentioned 1098 in this document). However, implementations MUST provide a 1099 configuration parameter, an option, or a different means of making 1100 Packet Padding consist of all zeros. 1102 The time elapsed between packets is computed according to the slot 1103 schedule as mentioned in Request-Session command description. At 1104 that point we skipped over the issue of computing exponentially 1105 distributed pseudo-random numbers in a reproducible fashion. 1107 7. Receiver Behavior 1109 Receiver knows when the sender will send packets. The following 1110 parameter is defined: Timeout (from Request-Session). Packets that 1111 are delayed by more than Timeout are considered lost (or `as good as 1112 lost'). Note that there is never an actual assurance of loss by the 1113 network: a `lost' packet might still be delivered at any time. The 1114 original specification for IPv4 required that packets be delivered 1115 within TTL seconds or never (with TTL having a maximum value of 255). 1116 To the best of the authors' knowledge, this requirement was never 1117 actually implemented (and of course only a complete and universal 1118 implementation would ensure that packets don't travel for longer than 1119 TTL seconds). Further, IPv4 specification makes no claims about the 1120 time it takes the packet to traverse the last link of the path. 1122 The choice of a reasonable value of Timeout is a problem faced by a 1123 user of OWAMP protocol, not by an implementor. A value such as two 1124 minutes is very safe. Note that certain applications (such as 1125 interactive `one-way ping') might wish to obtain the data faster than 1126 that. 1128 As packets are received, 1130 + Timestamp the received packet. 1132 + In authenticated or encrypted mode, decrypt first block (16 1133 octets) of packet body. 1135 + Store the packet sequence number, send time, receive time, and the 1136 TTL from the packet IP header for the results to be transferred. 1138 + Packets not received within the Timeout are considered lost. They 1139 are recorded with their true seqno, presumed send time, receive 1140 time consisting of a string of zero bits, and TTL of 255. 1142 Implementations SHOULD fetch the TTL value from the IP header of the 1143 packet. If an implementation does not fetch the actual TTL value 1144 (the only good reason to not do so is inability to access the TTL 1145 field of arriving packets), it MUST record the TTL value as 255. 1147 Packets that are actually received are recorded in the order of 1148 arrival. Lost packet records serve as indications of the send times 1149 of lost packets. They SHOULD be placed either at the point where the 1150 receiver learns about the loss or at any later point; in particular, 1151 one MAY place all the records that correspond to lost packets at the 1152 very end. 1154 Packets that have send time in the future MUST be recorded normally, 1155 without changing their send timestamp, unless they have to be 1156 discarded. (Send timestamps in the future would normally indicate 1157 clocks that differ by more than the delay. Some data -- such as 1158 jitter -- can be extracted even without knowledge of time difference. 1159 For other kinds of data, the adjustment is best handled by the data 1160 consumer on the basis of the complete information in a measurement 1161 session as well as possibly external data.) 1163 Packets with a sequence number that was already observed (duplicate 1164 packets) MUST be recorded normally. (Duplicate packets are sometimes 1165 introduced by IP networks. The protocol has to be able to measure 1166 duplication.) 1168 If any of the following is true, the packet MUST be discarded: 1170 + Send timestamp is more than Timeout in the past or in the future. 1172 + Send timestamp differs by more than Timeout from the time when the 1173 packet should have been sent according to its seqno. 1175 + In authenticated or encrypted mode, any of the bits of zero 1176 padding inside the first 16 octets of packet body is non-zero. 1178 8. Computing Exponentially Distributed Pseudo-Random Numbers 1180 Here we describe the way exponential random quantities used in the 1181 protocol are generated. While there is a fair number of algorithms 1182 for generating exponential random variables, most of them rely on 1183 having logarithmic function as a primitive, resulting in potentially 1184 different values, depending on the particular implementation of the 1185 math library. We use algorithm 3.4.1.S in [KNUTH], which is free 1186 of the above mentioned problem, and guarantees the same output on any 1187 implementation. The algorithm belongs to the 'ziggurat' family 1188 developed in the 1970s by G.Marsaglia, M.Sibuya and J.H.Ahrens 1189 [ZIGG]. It replaces the use of logarithmic function by clever bit 1190 manipulation, still producing the exponential variates on output. 1192 8.1. High-Level Description of the Algorithm 1194 For ease of exposition, the algorithm is first described with all 1195 arithmetic operations being interpreted in their natural sense. 1196 Later, exact details on data types, arithmetic, and generation of the 1197 uniform random variates used by the algorithm are given. It is an 1198 almost verbatim quotation from [KNUTH], p.133. 1200 Algorithm S: Given a real positive number 'mu', produce an 1201 exponential random variate with mean 'mu'. 1203 First, the constants 1205 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 1207 are computed in advance. The exact values which MUST be used by all 1208 implementations are given in the reference code (see Appendix). This 1209 is necessary to insure that exactly the same pseudo-random sequences 1210 are produced by all implementations. 1212 S1. [Get U and shift.] Generate a 32-bit uniform random binary 1213 fraction 1215 U = (.b0 b1 b2 ... b31) [note the decimal point] 1217 Locate the first zero bit b_j, and shift off the leading (j+1) bits, 1218 setting U <- (.b_{j+1} ... b31) 1220 NOTE: in the rare case that the zero has not been found it is 1221 prescribed that the algorithm return (mu*32*ln2). 1223 S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and 1224 terminate the algorithm. (Note that Q[1] = ln2.) 1225 S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k 1226 new uniform random binary fractions U1,...,Uk and set V <- 1227 min(U1,...,Uk). 1229 S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. 1231 8.2. Data Types, Representation and Arithmetic 1233 The high-level algorithm operates on real numbers -- typically 1234 represented as floating point numbers. This specification prescribes 1235 that unsigned 64-bit integers be used instead. 1237 u_int64_t integers are interpreted as real numbers by placing the 1238 decimal point after the first 32 bits. In other words, conceptually 1239 the interpretation is given by the map: 1241 u_int64_t u; 1243 u |--> (double)u / (2**32) 1245 The algorithm produces a sequence of such u_int64_t integers which is 1246 guaranteed to be the same on any implementation. Any further 1247 interpretation (such as given by (1)) is done by the application, and 1248 is not part of this specification. 1250 We specify that the u_int64_t representations of the first 11 values 1251 of the Q array in the high-level algorithm be as follows: 1253 #1 0xB17217F8, 1254 #2 0xEEF193F7, 1255 #3 0xFD271862, 1256 #4 0xFF9D6DD0, 1257 #5 0xFFF4CFD0, 1258 #6 0xFFFEE819, 1259 #7 0xFFFFE7FF, 1260 #8 0xFFFFFE2B, 1261 #9 0xFFFFFFE0, 1262 #10 0xFFFFFFFE, 1263 #11 0xFFFFFFFF 1265 For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) 1266 = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF 1268 Small integer 'j' in the high-level algorithm is represented as 1269 u_int64_t value j * (2**32); 1271 Operation of addition is done as usual on u_int64_t numbers; however, 1272 the operation of multiplication in the high-level algorithm should be 1273 replaced by 1275 (u, v) |---> (u * v) >> 32 1277 Implementations MUST compute (u * v) exactly. For example, a 1278 fragment of unsigned 128-bit arithmetic can be implemented for this 1279 purpose (see sample implementation below). 1281 8.3. Uniform Random Quantities 1283 The procedure for obtaining a sequence of 32-bit random numbers (such 1284 as 'U' in algorithm S) relies on using AES encryption in counter 1285 mode. To describe the exact working of the algorithm we introduce two 1286 primitives from Rijndael. Their prototypes and specification are 1287 given below, and they are assumed to be provided by the supporting 1288 Rijndael implementation, such as [RIJN]. 1290 + This function initializes a Rijndael key with bytes from 'seed' 1292 void KeyInit(unsigned char seed[16]); 1294 + This function encrypts the 16-octet block 'inblock' with the 'key' 1295 returning a 16-octet encrypted block. Here 'keyInstance' is an 1296 opaque type used to represent Rijndael keys. 1298 void BlockEncrypt(keyInstance key, unsigned char inblock[16]); 1300 Algorithm Unif: given a 16-octet quantity seed, produce a sequence of 1301 unsigned 32-bit pseudo-random uniformly distributed integers. In 1302 OWAMP, the SID (session ID) from Control protocol plays the role of 1303 seed. 1305 U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an 1306 unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need 1307 more random bytes?] Set i <- c mod 4. If (i == 0) set s <- 1308 BlockEncrypt(key, c) 1310 U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1 1312 U4. [Do output] Output the i_th quartet of octets from s starting 1313 from high-order octets, converted to native byte order and 1314 represented as OWPNum64 value (as in 3.b). 1316 U5. [Loop] Go to step U2. 1318 9. Security Considerations 1320 The goal of authenticated mode to let one passphrase-protect service 1321 provided by a particular OWAMP-Control server. One can imagine a 1322 variety of circumstances where this could be useful. Authenticated 1323 mode is designed to prohibit theft of service. 1325 Additional design objective of authenticated mode was to make it 1326 impossible for an attacker who cannot read traffic between OWAMP-Test 1327 sender and receiver to tamper with test results in a fashion that 1328 affects the measurements, but not other traffic. 1330 The goal of encrypted mode is quite different: To make it hard for a 1331 party in the middle of the network to make results look `better' than 1332 they should be. This is especially true if one of client and server 1333 doesn't coincide with neither sender nor receiver. 1335 Encryption of OWAMP-Control using AES CBC mode with blocks of zeros 1336 after each message aims to achieve two goals: (i) to provide secrecy 1337 of exchange; (ii) to provide authentication of each message. 1339 OWAMP-Test sessions directed at an unsuspecting party could be used 1340 for denial of service (DoS) attacks. In unauthenticated mode servers 1341 should limits receivers to hosts they control or to the OWAMP-Control 1342 client. 1344 OWAMP-Test sessions could be used as covert channels of information. 1345 Environments that are worried about covert channels should take this 1346 into consideration. 1348 Notice that AES in counter mode is used for pseudo-random number 1349 generation, so implementation of AES MUST be included even in a 1350 server that only supports unauthenticated mode. 1352 10. IANA Considerations 1354 IANA is requested to allocate a well-known TCP port number for OWAMP- 1355 Control part of the OWAMP protocol. 1357 11. Internationalization Considerations 1359 The protocol does not carry any information in a natural language. 1361 12. Appendix A: Sample Implementation of Exponential Deviate Computation 1363 /* 1364 ** Example usage: generate a stream of exponential (mean 1) 1365 ** random quantities (ignoring error checking during initialization). 1366 ** If a variate with some mean mu other than 1 is desired, the output 1367 ** of this algorithm can be multiplied by mu according to the rules 1368 ** of arithmetic we described. 1370 ** Assume that a 16-octet 'seed' has been initialized 1371 ** (as the shared secret in OWAMP, for example) 1372 ** unsigned char seed[16]; 1374 ** OWPrand_context next; 1376 ** (initialize state) 1377 ** OWPrand_context_init(&next, seed); 1379 ** (generate a sequence of exponential variates) 1380 ** while (1) { 1381 ** u_int64_t num = OWPexp_rand64(&next); 1382 1383 ... 1384 ** } 1385 */ 1387 #include 1389 typedef u_int64_t u_int64_t; 1391 /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ 1392 #define K 12 1394 #define BIT31 0x80000000UL /* see if first bit in the lower 1395 32 bits is zero */ 1396 #define MASK32(n) ((n) & 0xFFFFFFFFUL) 1398 #define EXP2POW32 0x100000000ULL 1400 typedef struct OWPrand_context { 1401 unsigned char counter[16]; /* 16-octet counter (network byte order) */ 1402 keyInstance key; /* key used to encrypt the counter. */ 1403 unsigned char out[16]; /* the encrypted block is kept there. */ 1404 } OWPrand_context; 1406 /* 1407 ** The array has been computed according to the formula: 1408 ** 1409 ** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) 1410 ** 1411 ** as described in algorithm S. (The values below have been 1412 ** multiplied by 2^32 and rounded to the nearest integer.) 1413 ** These exact values MUST be used so that different implementation 1414 ** produce the same sequences. 1415 */ 1416 static u_int64_t Q[K] = { 1417 0, /* Placeholder - so array indices start from 1. */ 1418 0xB17217F8, 1419 0xEEF193F7, 1420 0xFD271862, 1421 0xFF9D6DD0, 1422 0xFFF4CFD0, 1423 0xFFFEE819, 1424 0xFFFFE7FF, 1425 0xFFFFFE2B, 1426 0xFFFFFFE0, 1427 0xFFFFFFFE, 1428 0xFFFFFFFF 1429 }; 1431 /* this element represents ln2 */ 1432 #define LN2 Q[1] 1434 /* 1435 ** Convert an unsigned 32-bit integer into a u_int64_t number.. 1436 */ 1437 u_int64_t 1438 OWPulong2num64(u_int32_t a) 1439 { 1440 return ((u_int64_t)1 << 32) * a; 1441 } 1443 /* 1444 ** Arithmetic functions on u_int64_t numbers. 1445 */ 1447 /* 1448 ** Addition. 1449 */ 1450 u_int64_t 1451 OWPnum64_add(u_int64_t x, u_int64_t y) 1452 { 1453 return x + y; 1454 } 1456 /* 1457 ** Multiplication. Allows overflow. Straightforward implementation 1458 ** of Algorithm 4.3.1.M (p.268) from [KNUTH] 1459 */ 1460 u_int64_t 1461 OWPnum64_mul(u_int64_t x, u_int64_t y) 1462 { 1463 unsigned long w[4]; 1464 u_int64_t xdec[2]; 1465 u_int64_t ydec[2]; 1467 int i, j; 1468 u_int64_t k, t, ret; 1470 xdec[0] = MASK32(x); 1471 xdec[1] = MASK32(x>>32); 1472 ydec[0] = MASK32(y); 1473 ydec[1] = MASK32(y>>32); 1475 for (j = 0; j < 4; j++) 1476 w[j] = 0; 1478 for (j = 0; j < 2; j++) { 1479 k = 0; 1480 for (i = 0; ; ) { 1481 t = k + (xdec[i]*ydec[j]) + w[i + j]; 1482 w[i + j] = t%EXP2POW32; 1483 k = t/EXP2POW32; 1484 if (++i < 2) 1485 continue; 1486 else { 1487 w[j + 2] = k; 1488 break; 1489 } 1490 } 1491 } 1493 ret = w[2]; 1494 ret <<= 32; 1495 return w[1] + ret; 1496 } 1497 /* 1498 ** Seed the random number generator using a 16-byte quantity 'seed' 1499 ** (== the session ID in OWAMP). This function implements step U1 1500 ** of algorithm Unif. 1501 */ 1503 void 1504 OWPrand_context_init(OWPrand_context *next, unsigned char *seed) 1505 { 1506 int i; 1508 /* Initialize the key */ 1509 rijndaelKeyInit(next->key, seed); 1511 /* Initialize the counter with zeros */ 1512 memset(next->out, 0, 16); 1513 for (i = 0; i < 16; i++) 1514 next->counter[i] = 0UL; 1515 } 1517 /* 1518 ** Random number generating functions. 1519 */ 1521 /* 1522 ** Generate and return a 32-bit uniform random string (saved in the less 1523 ** significant half of the u_int64_t). This function implements steps U2-U4 1524 ** of the algorithm Unif. 1525 */ 1526 u_int64_t 1527 OWPunif_rand64(OWPrand_context *next) 1528 { 1529 int j; 1530 u_int8_t *buf; 1531 u_int64_t ret = 0; 1533 /* step U2 */ 1534 u_int8_t i = next->counter[15] & (u_int8_t)3; 1535 if (!i) 1536 rijndaelEncrypt(next->key, next->counter, next->out); 1538 /* Step U3. Increment next.counter as a 16-octet single quantity 1539 in network byte order for AES counter mode. */ 1540 for (j = 15; j >= 0; j--) 1541 if (++next->counter[j]) 1542 break; 1544 /* Step U4. Do output. The last 4 bytes of ret now contain the 1545 random integer in network byte order */ 1546 buf = &next->out[4*i]; 1547 for(j=0;j<4;j++){ 1548 ret <<= 8; 1549 ret += *buf++; 1550 } 1551 return ret; 1552 } 1554 /* 1555 ** Generate a mean 1 exponential deviate. 1556 */ 1557 u_int64_t 1558 OWPexp_rand64(OWPrand_context *next) 1559 { 1561 unsigned long i, k; 1562 u_int32_t j = 0; 1563 u_int64_t U, V, J, tmp; 1565 /* Step S1. Get U and shift */ 1566 U = OWPunif_rand64(next); 1568 while ((U & BIT31) && (j < 32)){ /* shift until find first '0' */ 1569 U <<= 1; 1570 j++; 1571 } 1572 /* remove the '0' itself */ 1573 U <<= 1; 1575 U = MASK32(U); /* Keep only the fractional part. */ 1576 J = OWPulong2num64(j); 1578 /* Step S2. Immediate acceptance? */ 1579 if (U < LN2) /* return (j*ln2 + U) */ 1580 return OWPnum64_add(OWPnum64_mul(J, LN2), U); 1582 /* Step S3. Minimize. */ 1583 for (k = 2; k < K; k++) 1584 if (U < Q[k]) 1585 break; 1586 V = OWPunif_rand64(next); 1587 for (i = 2; i <= k; i++){ 1588 tmp = OWPunif_rand64(next); 1589 if (tmp < V) 1590 V = tmp; 1591 } 1592 /* Step S4. Return (j+V)*ln2 */ 1593 return OWPnum64_mul(OWPnum64_add(J, V), LN2); 1594 } 1596 13. Appendix B: Test Vectors for Exponential Deviates 1598 It is important that the test schedules generated by different 1599 implementations from identical inputs be identical. The non-trivial 1600 part is the generation of pseudo-random exponentially distributed 1601 deviates. To aid implementors in verifying interoperability, several 1602 test vectors are provided. For each of the four given 128-bit values 1603 of SID represented as hexadecimal numbers, 1,000,000 exponentially 1604 distributed 64-bit deviates are generated as described above. As 1605 they are generated, they are all added to each other. The sum of all 1606 1,000,000 deviates is given as a hexadecimal number for each SID. An 1607 implementation MUST produce exactly these hexadecimal numbers. To 1608 aid in the verification of the conversion of these numbers to values 1609 of delay in seconds, approximate values are given (assuming 1610 lambda=1). An implementation SHOULD produce delay values in seconds 1611 that are close to the ones given below. 1613 SID = 0x2872979303ab47eeac028dab3829dab2 1614 SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds) 1616 SID = 0x0102030405060708090a0b0c0d0e0f00 1617 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds) 1619 SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef 1620 SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) 1622 SID = 0xfeed0feed1feed2feed3feed4feed5ab 1623 SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) 1625 14. Normative References 1627 [AES] Advanced Encryption Standard (AES), 1628 http://csrc.nist.gov/encryption/aes/ 1630 [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, 1631 Implementation and Analysis', RFC 1305, March 1992. 1633 [RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321, 1634 April 1992. 1636 [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', 1637 RFC 2026, October 1996. 1639 [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate 1640 Requirement Levels', RFC 2119, March 1997. 1642 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for 1643 IP Performance Metrics' RFC 2330, May 1998. 1645 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of 1646 the Differentiated Services Field (DS Field) in the IPv4 and 1647 IPv6 Headers', RFC 2474, December 1998. 1649 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay 1650 Metric for IPPM', RFC 2679, September 1999. 1652 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet 1653 Loss Metric for IPPM', RFC 2680, September 1999. 1655 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior 1656 Identification Codes', RFC 2836, May 2000. 1658 15. Informative References 1660 [ZIGG] G. Marsaglia, M. Sibuya and J.H. Ahrens, Communications of 1661 ACM, 15 (1972), 876-877 1663 [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd 1664 edition, 1998 1666 [RIJN] Reference ANSI C implementation of Rijndael 1667 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip 1669 [RIPE] RIPE NCC Test-Traffic Measurements home, 1670 http://www.ripe.net/test-traffic/. 1672 [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay 1673 Measurements Using Test-Traffic', Spring 1998 Dutch Unix User 1674 Group Meeting, http://www.ripe.net/test- 1675 traffic/Talks/9805_nluug.ps.gz. 1677 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 1679 [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An 1680 Infrastructure for Network Performance Measurements', 1681 Proceedings of INET'99, June 1999. 1682 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 1684 16. Authors' Addresses 1686 Stanislav Shalunov 1688 Benjamin Teitelbaum 1690 Anatoly Karp 1692 Jeff Boote 1694 Matthew J. Zekauskas 1696 Expiration date: November 2004