idnits 2.17.1 draft-ietf-ippm-owdp-06.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 233 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 2003) is 7645 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 1471 -- Looks like a reference, but probably isn't: '16' on line 1379 == Missing Reference: 'Loop' is mentioned on line 1226, but not defined == Missing Reference: 'K' is mentioned on line 1392, but not defined -- Looks like a reference, but probably isn't: '4' on line 1439 -- Looks like a reference, but probably isn't: '2' on line 1469 -- Looks like a reference, but probably isn't: '0' on line 1448 -- Looks like a reference, but probably isn't: '15' on line 1510 == Unused Reference: 'RFC1305' is defined on line 1577, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1586, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1599, but no explicit reference was found in the text == Unused Reference: 'RFC2836' is defined on line 1602, but no explicit reference was found in the text == Unused Reference: 'RIPE-NLUUG' is defined on line 1619, but no explicit reference was found in the text == Unused Reference: 'SURVEYOR-INET' is defined on line 1626, 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 (==), 10 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 2003 Anatoly Karp 5 Jeff W. Boote 6 Matthew J. Zekauskas 7 Internet2 8 May 2003 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 24 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 (in this order). Packet records are sent 918 out in the same order they are made when the results of the session 919 are recorded. Therefore, the data is in arrival order. 921 Note that lost packets (if any losses were detected during the OWAMP- 922 Test session) MUST appear in the sequence of packets. They can 923 appear either at the point when the loss was detected or at any later 924 point. Lost packet records are distinguished by the receive 925 timestamp consisting of a string of zero bits and an error estimate 926 with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for 927 definition of these quantities and explanation of timestamp format 928 and error estimate format). 930 The last (possibly full, possibly incomplete) block (16 octets) of 931 data is padded with zeros if necessary. (These zeros are simple 932 padding and should be distinguished from the 16 octets of Integrity 933 Zero Padding that follow the session data and conclude the response 934 to Fetch-Session.) 936 6. OWAMP-Test 938 This section describes OWAMP-Test protocol. It runs over UDP using 939 sender and receiver IP and port numbers negotiated during Request- 940 Session exchange. 942 As OWAMP-Control, OWAMP-Test has three modes: unauthenticated, 943 authenticated, and encrypted. All OWAMP-Test sessions spawned by an 944 OWAMP-Control session inherit its mode. 946 OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and 947 OWAMP-Test receiver can potentially all be different machines. (In a 948 typical case we expect that there will be only two machines.) 950 6.1. Sender Behavior 952 The sender sends the receiver a stream of packets with schedule as 953 specified in the Request-Session command. The format of the body of 954 a UDP packet in the stream depends on the mode being used. 956 For unauthenticated mode: 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Sequence Number | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Timestamp | 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Error Estimate | | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 968 | | 969 . . 970 . Packet Padding . 971 . . 972 | | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 For authenticated and encrypted modes: 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Sequence Number | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | | 983 | Integrity Zero Padding (12 octets) | 984 | | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Timestamp | 987 | | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Error Estimate | | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 991 | Integrity Zero Padding (6 octets) | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | | 994 . . 995 . Packet Padding . 996 . . 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 The format of the timestamp is the same as in RFC 1305 and is as 1001 follows: first 32 bits represent the unsigned integer number of 1002 seconds elapsed since 0h on 1 January 1900; next 32 bits represent 1003 the fractional part of a second that has elapsed since then. 1005 So, Timestamp is represented as follows: 1006 0 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Integer part of seconds | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Fractional part of seconds | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 The Error Estimate specifies the estimate of the error and 1015 synchronization. It has the following format: 1017 0 1 1018 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 |S|Z| Scale | Multiplier | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 The first bit S SHOULD be set if the party generating the timestamp 1024 has a clock that is synchronized to UTC using an external source 1025 (e.g., the bit should be set if GPS hardware is used and it indicates 1026 that it has acquired current position and time or if NTP is used and 1027 it indicates that it has synchronized to an external source, which 1028 includes stratum 0 source, etc.); if there is no notion of external 1029 synchronization for the time source, the bit SHOULD NOT be set. The 1030 next bit has the same semantics as MBZ fields elsewhere: it MUST be 1031 set to zero by the sender and ignored by everyone else. The next six 1032 bits Scale form an unsigned integer; Multiplier is an unsigned 1033 integer as well. They are interpreted as follows: the error estimate 1034 is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation 1035 clarification: 2^Scale is two to the power of Scale.] Multiplier 1036 MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be 1037 considered corrupt and discarded. 1039 Sequence numbers start with 0 and are incremented by 1 for each 1040 subsequent packet. 1042 The minimum data segment length is therefore 14 octets in 1043 unauthenticated mode, and 32 octets in authenticated mode and 1044 encrypted modes. 1046 The OWAMP-Test packet layout is the same in authenticated and 1047 encrypted modes. The encryption operations are, however, different. 1048 The difference is that in encrypted mode both the sequence number and 1049 the timestamp are encrypted to provide maximum data integrity 1050 protection while in authenticated mode the sequence number is 1051 encrypted and the timestamp is sent in clear text. Sending the 1052 timestamp in clear text in authenticated mode allows to reduce the 1053 time between a timestamp is obtained by a sender and the packet is 1054 shipped out. In encrypted mode, the sender has to fetch the 1055 timestamp, encrypt it, and send it; in authenticated mode, the middle 1056 step is removed improving accuracy (the sequence number can be 1057 encrypted before the timestamp is fetched). 1059 In authenticated mode, the first block (16 octets) of each packet is 1060 encrypted using AES ECB mode. The key to use is the same key as is 1061 used for the corresponding OWAMP-Control session (where it is used in 1062 a different chaining mode). Electronic Cookbook (ECB) mode does not 1063 involve any actual chaining; this way, lost, duplicated, or reordered 1064 packets do not cause problems with deciphering any packet in an 1065 OWAMP-Test session. 1067 In encrypted mode, the first two blocks (32 octets) are encrypted 1068 using AES CBC mode. The key to use is the same key as is used for 1069 the corresponding OWAMP-Control session. Each OWAMP-Test packet is 1070 encrypted as a separate stream, with just one chaining operation; 1071 chaining does not span multiple packets so that lost, duplicated, or 1072 reordered packets do not cause problems. 1074 In unauthenticated mode, no encryption is applied. 1076 Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be 1077 generated independently of any other pseudo-random numbers mentioned 1078 in this document). However, implementations MUST provide a 1079 configuration parameter, an option, or a different means of making 1080 Packet Padding consist of all zeros. 1082 The time elapsed between packets is computed according to the slot 1083 schedule as mentioned in Request-Session command description. At 1084 that point we skipped over the issue of computing exponentially 1085 distributed pseudo-random numbers in a reproducible fashion. 1087 7. Computing Exponentially Distributed Pseudo-Random Numbers 1089 Here we describe the way exponential random quantities used in the 1090 protocol are generated. While there is a fair number of algorithms 1091 for generating exponential random variables, most of them rely on 1092 having logarithmic function as a primitive, resulting in potentially 1093 different values, depending on the particular implementation of the 1094 math library. We use algorithm 3.4.1.S in [KNUTH], which is free 1095 of the above mentioned problem, and guarantees the same output on any 1096 implementation. The algorithm belongs to the 'ziggurat' family 1097 developed in the 1970s by G.Marsaglia, M.Sibuya and J.H.Ahrens 1098 [ZIGG]. It replaces the use of logarithmic function by clever bit 1099 manipulation, still producing the exponential variates on output. 1101 7.1. High-Level Description of the Algorithm 1103 For ease of exposition, the algorithm is first described with all 1104 arithmetic operations being interpreted in their natural sense. 1105 Later, exact details on data types, arithmetic, and generation of the 1106 uniform random variates used by the algorithm are given. It is an 1107 almost verbatim quotation from [KNUTH], p.133. 1109 Algorithm S: Given a real positive number 'mu', produce an 1110 exponential random variate with mean 'mu'. 1112 First, the constants 1114 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 1116 are computed in advance. The exact values which MUST be used by all 1117 implementations are given in the reference code (see Appendix). This 1118 is necessary to insure that exactly the same pseudo-random sequences 1119 are produced by all implementations. 1121 S1. [Get U and shift.] Generate a 32-bit uniform random binary 1122 fraction 1124 U = (.b0 b1 b2 ... b31) [note the decimal point] 1126 Locate the first zero bit b_j, and shift off the leading (j+1) bits, 1127 setting U <- (.b_{j+1} ... b31) 1129 NOTE: in the rare case that the zero has not been found it is 1130 prescribed that the algorithm return (mu*32*ln2). 1132 S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and 1133 terminate the algorithm. (Note that Q[1] = ln2.) 1135 S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k 1136 new uniform random binary fractions U1,...,Uk and set V <- 1137 min(U1,...,Uk). 1139 S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. 1141 7.2. Data Types, Representation and Arithmetic 1143 The high-level algorithm operates on real numbers -- typically 1144 represented as floating point numbers. This specification prescribes 1145 that unsigned 64-bit integers be used instead. 1147 u_int64_t integers are interpreted as real numbers by placing the 1148 decimal point after the first 32 bits. In other words, conceptually 1149 the interpretation is given by the map: 1151 u_int64_t u; 1153 u |--> (double)u / (2**32) 1155 The algorithm produces a sequence of such u_int64_t integers which is 1156 guaranteed to be the same on any implementation. Any further 1157 interpretation (such as given by (1)) is done by the application, and 1158 is not part of this specification. 1160 We specify that the u_int64_t representations of the first 11 values 1161 of the Q array in the high-level algorithm be as follows: 1163 #1 0xB17217F8, 1164 #2 0xEEF193F7, 1165 #3 0xFD271862, 1166 #4 0xFF9D6DD0, 1167 #5 0xFFF4CFD0, 1168 #6 0xFFFEE819, 1169 #7 0xFFFFE7FF, 1170 #8 0xFFFFFE2B, 1171 #9 0xFFFFFFE0, 1172 #10 0xFFFFFFFE, 1173 #11 0xFFFFFFFF 1175 For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) 1176 = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF 1178 Small integer 'j' in the high-level algorithm is represented as 1179 u_int64_t value j * (2**32); 1181 Operation of addition is done as usual on u_int64_t numbers; however, 1182 the operation of multiplication in the high-level algorithm should be 1183 replaced by 1185 (u, v) |---> (u * v) >> 32 1187 Implementations MUST compute (u * v) exactly. For example, a 1188 fragment of unsigned 128-bit arithmetic can be implemented for this 1189 purpose (see sample implementation below). 1191 7.3. Uniform Random Quantities 1193 The procedure for obtaining a sequence of 32-bit random numbers (such 1194 as 'U' in algorithm S) relies on using AES encryption in counter 1195 mode. To describe the exact working of the algorithm we introduce two 1196 primitives from Rijndael. Their prototypes and specification are 1197 given below, and they are assumed to be provided by the supporting 1198 Rijndael implementation, such as [RIJN]. 1200 + This function initializes a Rijndael key with bytes from 'seed' 1202 void KeyInit(unsigned char seed[16]); 1204 + This function encrypts the 16-octet block 'inblock' with the 'key' 1205 returning a 16-octet encrypted block. Here 'keyInstance' is an 1206 opaque type used to represent Rijndael keys. 1208 void BlockEncrypt(keyInstance key, unsigned char inblock[16]); 1210 Algorithm Unif: given a 16-octet quantity seed, produce a sequence of 1211 unsigned 32-bit pseudo-random uniformly distributed integers. In 1212 OWAMP, the SID (session ID) from Control protocol plays the role of 1213 seed. 1215 U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an 1216 unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need 1217 more random bytes?] Set i <- c mod 4. If (i == 0) set s <- 1218 BlockEncrypt(key, c) 1220 U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1 1222 U4. [Do output] Output the i_th quartet of octets from s starting 1223 from high-order octets, converted to native byte order and 1224 represented as OWPNum64 value (as in 3.b). 1226 U5. [Loop] Go to step U2. 1228 7.4. Receiver Behavior 1230 Receiver knows when the sender will send packets. The following 1231 parameter is defined: Timeout (from Request-Session). Packets that 1232 are delayed by more that Timeout are considered lost (or `as good as 1233 lost'). Note that there is never an actual assurance of loss by the 1234 network: a `lost' packet might still be delivered at any time. The 1235 original specification for IPv4 required that packets be delivered 1236 within TTL seconds or never (with TTL having a maximum value of 255). 1237 To the best of the authors' knowledge, this requirement was never 1238 actually implemented (and of course only a complete and universal 1239 implementation would ensure that packets don't travel for longer than 1240 TTL seconds). Further, IPv4 specification makes no claims about the 1241 time it takes the packet to traverse the last link of the path. 1243 The choice of a reasonable value of Timeout is a problem faced by a 1244 user of OWAMP protocol, not by an implementor. A value such as two 1245 minutes is very safe. Note that certain applications (such as 1246 interactive `one-way ping') might wish to obtain the data faster than 1247 that. 1249 As packets are received, 1251 + Timestamp the received packet. 1253 + In authenticated or encrypted mode, decrypt first block (16 1254 octets) of packet body. 1256 + Store the packet sequence number, send times, and receive times 1257 for the results to be transferred. 1259 + Packets not received within the Timeout are considered lost. They 1260 are recorded with their seqno, presumed send time, and receive 1261 time consisting of a string of zero bits. 1263 Packets that are actually received are recorded in the order of 1264 arrival. Lost packet records serve as indications of the send times 1265 of lost packets. They SHOULD be placed either at the point where the 1266 receiver learns about the loss or at any later point; in particular, 1267 one MAY place all the records that correspond to lost packets at the 1268 very end. 1270 Packets that have send time in the future MUST be recorded normally, 1271 without changing their send timestamp, unless they have to be 1272 discarded. (Send timestamps in the future would normally indicate 1273 clocks that differ by more than the delay. Some data -- such as 1274 jitter -- can be extracted even without knowledge of time difference. 1275 For other kinds of data, the adjustment is best handled by the data 1276 consumer on the basis of the complete information in a measurement 1277 session as well as possibly external data.) 1279 Packets with a sequence number that was already observed (duplicate 1280 packets) MUST be recorded normally. (Duplicate packets are sometimes 1281 introduced by IP networks. The protocol has to be able to measure 1282 duplication.) 1284 If any of the following is true, packet MUST be discarded: 1286 + Send timestamp is more than Timeout in the past or in the future. 1288 + Send timestamp differs by more than Timeout from the time when the 1289 packet should have been sent according to its seqno. 1291 + In authenticated or encrypted mode, any of the bits of zero 1292 padding inside the first 16 octets of packet body is non-zero. 1294 8. Security Considerations 1296 The goal of authenticated mode to let one passphrase-protect service 1297 provided by a particular OWAMP-Control server. One can imagine a 1298 variety of circumstances where this could be useful. Authenticated 1299 mode is designed to prohibit theft of service. 1301 Additional design objective of authenticated mode was to make it 1302 impossible for an attacker who cannot read traffic between OWAMP-Test 1303 sender and receiver to tamper with test results in a fashion that 1304 affects the measurements, but not other traffic. 1306 The goal of encrypted mode is quite different: To make it hard for a 1307 party in the middle of the network to make results look `better' than 1308 they should be. This is especially true if one of client and server 1309 doesn't coincide with neither sender nor receiver. 1311 Encryption of OWAMP-Control using AES CBC mode with blocks of zeros 1312 after each message aims to achieve two goals: (i) to provide secrecy 1313 of exchange; (ii) to provide authentication of each message. 1315 OWAMP-Test sessions directed at an unsuspecting party could be used 1316 for denial of service (DoS) attacks. In unauthenticated mode servers 1317 should limits receivers to hosts they control or to the OWAMP-Control 1318 client. 1320 OWAMP-Test sessions could be used as covert channels of information. 1321 Environments that are worried about covert channels should take this 1322 into consideration. 1324 Notice that AES in counter mode is used for pseudo-random number 1325 generation, so implementation of AES MUST be included even in a 1326 server that only supports unauthenticated mode. 1328 9. IANA Considerations 1330 IANA is requested to allocate a well-known TCP port number for OWAMP- 1331 Control part of the OWAMP protocol. 1333 10. Internationalization Considerations 1335 The protocol does not carry any information in a natural language. 1337 11. Appendix: Sample Implementation of Exponential Deviate Computation 1339 /* 1340 ** Example usage: generate a stream of exponential (mean 1) 1341 ** random quantities (ignoring error checking during initialization). 1342 ** If a variate with some mean mu other than 1 is desired, the output 1343 ** of this algorithm can be multiplied by mu according to the rules 1344 ** of arithmetic we described. 1346 ** Assume that a 16-octet 'seed' has been initialized 1347 ** (as the shared secret in OWAMP, for example) 1348 ** unsigned char seed[16]; 1350 ** OWPrand_context next; 1352 ** (initialize state) 1353 ** OWPrand_context_init(&next, seed); 1355 ** (generate a sequence of exponential variates) 1356 ** while (1) { 1357 ** u_int64_t num = OWPexp_rand64(&next); 1358 1359 ... 1360 ** } 1361 */ 1363 #include 1365 typedef u_int64_t u_int64_t; 1367 /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ 1368 #define K 12 1370 #define BIT31 0x80000000UL /* see if first bit in the lower 1371 32 bits is zero */ 1372 #define MASK32(n) ((n) & 0xFFFFFFFFUL) 1374 #define EXP2POW32 0x100000000ULL 1376 typedef struct OWPrand_context { 1377 unsigned char counter[16]; /* 16-octet counter (network byte order) */ 1378 keyInstance key; /* key used to encrypt the counter. */ 1379 unsigned char out[16]; /* the encrypted block is kept there. */ 1380 } OWPrand_context; 1382 /* 1383 ** The array has been computed according to the formula: 1384 ** 1385 ** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) 1386 ** 1387 ** as described in algorithm S. (The values below have been 1388 ** multiplied by 2^32 and rounded to the nearest integer.) 1389 ** These exact values MUST be used so that different implementation 1390 ** produce the same sequences. 1391 */ 1392 static u_int64_t Q[K] = { 1393 0, /* Placeholder - so array indices start from 1. */ 1394 0xB17217F8, 1395 0xEEF193F7, 1396 0xFD271862, 1397 0xFF9D6DD0, 1398 0xFFF4CFD0, 1399 0xFFFEE819, 1400 0xFFFFE7FF, 1401 0xFFFFFE2B, 1402 0xFFFFFFE0, 1403 0xFFFFFFFE, 1404 0xFFFFFFFF 1405 }; 1407 /* this element represents ln2 */ 1408 #define LN2 Q[1] 1410 /* 1411 ** Convert an unsigned 32-bit integer into a u_int64_t number.. 1412 */ 1413 u_int64_t 1414 OWPulong2num64(u_int32_t a) 1415 { 1416 return ((u_int64_t)1 << 32) * a; 1417 } 1419 /* 1420 ** Arithmetic functions on u_int64_t numbers. 1421 */ 1423 /* 1424 ** Addition. 1425 */ 1426 u_int64_t 1427 OWPnum64_add(u_int64_t x, u_int64_t y) 1428 { 1429 return x + y; 1430 } 1432 /* 1433 ** Multiplication. Allows overflow. Straightforward implementation 1434 ** of Algorithm 4.3.1.M (p.268) from [KNUTH] 1435 */ 1436 u_int64_t 1437 OWPnum64_mul(u_int64_t x, u_int64_t y) 1438 { 1439 unsigned long w[4]; 1440 u_int64_t xdec[2]; 1441 u_int64_t ydec[2]; 1443 int i, j; 1444 u_int64_t k, t, ret; 1446 xdec[0] = MASK32(x); 1447 xdec[1] = MASK32(x>>32); 1448 ydec[0] = MASK32(y); 1449 ydec[1] = MASK32(y>>32); 1451 for (j = 0; j < 4; j++) 1452 w[j] = 0; 1454 for (j = 0; j < 2; j++) { 1455 k = 0; 1456 for (i = 0; ; ) { 1457 t = k + (xdec[i]*ydec[j]) + w[i + j]; 1458 w[i + j] = t%EXP2POW32; 1459 k = t/EXP2POW32; 1460 if (++i < 2) 1461 continue; 1462 else { 1463 w[j + 2] = k; 1464 break; 1465 } 1466 } 1467 } 1469 ret = w[2]; 1470 ret <<= 32; 1471 return w[1] + ret; 1472 } 1473 /* 1474 ** Seed the random number generator using a 16-byte quantity 'seed' 1475 ** (== the session ID in OWAMP). This function implements step U1 1476 ** of algorithm Unif. 1477 */ 1479 void 1480 OWPrand_context_init(OWPrand_context *next, unsigned char *seed) 1481 { 1482 int i; 1484 /* Initialize the key */ 1485 rijndaelKeyInit(next->key, seed); 1487 /* Initialize the counter with zeros */ 1488 memset(next->out, 0, 16); 1489 for (i = 0; i < 16; i++) 1490 next->counter[i] = 0UL; 1491 } 1493 /* 1494 ** Random number generating functions. 1495 */ 1497 /* 1498 ** Generate and return a 32-bit uniform random string (saved in the less 1499 ** significant half of the u_int64_t). This function implements steps U2-U4 1500 ** of the algorithm Unif. 1501 */ 1502 u_int64_t 1503 OWPunif_rand64(OWPrand_context *next) 1504 { 1505 int j; 1506 u_int8_t *buf; 1507 u_int64_t ret = 0; 1509 /* step U2 */ 1510 u_int8_t i = next->counter[15] & (u_int8_t)3; 1511 if (!i) 1512 rijndaelEncrypt(next->key, next->counter, next->out); 1514 /* Step U3. Increment next.counter as a 16-octet single quantity 1515 in network byte order for AES counter mode. */ 1516 for (j = 15; j >= 0; j--) 1517 if (++next->counter[j]) 1518 break; 1520 /* Step U4. Do output. The last 4 bytes of ret now contain the 1521 random integer in network byte order */ 1522 buf = &next->out[4*i]; 1523 for(j=0;j<4;j++){ 1524 ret <<= 8; 1525 ret += *buf++; 1526 } 1527 return ret; 1528 } 1530 /* 1531 ** Generate a mean 1 exponential deviate. 1532 */ 1533 u_int64_t 1534 OWPexp_rand64(OWPrand_context *next) 1535 { 1537 unsigned long i, k; 1538 u_int32_t j = 0; 1539 u_int64_t U, V, J, tmp; 1541 /* Step S1. Get U and shift */ 1542 U = OWPunif_rand64(next); 1544 while ((U & BIT31) && (j < 32)){ /* shift until find first '0' */ 1545 U <<= 1; 1546 j++; 1547 } 1548 /* remove the '0' itself */ 1549 U <<= 1; 1551 U = MASK32(U); /* Keep only the fractional part. */ 1552 J = OWPulong2num64(j); 1554 /* Step S2. Immediate acceptance? */ 1555 if (U < LN2) /* return (j*ln2 + U) */ 1556 return OWPnum64_add(OWPnum64_mul(J, LN2), U); 1558 /* Step S3. Minimize. */ 1559 for (k = 2; k < K; k++) 1560 if (U < Q[k]) 1561 break; 1562 V = OWPunif_rand64(next); 1563 for (i = 2; i <= k; i++){ 1564 tmp = OWPunif_rand64(next); 1565 if (tmp < V) 1566 V = tmp; 1567 } 1568 /* Step S4. Return (j+V)*ln2 */ 1569 return OWPnum64_mul(OWPnum64_add(J, V), LN2); 1570 } 1572 12. Normative References 1574 [AES] Advanced Encryption Standard (AES), 1575 http://csrc.nist.gov/encryption/aes/ 1577 [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, 1578 Implementation and Analysis', RFC 1305, March 1992. 1580 [RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321, 1581 April 1992. 1583 [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', 1584 RFC 2026, October 1996. 1586 [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate 1587 Requirement Levels', RFC 2119, March 1997. 1589 [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for 1590 IP Performance Metrics' RFC 2330, May 1998. 1592 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of 1593 the Differentiated Services Field (DS Field) in the IPv4 and 1594 IPv6 Headers', RFC 2474, December 1998. 1596 [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay 1597 Metric for IPPM', RFC 2679, September 1999. 1599 [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet 1600 Loss Metric for IPPM', RFC 2680, September 1999. 1602 [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior 1603 Identification Codes', RFC 2836, May 2000. 1605 13. Informative References 1607 [ZIGG] G. Marsaglia, M. Sibuya and J.H. Ahrens, Communications of 1608 ACM, 15 (1972), 876-877 1610 [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd 1611 edition, 1998 1613 [RIJN] Reference ANSI C implementation of Rijndael 1614 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip 1616 [RIPE] RIPE NCC Test-Traffic Measurements home, 1617 http://www.ripe.net/test-traffic/. 1619 [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay 1620 Measurements Using Test-Traffic', Spring 1998 Dutch Unix User 1621 Group Meeting, http://www.ripe.net/test- 1622 traffic/Talks/9805_nluug.ps.gz. 1624 [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. 1626 [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An 1627 Infrastructure for Network Performance Measurements', 1628 Proceedings of INET'99, June 1999. 1629 http://www.isoc.org/inet99/proceedings/4h/4h_2.htm 1631 14. Authors' Addresses 1633 Stanislav Shalunov 1635 Benjamin Teitelbaum 1637 Anatoly Karp 1639 Jeff Boote 1641 Matthew J. Zekauskas 1643 Expiration date: November 2003