idnits 2.17.1 draft-morton-ippm-twamp-rate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5357, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5357, updated by this document, for RFC5378 checks: 2005-11-11) -- 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 (March 4, 2012) is 4436 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft L. Ciavattone 4 Updates: 5357 (if approved) AT&T Labs 5 Intended status: Standards Track March 4, 2012 6 Expires: September 5, 2012 8 TWAMP Burst Rate Measurement Features 9 draft-morton-ippm-twamp-rate-01 11 Abstract 13 This memo describes two rate-measurement features for the core 14 specification of TWAMP - the Two-Way Active Measurement Protocol: an 15 optional capability where the reflector host responds with a 16 controlled burst of test-session packets (instead of a single 17 packet), and an optional test mode that requires the responder to 18 measure a burst of test packets and communicate the results in 19 truncated packet(s). Both features add the ability to control packet 20 size in the tested direction, enabling asymmetrical packet size 21 testing. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 5, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 65 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 66 3.1. Connection Setup with New Features . . . . . . . . . . . . 5 67 3.2. Burst Generation: Request-TW-Session Packet Format . . . . 5 68 3.3. Burst Measurement: Request-TW-Session Packet Format . . . 7 69 3.4. Burst Gen and Meas: Accept Session Packet Format . . . . . 8 70 3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . . 8 71 3.6. Additional considerations . . . . . . . . . . . . . . . . 8 72 4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . . 9 73 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 9 75 4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 9 76 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 10 77 4.2.1. Session-Reflector Burst Packet Format and Contents . . 10 78 5. Burst Measurement in TWAMP Test . . . . . . . . . . . . . . . 12 79 5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 12 80 5.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 12 81 5.1.2. Packet Formats and Contents . . . . . . . . . . . . . 12 82 5.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 13 83 5.2.1. Session-Reflector Burst Measurement Response 84 Packet Format and Contents . . . . . . . . . . . . . . 14 85 6. Special Case of One-packet Bursts . . . . . . . . . . . . . . 16 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 8.1. Registry Specification . . . . . . . . . . . . . . . . . . 16 89 8.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 17 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an 99 extension of the One-way Active Measurement Protocol, OWAMP 100 [RFC4656]. The TWAMP specification gathered wide review as it was 101 deployed, resulting in recommendations for new features. 103 This memo describes two closely-related features for TWAMP. When 104 measuring packet delivery rate to end-systems, unique control and 105 measurement capabilities become useful, especially when the path 106 tested includes asymmetrical link speeds (as are often deployed in 107 consumer Internet access services). 109 One feature is the OPTIONAL capability for the responder host to 110 return a controlled burst of test-session packets (instead of a 111 single packet). 113 Another is an optional sender packet format that requires the 114 responder to measure a burst of test packets and communicate the 115 results in a single packet. 117 Both features add the ability to control packet size in each 118 direction, enabling asymmetrical packet size testing. Although TWAMP 119 [RFC5357] recommends padding truncation to achieve symmetrical sizes 120 (to compensate for the Session-Reflector's larger test packet 121 header), these features configure test packet sizes when the test 122 session is requested using the TWAMP-Control protocol. 124 We note that [draft-baillargeon-ippm-twamp-value-added-octets-01.txt] 125 addresses a similar measurement problem, but places different 126 requirements on the reflector host and does not include the 127 asymmetrical size aspect. 129 This memo is an update to the TWAMP core protocol specified in 130 [RFC5357]. Measurement systems are not required to implement the 131 features described in this memo to claim compliance with [RFC5357]. 133 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 134 to zero by senders and MUST be ignored by receivers. Also, the HMAC 135 (Hashed Message Authentication Code) MUST be calculated as defined in 136 Section 3.2 of [RFC4656]. 138 2. Purpose and Scope 140 The purpose of this memo is to define two OPTIONAL closely-related 141 features for TWAMP [RFC5357]. The features enhance the TWAMP 142 responder's capabilities to perform a simple operations on test 143 packets, and the capability to demand asymmetrical size TWAMP-Test 144 packets. 146 The scope of the memo is limited to specifications of the following 147 features: 149 o Burst Generation: the capability of the Session-Reflector to 150 generate a burst of packets for return to the Session-Sender, and 151 the corresponding TWAMP-Control messages to activate the 152 capability between compliant hosts. 154 o Burst Measurement: the capability of the Session-Reflector to 155 measure a burst of packets from the Session-Sender, report the key 156 information (receive timestamps) in the response packet(s), and 157 the corresponding TWAMP-Control messages to activate the 158 capability between compliant hosts. 160 o Asymmetrical Size: the capability to ensure that TWAMP-Test 161 protocol uses a specific packet size in each direction. This 162 feature is combined with the Burst features, and essentially adds 163 a third simple capability when the Burst size = 1. 165 This memo extends the modes of operation through assignment of two 166 new values in the Modes Field (see section 3.1 of[RFC4656] for the 167 format of the Server Greeting message), while retaining backward 168 compatibility with the core TWAMP [RFC5357] implementations. The two 169 new values correspond to the two features defined in this memo. 171 When the Server and Control-Client have agreed to use the Burst 172 Generation mode during control connection setup, then the Control- 173 Client, the Server, the Session-Sender, and the Session-Reflector 174 MUST all conform to the requirements of that mode, as identified 175 below. 177 When the Server and Control-Client have agreed to use the Burst 178 Measurement mode during control connection setup, then the Control- 179 Client, the Server, the Session-Sender, and the Session-Reflector 180 MUST all conform to the requirements of that mode, as identified 181 below. 183 3. TWAMP Control Extensions 185 TWAMP-Control protocol [RFC5357] uses the Modes Field to identify and 186 select specific communication capabilities, and this field is a 187 recognized extension mechanism. The following sections describe two 188 such extensions. 190 3.1. Connection Setup with New Features 192 TWAMP connection establishment follows the procedure defined in 193 section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new 194 features require two new bit positions (and values). See the IANA 195 section for details on the assigned values and bit positions. 197 The Server sets one or both of the new bit positions in the Modes 198 Field of the Server Greeting message to indicate its capabilities and 199 willingness to operate in either of these modes if desired. 201 If the Control-Client intends to operate all test sessions invoked 202 with this control connection using one of the new modes, it MUST set 203 the Mode Field bit corresponding to each function in the Setup 204 Response message. With this and other extensions, the Control-Client 205 MAY set multiple Mode Field bits in the Setup Response message, but 206 these new features are mutually exclusive, and MUST NOT be used 207 together. 209 3.2. Burst Generation: Request-TW-Session Packet Format 211 The bits designated for the Burst Generation feature in the Request- 212 TW-Session command are as shown in the packet format below. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Number of Schedule Slots | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Number of Packets* | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 . . 224 . ... Many fields (62 octets) not shown ... . 225 . . 226 . . 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Padding Length* (4 octets) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Start Time, (8 octets) | 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Timeout, (8 octets) | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type-P Descriptor | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Octets to be reflected | Length of padding to reflect | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | MBZ (2 octets) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 | HMAC (16 octets) | 244 | | 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 * = re-interpreted field 250 Two re-interpreted fields appear in the Request-TW-Session command 251 when using Burst Generation mode: 253 1. Number of Packets: In this mode, re-interpreted as the number of 254 packets that the Session-Reflector MUST generate in each Burst. 256 2. Packet Padding Length: In the mode, re-interpreted as the number 257 of octets the Session-Reflector MUST append to the Test packet 258 header of each packet it generates as part of the burst. The 259 Session-Reflector MUST NOT assume that the Session-Sender will 260 use any packet padding, and MUST be prepared to generate the 261 padding itself. 263 3.3. Burst Measurement: Request-TW-Session Packet Format 265 The bits designated for the Burst Generation feature in the Request- 266 TW-Session command are as shown in the packet format below. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Number of Schedule Slots | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Number of Packets* | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 . . 278 . ... Many fields (62 octets) not shown ... . 279 . . 280 . . 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Padding Length (4 octets) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Start Time, (8 octets) | 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Timeout*, (8 octets) | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type-P Descriptor | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Octets to be reflected | Length of padding to reflect | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | MBZ (2 octets) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 | HMAC (16 octets) | 298 | | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 * = re-interpreted field 304 Two re-interpreted fields appear in the Request-TW-Session command 305 when using Burst Measurement mode: 307 1. Number of Packets: In this mode, re-interpreted as the number of 308 packets that the Session-Reflector MUST expect to measure as part 309 of each Burst. 311 2. Timeout: In this mode, re-interpreted as the time to wait for all 312 packets in a burst to arrive, expressed in the existing timestamp 313 format used in TWAMP and OWAMP. In the case of lost packets, the 314 Session-Reflector is commanded to wait through this time-out for 315 packets in a burst to arrive. 317 3.4. Burst Gen and Meas: Accept Session Packet Format 319 The Accept Session command for the Burst feature is as shown in the 320 packet format below (assuming the Reflect Octets feature is also in 321 use). 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 | Accept | MBZ | Port | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 328 | | 329 | SID (16 octets) | 330 | | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Reflected octets | Server octets | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | MBZ (8 octets) | 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | HMAC (16 octets) | 340 | | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 3.5. Burst Gen and Meas: Stopping Test Sessions 346 The Control-Client SHALL stop in-progress test sessions using any 347 standardized methods, including section 3.8 of [RFC5357] or the 348 optional capability of [RFC5938]. 350 3.6. Additional considerations 352 The value of the Modes Field sent by the Server in the Server 353 Greeting message is the bit-wise OR of the mode values that it is 354 willing to support during this session. 356 We note that Burst Generation and Measurement features are 357 incompatible with each other, and with the Symmetrical Size feature 358 described in [RFC6038], and MUST NOT be used in combination with 359 those features. 361 With the publication of this memo as an RFC, the last 9 bit positions 362 of the Modes 32-bit Field are used. A Control-Client conforming to 363 this extension of [RFC5357] MAY ignore the values in the higher bits 364 of the Modes Field, or it MAY support other features that are 365 communicated in those bit positions. The other bits are available 366 for future protocol extensions. 368 4. Burst Generation in TWAMP Test 370 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 371 protocol with the exception that the Session-Reflector transmits test 372 packets to the Session-Sender in response to each test packet it 373 receives. The Burst Generation feature modifies the behavior of 374 TWAMP section 4[RFC5357]. This mode requires the Session-Sender to 375 send a Burst-Initiation packet, and the Session-Reflector generates 376 test session packets according to the configuration agreed using the 377 TWAMP-Control protocol. 379 4.1. Sender Behavior 381 This section describes extensions to the behavior of the TWAMP 382 Session-Sender. 384 4.1.1. Packet Timings 386 The Send Schedule is not utilized in TWAMP, and this is unchanged in 387 this memo. 389 4.1.2. Packet Formats and Contents 391 The Session-Sender packet format and content follow the same 392 procedure and guidelines as defined in section 4.1.2 of [RFC4656] (as 393 indicated in section 4.1.2 of TWAMP [RFC5357]). 395 This mode uses the original TWAMP-Test Packet Padding Field (see 396 section 4.1.2 of [RFC4656]), or can be used with Reflect Octets 397 feature as shown below for unauthenticated mode: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Sequence Number | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Timestamp | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Error Estimate | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 409 | | 410 | Packet Padding (to be reflected) | 411 . (length in octets specified in command) . 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 . . 414 . Additional Packet Padding . 415 . . 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Burst Initiation Packet Format 419 The Sequence Number, Timestamp, and Error Estimate fields are the 420 same as specified in section 4.1.2 of [RFC4656] in OWAMP. 422 We note that the format of the Burst Initiation packet has not been 423 changed from the usual Session-Sender test packet format, to simplify 424 adoption. 426 4.2. Reflector Behavior 428 The TWAMP Reflector differs significantly from the procedures and 429 guidelines in section 4.2 of [RFC5357]. The following new functions 430 MUST be performed: 432 o Recognition of the function of the Burst Initiation Packet used in 433 this mode. 435 o Generation of the required burst of test session packets, 436 according to the configuration agreed in Request-TW-Session 437 command, with the agreed number of packets in each burst and size 438 of each packet in the burst. 440 4.2.1. Session-Reflector Burst Packet Format and Contents 442 The Burst Generation feature retains the usual Reflector packet 443 fields, as shown below. When the Burst Generation mode is selected, 444 the Session-Reflector SHALL use the following TWAMP-Test Packet 445 Format in Unauthenticated mode (shown with Reflect Octets feature 446 activated): 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Sequence Number | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Timestamp | 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Error Estimate | MBZ | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Receive Timestamp | 459 | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Sender Sequence Number | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Sender Timestamp | 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Sender Error Estimate | MBZ | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Sender TTL | Packet Padding (from Session-Sender) | 469 +-+-+-+-+-+-+-+-+ + 470 . . 471 + +-+-+-+-+-+-+-+-+ 472 | Packet Padding (from Session-Sender) | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 474 | | 475 | | 476 . Additional Packet Padding . 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Section 4.2.1 of [RFC5357] describes the above fields as used in 480 TWAMP, with one exception. 482 The Sequence Number field SHALL indicate the sequence number of each 483 packet sent throughout the test session. The Sequence Number SHALL 484 be increased by 1 for each packet. The initial Sequence Number SHALL 485 be 0. 487 When one burst is complete, the Sequence Numbers SHALL continue to 488 increment by 1 in the packets generated in response to the next 489 burst. 491 The total Packet Padding octets SHALL have the length specified in 492 the TWAMP-Control request for the appropriate test session. The 493 Session-Reflector MAY need to generate its own packet padding, if the 494 Burst Request packet does not include this field (or contains 495 insufficient padding). 497 In any case, the Session-Reflector MAY re-use the Sender's Packet 498 Padding (since the requirements for padding generation are the same 499 for each) when possible. 501 The Session-Reflector SHALL send a series of TWAMP-Test Packets in 502 response to reception of the Burst Initiation Packet, according to 503 the configuration agreed in the Request-TW-Session command (number of 504 packets and padding), and as immediately as possible. The Session- 505 Reflector SHALL send all packets in a burst as close to back-to-back 506 as possible (recognizing that lower layers may have spacing 507 requirements that take precedence). 509 5. Burst Measurement in TWAMP Test 511 The Burst Measurement feature modifies the behavior of TWAMP section 512 4[RFC5357]. This mode requires the Session-Sender to send a Burst of 513 test packets, and the Session-Reflector measures the burst of packets 514 and reports the results in the Burst Response packet format(s), as 515 described below. 517 5.1. Sender Behavior 519 This section describes extensions to the behavior of the TWAMP 520 Session-Sender. 522 5.1.1. Packet Timings 524 The Session-Sender SHALL send all packets in a burst as close to 525 back-to-back as possible (recognizing that lower layers may have 526 spacing requirements that take precedence). 528 5.1.2. Packet Formats and Contents 530 The Session-Sender packet format and content SHALL comply with that 531 defined in section 4.1.2 of [RFC4656] (as indicated in section 4.1.2 532 of TWAMP [RFC5357]). 534 This mode uses the original TWAMP-Test Packet Padding Field (see 535 section 4.1.2 of [RFC4656]), or can be used with Reflect Octets 536 feature as shown below for unauthenticated mode: 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Burst Sequence Number | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Timestamp | 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Error Estimate | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 548 | | 549 | Packet Padding (to be reflected) | 550 . (length in octets specified in command) . 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 . . 553 . Additional Packet Padding . 554 . . 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Session-Sender Burst Test Packet Format 558 The Burst Sequence Number field SHALL indicate the number of each 559 burst. The Burst Sequence Number SHALL be increased by 1 for each 560 burst, and remain the same for each packet in a burst. The initial 561 number SHALL be 0. 563 When one burst is complete, the Burst Sequence Number used in the all 564 packets of the next burst SHALL be increased by 1. 566 5.2. Reflector Behavior 568 The TWAMP Reflector differs slightly from the procedures and 569 guidelines in section 4.2 of [RFC5357]. The following new functions 570 MUST be performed: 572 o Recognition of the function of the Session-Sender Burst Test 573 Packet Format used in this mode. 575 o Processing the required bursts of test session packets, according 576 to the configuration agreed in Request-TW-Session command, with 577 the agreed length of the burst in packets and size of each packet 578 in the burst, and the agreed Burst Time-out. 580 o Response with an abbreviated Session-Reflector test packet as 581 described below. For discussion, we will call this the 1-to-1 582 response. 584 o OR - Response with the new Burst Measurement Response packet 585 described below. For discussion, we will call this the 586 accumulated response. 588 We seek feedback from the IPPM working group on which of these two 589 alternatives is preferable. 591 5.2.1. Session-Reflector Burst Measurement Response Packet Format and 592 Contents 594 The Burst Measurement feature specifies a standard Session-Reflector 595 packet to communicate the results, as shown below. When the Burst 596 measurement mode is selected, the Session-Sender SHALL use the 597 following Burst Measurement Response packet Format in Unauthenticated 598 mode (shown with Reflect Octets feature also in use): 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Sequence Number | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Timestamp | 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Error Estimate | MBZ | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 610 | Receive Timestamp | 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Sender Burst Sequence Number | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Sender Timestamp B 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Sender Error Estimate | MBZ | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Sender TTL | Packet Padding (from Session-Sender) | 621 +-+-+-+-+-+-+-+-+ + 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 624 Session-Reflector Measurement Packet (1-to-1 response) 626 Section 4.2.1 of [RFC5357] describes the fields in the 1-to-1 627 response packet above; they are the same as used in TWAMP. The main 628 difference is that Packet Padding SHALL be truncated on a 16 octet- 629 word boundary, returning the minimum information to the Session- 630 Sender. 632 All Timestamps SHALL be formatted according to the precedent set in 633 section 4.1.2 of [RFC4656], which is to use [RFC1305] (and updated 634 version), as follows: 636 "The first 32 bits represent the unsigned integer number of seconds 637 elapsed since 0h on 1 January 1900; the next 32 bits represent the 638 fractional part of a second that has elapsed since then." 640 The Session-Reflector MUST truncate the Sender's Packet Padding, 641 unless the Reflect Octets feature is also active in which case the 642 Session_Reflector MAY re-use the Sender's Packet Padding (since the 643 requirements for padding generation are the same for each) to reach a 644 word boundary. 646 The Sender Timestamp field SHALL have the sender's timestamp from 647 each packet received in the burst. 649 In 1-to-1 response mode, the Session-Reflector SHALL send a Session- 650 Reflector Measurement Packet in response to every Session-Sender 651 packet received, and as immediately as possible. 653 ======================================================== 655 In the accumulated response alternative, the Session-Reflector 656 creates and holds all packet headers described above in a buffer, and 657 sends them all at once in a single Session-Reflector test packet. 658 The length of the burst and the path MTU MUST be coordinated to avoid 659 fragmentation. 661 The first Session-Sender packet to arrive with a previously unseen 662 Burst Sequence Number SHALL be designated as the "First" packet in 663 that burst, and its timestamp is used in processing below. 665 As subsequent packets arrive, Session-Reflector SHALL: 667 o Maintain a count of packets with the same Burst Sequence Number 668 (one burst). 670 o Time stamp each packet as it arrives and store the time stamp in a 671 response packet structure with all fields complete, as in the 672 1-to-1 alternative. 674 When 676 o The count of packets with the same Burst Sequence Number equals 677 the agreed Burst Length, OR 679 o The agreed Timeout expires (computed by a the time to the "First" 680 Packet Timestamp), OR 682 o The Burst Sequence Number increases from previous packets 683 (indicating a new Burst is in progress), 685 then the current burst is determined to be complete. 687 When the Burst is complete, the Session-Reflector SHALL terminate the 688 current burst processing as described above and send the Burst 689 Measurement Response Packet to the Session-Sender as immediately as 690 possible. 692 In Accumulated Response, the Burst Measurement Response Packet is a 693 single packet with the concatenation of all previously-generated 694 response packet formats in the information field. 696 6. Special Case of One-packet Bursts 698 When the Number of Packets field in the Request-TW-Session command 699 equals 1, then the Burst Generation and Measurement modes are reduced 700 to test sessions with controlled, asymmetrical packet sizes. A 701 minimal size packet travels in one direction, and the measured 702 direction uses a packet with all Packet Padding specified in the 703 Request-TW-Session command. 705 7. Security Considerations 707 These extended modes of operation do not appear to permit any new 708 attacks on hosts communicating with core TWAMP [RFC5357]. 710 The security considerations that apply to any active measurement of 711 live networks are relevant here as well. See [RFC4656] and 712 [RFC5357]. 714 8. IANA Considerations 716 This memo adds two modes to the IANA registry for the TWAMP Modes 717 Field, and describes behavior when the new modes are used. This 718 field is a recognized extension mechanism for TWAMP. 720 8.1. Registry Specification 722 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 723 TWAMP-Modes are specified in TWAMP Server Greeting messages and 724 Set-up Response messages, as described in section 3.1 of [RFC5357], 725 consistent with section 3.1 of [RFC4656], and extended by this memo. 726 Modes are indicated by setting bits in the 32-bit Modes field that 727 correspond to values in the Modes registry. For the TWAMP-Modes 728 registry, we expect that new features will be assigned increasing 729 registry values that correspond to single bit positions, unless there 730 is a good reason to do otherwise (more complex encoding than single 731 bit positions may be used in the future, to access the 2^32 value 732 space). 734 8.2. Registry Contents 736 TWAMP Modes Registry is recommended to be augmented as follows: 738 Value Description Semantics Definition 739 -------------------------------------------------------- 740 xxx Burst Generation this memo, section 3.1 741 Capability new bit position (X) 742 yyy Burst Measurement this memo, section 3.1 743 new bit position (Y) 745 >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values 747 The suggested values are 749 X=7, xxx=128 751 Y=8, yyy=256 <<<< 753 9. Acknowledgements 755 The authors thank folks for review and comment. 757 10. References 759 10.1. Normative References 761 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 762 Specification, Implementation", RFC 1305, March 1992. 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, March 1997. 767 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 768 Zekauskas, "A One-way Active Measurement Protocol 769 (OWAMP)", RFC 4656, September 2006. 771 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 773 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 774 RFC 5357, October 2008. 776 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 777 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 778 August 2009. 780 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 781 Feature for the Two-Way Active Measurement Protocol 782 (TWAMP)", RFC 5938, August 2010. 784 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 785 Protocol (TWAMP) Reflect Octets and Symmetrical Size 786 Features", RFC 6038, October 2010. 788 10.2. Informative References 790 Authors' Addresses 792 Al Morton 793 AT&T Labs 794 200 Laurel Avenue South 795 Middletown,, NJ 07748 796 USA 798 Phone: +1 732 420 1571 799 Fax: +1 732 368 1192 800 Email: acmorton@att.com 801 URI: http://home.comcast.net/~acmacm/ 803 Len Ciavattone 804 AT&T Labs 805 200 Laurel Avenue South 806 Middletown,, NJ 07748 807 USA 809 Phone: +1 732 420 1239 810 Fax: 811 Email: lencia@att.com 812 URI: