idnits 2.17.1 draft-morton-ippm-twamp-rate-03.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 (February 21, 2013) is 4075 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) == Outdated reference: A later version (-10) exists of draft-ietf-ippm-rate-problem-02 == Outdated reference: A later version (-01) exists of draft-morton-ippm-lmap-path-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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 February 21, 2013 6 Expires: August 25, 2013 8 TWAMP Burst Rate Measurement Features 9 draft-morton-ippm-twamp-rate-03 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. This draft defines the modes in terms of traditional UDP 22 test packets. Use TCP transport instead of UDP may be desirable, but 23 is deferred for future work. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 25, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Alternate Transport Protocol Selection . . . . . . . . . . 4 66 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 67 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 6 68 3.1. Connection Setup with New Features . . . . . . . . . . . . 6 69 3.2. Burst Generation: Request-TW-Session Packet Format . . . . 6 70 3.3. Burst Measurement: Request-TW-Session Packet Format . . . 8 71 3.4. Burst Gen and Meas: Accept Session Packet Format . . . . . 9 72 3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . . 9 73 3.6. Additional considerations . . . . . . . . . . . . . . . . 9 74 4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . . 10 75 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 76 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10 77 4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 10 78 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 11 79 4.2.1. Session-Reflector Burst Packet Format and Contents . . 11 80 5. Burst Measurement in TWAMP Test . . . . . . . . . . . . . . . 13 81 5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 13 82 5.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 13 83 5.1.2. Packet Formats and Contents . . . . . . . . . . . . . 13 84 5.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14 85 5.2.1. Session-Reflector Burst Measurement Response 86 Packet Format and Contents . . . . . . . . . . . . . . 15 87 6. Special Case of One-packet Bursts . . . . . . . . . . . . . . 17 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 8.1. Registry Specification . . . . . . . . . . . . . . . . . . 17 91 8.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 18 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an 102 extension of the One-way Active Measurement Protocol, OWAMP 103 [RFC4656]. The TWAMP specification gathered wide review as it was 104 deployed, resulting in recommendations for new features. 106 This memo describes two closely-related features for TWAMP. When 107 measuring packet delivery rate to end-systems, unique control and 108 measurement capabilities become useful, especially when the path 109 tested includes asymmetrical link speeds (as are often deployed in 110 consumer Internet access services). 112 One feature is the OPTIONAL capability for the responder host to 113 return a controlled burst of test-session packets (instead of a 114 single packet). 116 Another is an optional sender packet format that requires the 117 responder to measure a burst of test packets and communicate the 118 results in a single packet. 120 Both features add the ability to control packet size in each 121 direction, enabling asymmetrical packet size testing. Although TWAMP 122 [RFC5357] recommends padding truncation to achieve symmetrical sizes 123 (to compensate for the Session-Reflector's larger test packet 124 header), these features configure test packet sizes when the test 125 session is requested using the TWAMP-Control protocol. 127 This memo is an update to the TWAMP core protocol specified in 128 [RFC5357]. Measurement systems are not required to implement the 129 features described in this memo to claim compliance with [RFC5357]. 131 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 132 to zero by senders and MUST be ignored by receivers. Also, the HMAC 133 (Hashed Message Authentication Code) MUST be calculated as defined in 134 Section 3.2 of [RFC4656]. 136 1.1. Alternate Transport Protocol Selection 138 An open question in the IPPM problem statement draft 139 [I-D.ietf-ippm-rate-problem] is whether testing with TCP transport 140 protocol is a needed capability. The current TWAMP test protocol 141 capability is limited to UDP transport. 143 This is clearly a topic where coordination is required between the 144 testing sender and receiver devices. It could be specified as an 145 independent TWAMP feature, and although it is clearly related to the 146 features described here, the work is deferred to a future memo. 148 2. Purpose and Scope 150 The purpose of this memo is to define two OPTIONAL closely-related 151 features for TWAMP [RFC5357]. The features enhance the TWAMP 152 responder's capabilities to perform a simple operations on test 153 packets, and the capability to demand asymmetrical size TWAMP-Test 154 packets. 156 This memo is intended to satisfy key requirements contianed in the 157 IPPM problem statement [I-D.ietf-ippm-rate-problem]. Referring to 158 the reference path defined in [I-D.morton-ippm-lmap-path], possible 159 measurement points include a Subscriber's host (mp000), the access 160 service demarcation point (mp100), Intra IP access where a globally 161 routable address is present (mp150), or the gateway between the 162 measured access network and other networks (mp190). The requirements 163 of this testing environment make it difficult to "correctly" generate 164 fixed rate packet ensembles. Some of the devices doing the 165 generation and/or measurement were designed for low-cost-large-scale 166 deployment and primarily for a purpose other than measurement. 168 The scope of the memo is limited to specifications of the following 169 features: 171 o Burst Generation: the capability of the Session-Reflector to 172 generate a burst of packets for return to the Session-Sender, and 173 the corresponding TWAMP-Control messages to activate the 174 capability between compliant hosts. 176 o Burst Measurement: the capability of the Session-Reflector to 177 measure a burst of packets from the Session-Sender, report the key 178 information (receive timestamps) in the response packet(s), and 179 the corresponding TWAMP-Control messages to activate the 180 capability between compliant hosts. 182 o Asymmetrical Size: the capability to ensure that TWAMP-Test 183 protocol uses a specific packet size in each direction. This 184 feature is combined with the Burst features, and essentially adds 185 a third simple capability when the Burst size = 1. 187 This memo extends the modes of operation through assignment of two 188 new values in the Modes Field (see section 3.1 of[RFC4656] for the 189 format of the Server Greeting message), while retaining backward 190 compatibility with the core TWAMP [RFC5357] implementations. The two 191 new values correspond to the two features defined in this memo. 193 When the Server and Control-Client have agreed to use the Burst 194 Generation mode during control connection setup, then the Control- 195 Client, the Server, the Session-Sender, and the Session-Reflector 196 MUST all conform to the requirements of that mode, as identified 197 below. 199 When the Server and Control-Client have agreed to use the Burst 200 Measurement mode during control connection setup, then the Control- 201 Client, the Server, the Session-Sender, and the Session-Reflector 202 MUST all conform to the requirements of that mode, as identified 203 below. 205 3. TWAMP Control Extensions 207 TWAMP-Control protocol [RFC5357] uses the Modes Field to identify and 208 select specific communication capabilities, and this field is a 209 recognized extension mechanism. The following sections describe two 210 such extensions. 212 3.1. Connection Setup with New Features 214 TWAMP connection establishment follows the procedure defined in 215 section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new 216 features require two new bit positions (and values). See the IANA 217 section for details on the assigned values and bit positions. 219 The Server sets one or both of the new bit positions in the Modes 220 Field of the Server Greeting message to indicate its capabilities and 221 willingness to operate in either of these modes if desired. 223 If the Control-Client intends to operate all test sessions invoked 224 with this control connection using one of the new modes, it MUST set 225 the Mode Field bit corresponding to each function in the Setup 226 Response message. With this and other extensions, the Control-Client 227 MAY set multiple Mode Field bits in the Setup Response message, but 228 these new features are mutually exclusive, and MUST NOT be used 229 together. 231 3.2. Burst Generation: Request-TW-Session Packet Format 233 The bits designated for the Burst Generation feature in the Request- 234 TW-Session command are as shown in the packet format below. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Number of Schedule Slots | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Number of Packets* | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 . . 246 . ... Many fields (62 octets) not shown ... . 247 . . 248 . . 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Padding Length* (4 octets) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Start Time, (8 octets) | 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Timeout, (8 octets) | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type-P Descriptor | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Octets to be reflected | Length of padding to reflect | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | MBZ (2 octets) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 | HMAC (16 octets) | 266 | | 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 * = re-interpreted field 272 Two re-interpreted fields appear in the Request-TW-Session command 273 when using Burst Generation mode: 275 1. Number of Packets: In this mode, re-interpreted as the number of 276 packets that the Session-Reflector MUST generate in each Burst. 278 2. Packet Padding Length: In the mode, re-interpreted as the number 279 of octets the Session-Reflector MUST append to the Test packet 280 header of each packet it generates as part of the burst. The 281 Session-Reflector MUST NOT assume that the Session-Sender will 282 use any packet padding, and MUST be prepared to generate the 283 padding itself. 285 3.3. Burst Measurement: Request-TW-Session Packet Format 287 The bits designated for the Burst Generation feature in the Request- 288 TW-Session command are as shown in the packet format below. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Number of Schedule Slots | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Number of Packets* | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 . . 300 . ... Many fields (62 octets) not shown ... . 301 . . 302 . . 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Padding Length (4 octets) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Start Time, (8 octets) | 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Timeout*, (8 octets) | 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type-P Descriptor | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Octets to be reflected | Length of padding to reflect | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | MBZ (2 octets) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 | HMAC (16 octets) | 320 | | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 * = re-interpreted field 326 Two re-interpreted fields appear in the Request-TW-Session command 327 when using Burst Measurement mode: 329 1. Number of Packets: In this mode, re-interpreted as the number of 330 packets that the Session-Reflector MUST expect to measure as part 331 of each Burst. 333 2. Timeout: In this mode, re-interpreted as the time to wait for all 334 packets in a burst to arrive, expressed in the existing timestamp 335 format used in TWAMP and OWAMP. In the case of lost packets, the 336 Session-Reflector is commanded to wait through this time-out for 337 packets in a burst to arrive. 339 3.4. Burst Gen and Meas: Accept Session Packet Format 341 The Accept Session command for the Burst feature is as shown in the 342 packet format below (assuming the Reflect Octets feature is also in 343 use). 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Accept | MBZ | Port | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 350 | | 351 | SID (16 octets) | 352 | | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Reflected octets | Server octets | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | MBZ (8 octets) | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 | HMAC (16 octets) | 362 | | 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 3.5. Burst Gen and Meas: Stopping Test Sessions 368 The Control-Client SHALL stop in-progress test sessions using any 369 standardized methods, including section 3.8 of [RFC5357] or the 370 optional capability of [RFC5938]. 372 3.6. Additional considerations 374 The value of the Modes Field sent by the Server in the Server 375 Greeting message is the bit-wise OR of the mode values that it is 376 willing to support during this session. 378 We note that Burst Generation and Measurement features are 379 incompatible with each other, and with the Symmetrical Size feature 380 described in [RFC6038], and MUST NOT be used in combination with 381 those features. 383 With the publication of this memo as an RFC, the last 9 bit positions 384 of the Modes 32-bit Field are used. A Control-Client conforming to 385 this extension of [RFC5357] MAY ignore the values in the higher bits 386 of the Modes Field, or it MAY support other features that are 387 communicated in those bit positions. The other bits are available 388 for future protocol extensions. 390 4. Burst Generation in TWAMP Test 392 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 393 protocol with the exception that the Session-Reflector transmits test 394 packets to the Session-Sender in response to each test packet it 395 receives. The Burst Generation feature modifies the behavior of 396 TWAMP section 4[RFC5357]. This mode requires the Session-Sender to 397 send a Burst-Initiation packet, and the Session-Reflector generates 398 test session packets according to the configuration agreed using the 399 TWAMP-Control protocol. 401 4.1. Sender Behavior 403 This section describes extensions to the behavior of the TWAMP 404 Session-Sender. 406 4.1.1. Packet Timings 408 The Send Schedule is not utilized in TWAMP, and this is unchanged in 409 this memo. 411 4.1.2. Packet Formats and Contents 413 The Session-Sender packet format and content follow the same 414 procedure and guidelines as defined in section 4.1.2 of [RFC4656] (as 415 indicated in section 4.1.2 of TWAMP [RFC5357]). 417 This mode uses the original TWAMP-Test Packet Padding Field (see 418 section 4.1.2 of [RFC4656]), or can be used with Reflect Octets 419 feature as shown below for unauthenticated mode: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Sequence Number | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Timestamp | 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Error Estimate | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 431 | | 432 | Packet Padding (to be reflected) | 433 . (length in octets specified in command) . 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 . . 436 . Additional Packet Padding . 437 . . 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Burst Initiation Packet Format 441 The Sequence Number, Timestamp, and Error Estimate fields are the 442 same as specified in section 4.1.2 of [RFC4656] in OWAMP. 444 We note that the format of the Burst Initiation packet has not been 445 changed from the usual Session-Sender test packet format, to simplify 446 adoption. 448 4.2. Reflector Behavior 450 The TWAMP Reflector differs significantly from the procedures and 451 guidelines in section 4.2 of [RFC5357]. The following new functions 452 MUST be performed: 454 o Recognition of the function of the Burst Initiation Packet used in 455 this mode. 457 o Generation of the required burst of test session packets, 458 according to the configuration agreed in Request-TW-Session 459 command, with the agreed number of packets in each burst and size 460 of each packet in the burst. 462 4.2.1. Session-Reflector Burst Packet Format and Contents 464 The Burst Generation feature retains the usual Reflector packet 465 fields, as shown below. When the Burst Generation mode is selected, 466 the Session-Reflector SHALL use the following TWAMP-Test Packet 467 Format in Unauthenticated mode (shown with Reflect Octets feature 468 activated): 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Sequence Number | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Timestamp | 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Error Estimate | MBZ | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Receive Timestamp | 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Sender Sequence Number | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Sender Timestamp | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Sender Error Estimate | MBZ | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Sender TTL | Packet Padding (from Session-Sender) | 491 +-+-+-+-+-+-+-+-+ + 492 . . 493 + +-+-+-+-+-+-+-+-+ 494 | Packet Padding (from Session-Sender) | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 496 | | 497 | | 498 . Additional Packet Padding . 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Section 4.2.1 of [RFC5357] describes the above fields as used in 502 TWAMP, with one exception. 504 The Sequence Number field SHALL indicate the sequence number of each 505 packet sent throughout the test session. The Sequence Number SHALL 506 be increased by 1 for each packet. The initial Sequence Number SHALL 507 be 0. 509 When one burst is complete, the Sequence Numbers SHALL continue to 510 increment by 1 in the packets generated in response to the next 511 burst. 513 The total Packet Padding octets SHALL have the length specified in 514 the TWAMP-Control request for the appropriate test session. The 515 Session-Reflector MAY need to generate its own packet padding, if the 516 Burst Request packet does not include this field (or contains 517 insufficient padding). 519 In any case, the Session-Reflector MAY re-use the Sender's Packet 520 Padding (since the requirements for padding generation are the same 521 for each) when possible. 523 The Session-Reflector SHALL send a series of TWAMP-Test Packets in 524 response to reception of the Burst Initiation Packet, according to 525 the configuration agreed in the Request-TW-Session command (number of 526 packets and padding), and as immediately as possible. The Session- 527 Reflector SHALL send all packets in a burst as close to back-to-back 528 as possible (recognizing that lower layers may have spacing 529 requirements that take precedence). 531 5. Burst Measurement in TWAMP Test 533 The Burst Measurement feature modifies the behavior of TWAMP section 534 4[RFC5357]. This mode requires the Session-Sender to send a Burst of 535 test packets, and the Session-Reflector measures the burst of packets 536 and reports the results in the Burst Response packet format(s), as 537 described below. 539 5.1. Sender Behavior 541 This section describes extensions to the behavior of the TWAMP 542 Session-Sender. 544 5.1.1. Packet Timings 546 The Session-Sender SHALL send all packets in a burst as close to 547 back-to-back as possible (recognizing that lower layers may have 548 spacing requirements that take precedence). 550 5.1.2. Packet Formats and Contents 552 The Session-Sender packet format and content SHALL comply with that 553 defined in section 4.1.2 of [RFC4656] (as indicated in section 4.1.2 554 of TWAMP [RFC5357]). 556 This mode uses the original TWAMP-Test Packet Padding Field (see 557 section 4.1.2 of [RFC4656]), or can be used with Reflect Octets 558 feature as shown below for unauthenticated mode: 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Burst Sequence Number | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Timestamp | 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Error Estimate | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 570 | | 571 | Packet Padding (to be reflected) | 572 . (length in octets specified in command) . 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 . . 575 . Additional Packet Padding . 576 . . 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Session-Sender Burst Test Packet Format 580 The Burst Sequence Number field SHALL indicate the number of each 581 burst. The Burst Sequence Number SHALL be increased by 1 for each 582 burst, and remain the same for each packet in a burst. The initial 583 number SHALL be 0. 585 When one burst is complete, the Burst Sequence Number used in the all 586 packets of the next burst SHALL be increased by 1. 588 5.2. Reflector Behavior 590 The TWAMP Reflector differs slightly from the procedures and 591 guidelines in section 4.2 of [RFC5357]. The following new functions 592 MUST be performed: 594 o Recognition of the function of the Session-Sender Burst Test 595 Packet Format used in this mode. 597 o Processing the required bursts of test session packets, according 598 to the configuration agreed in Request-TW-Session command, with 599 the agreed length of the burst in packets and size of each packet 600 in the burst, and the agreed Burst Time-out. 602 o Response with an abbreviated Session-Reflector test packet as 603 described below. For discussion, we will call this the 1-to-1 604 response. 606 o OR - Response with the new Burst Measurement Response packet 607 described below. For discussion, we will call this the 608 accumulated response. 610 We seek feedback from the IPPM working group on which of these two 611 alternatives is preferable. 613 5.2.1. Session-Reflector Burst Measurement Response Packet Format and 614 Contents 616 The Burst Measurement feature specifies a standard Session-Reflector 617 packet to communicate the results, as shown below. When the Burst 618 measurement mode is selected, the Session-Sender SHALL use the 619 following Burst Measurement Response packet Format in Unauthenticated 620 mode (shown with Reflect Octets feature also in use): 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Sequence Number | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Timestamp | 628 | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Error Estimate | MBZ | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 632 | Receive Timestamp | 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Sender Burst Sequence Number | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Sender Timestamp B 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Sender Error Estimate | MBZ | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Sender TTL | Packet Padding (from Session-Sender) | 643 +-+-+-+-+-+-+-+-+ + 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 646 Session-Reflector Measurement Packet (1-to-1 response) 648 Section 4.2.1 of [RFC5357] describes the fields in the 1-to-1 649 response packet above; they are the same as used in TWAMP. The main 650 difference is that Packet Padding SHALL be truncated on a 16 octet- 651 word boundary, returning the minimum information to the Session- 652 Sender. 654 All Timestamps SHALL be formatted according to the precedent set in 655 section 4.1.2 of [RFC4656], which is to use [RFC1305] (and updated 656 version), as follows: 658 "The first 32 bits represent the unsigned integer number of seconds 659 elapsed since 0h on 1 January 1900; the next 32 bits represent the 660 fractional part of a second that has elapsed since then." 662 The Session-Reflector MUST truncate the Sender's Packet Padding, 663 unless the Reflect Octets feature is also active in which case the 664 Session_Reflector MAY re-use the Sender's Packet Padding (since the 665 requirements for padding generation are the same for each) to reach a 666 word boundary. 668 The Sender Timestamp field SHALL have the sender's timestamp from 669 each packet received in the burst. 671 In 1-to-1 response mode, the Session-Reflector SHALL send a Session- 672 Reflector Measurement Packet in response to every Session-Sender 673 packet received, and as quickly as possible. 675 ======================================================== 677 In the accumulated response alternative, the Session-Reflector 678 creates and holds all packet headers described above in a buffer, and 679 sends them all at once in a single Session-Reflector test packet. 680 The length of the burst and the path MTU MUST be coordinated to avoid 681 fragmentation. 683 The first Session-Sender packet to arrive with a previously unseen 684 Burst Sequence Number SHALL be designated as the "First" packet in 685 that burst, and its timestamp is used in processing below. 687 As subsequent packets arrive, Session-Reflector SHALL: 689 o Maintain a count of packets with the same Burst Sequence Number 690 (one burst). 692 o Time stamp each packet as it arrives and store the time stamp in a 693 response packet structure with all fields complete, as in the 694 1-to-1 alternative. 696 When 698 o The count of packets with the same Burst Sequence Number equals 699 the agreed Burst Length, OR 701 o The agreed Timeout expires (computed by a the time to the "First" 702 Packet Timestamp), OR 704 o The Burst Sequence Number increases from previous packets 705 (indicating a new Burst is in progress), 707 then the current burst is determined to be complete. 709 When the Burst is complete, the Session-Reflector SHALL terminate the 710 current burst processing as described above and send the Burst 711 Measurement Response Packet to the Session-Sender as immediately as 712 possible. 714 In Accumulated Response, the Burst Measurement Response Packet is a 715 single packet with the concatenation of all previously-generated 716 response packet formats in the information field. 718 6. Special Case of One-packet Bursts 720 When the Number of Packets field in the Request-TW-Session command 721 equals 1, then the Burst Generation and Measurement modes are reduced 722 to test sessions with controlled, asymmetrical packet sizes. A 723 minimal size packet travels in one direction, and the measured 724 direction uses a packet with all Packet Padding specified in the 725 Request-TW-Session command. 727 7. Security Considerations 729 These extended modes of operation do not appear to permit any new 730 attacks on hosts communicating with core TWAMP [RFC5357]. 732 The security considerations that apply to any active measurement of 733 live networks are relevant here as well. See [RFC4656] and 734 [RFC5357]. 736 8. IANA Considerations 738 This memo adds two modes to the IANA registry for the TWAMP Modes 739 Field, and describes behavior when the new modes are used. This 740 field is a recognized extension mechanism for TWAMP. 742 8.1. Registry Specification 744 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 745 TWAMP-Modes are specified in TWAMP Server Greeting messages and 746 Set-up Response messages, as described in section 3.1 of [RFC5357], 747 consistent with section 3.1 of [RFC4656], and extended by this memo. 748 Modes are indicated by setting bits in the 32-bit Modes field that 749 correspond to values in the Modes registry. For the TWAMP-Modes 750 registry, we expect that new features will be assigned increasing 751 registry values that correspond to single bit positions, unless there 752 is a good reason to do otherwise (more complex encoding than single 753 bit positions may be used in the future, to access the 2^32 value 754 space). 756 8.2. Registry Contents 758 TWAMP Modes Registry is recommended to be augmented as follows: 760 Value Description Semantics Definition 761 -------------------------------------------------------- 762 xxx Burst Generation this memo, section 3.1 763 Capability new bit position (X) 764 yyy Burst Measurement this memo, section 3.1 765 new bit position (Y) 767 >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values 769 The suggested values are 771 X=7, xxx=128 773 Y=8, yyy=256 <<<< 775 9. Acknowledgements 777 The authors thank Chistofer Flinta for review and comment. 779 10. References 781 10.1. Normative References 783 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 784 Specification, Implementation", RFC 1305, March 1992. 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 790 Zekauskas, "A One-way Active Measurement Protocol 791 (OWAMP)", RFC 4656, September 2006. 793 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 795 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 796 RFC 5357, October 2008. 798 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 799 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 800 August 2009. 802 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 803 Feature for the Two-Way Active Measurement Protocol 804 (TWAMP)", RFC 5938, August 2010. 806 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 807 Protocol (TWAMP) Reflect Octets and Symmetrical Size 808 Features", RFC 6038, October 2010. 810 10.2. Informative References 812 [I-D.ietf-ippm-rate-problem] 813 Morton, A., "Rate Measurement Test Protocol Problem 814 Statement", draft-ietf-ippm-rate-problem-02 (work in 815 progress), February 2013. 817 [I-D.morton-ippm-lmap-path] 818 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 819 A. Morton, "A Reference Path and Measurement Points for 820 LMAP", draft-morton-ippm-lmap-path-00 (work in progress), 821 January 2013. 823 Authors' Addresses 825 Al Morton 826 AT&T Labs 827 200 Laurel Avenue South 828 Middletown,, NJ 07748 829 USA 831 Phone: +1 732 420 1571 832 Fax: +1 732 368 1192 833 Email: acmorton@att.com 834 URI: http://home.comcast.net/~acmacm/ 835 Len Ciavattone 836 AT&T Labs 837 200 Laurel Avenue South 838 Middletown,, NJ 07748 839 USA 841 Phone: +1 732 420 1239 842 Fax: 843 Email: lencia@att.com 844 URI: