idnits 2.17.1 draft-morton-ippm-twamp-rate-05.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 13, 2014) is 3723 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-05 Summary: 1 error (**), 0 flaws (~~), 2 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 13, 2014 6 Expires: August 17, 2014 8 TWAMP Burst Rate Measurement Features 9 draft-morton-ippm-twamp-rate-05 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 of TCP transport instead of UDP may be desirable, 23 but is deferred to other 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 17, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Alternate Transport Protocol Selection . . . . . . . . . 3 67 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 68 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . 5 69 3.1. Connection Setup with New Features . . . . . . . . . . . 5 70 3.2. Burst Generation: Request-TW-Session Packet Format . . . 5 71 3.3. Burst Measurement: Request-TW-Session Packet Format . . . 7 72 3.4. Burst Gen and Meas: Accept Session Packet Format . . . . 8 73 3.5. Burst Gen and Meas: Stopping Test Sessions . . . . . . . 8 74 3.6. Additional considerations . . . . . . . . . . . . . . . . 8 75 4. Burst Generation in TWAMP Test . . . . . . . . . . . . . . . 9 76 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . 9 78 4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 9 79 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . 10 80 4.2.1. Session-Reflector Burst Packet Format and Contents . 10 81 5. Burst Measurement in TWAMP Test . . . . . . . . . . . . . . . 12 82 5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 12 83 5.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . 12 84 5.1.2. Packet Formats and Contents . . . . . . . . . . . . . 12 85 5.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . 13 86 5.2.1. Session-Reflector Burst Measurement Response Packet 87 Format and Contents . . . . . . . . . . . . . . . . . 14 88 6. Special Case of One-packet Bursts . . . . . . . . . . . . . . 16 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 8.1. Registry Specification . . . . . . . . . . . . . . . . . 16 92 8.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 17 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 96 10.2. Informative References . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Burst Initiation Packet Format 442 The Sequence Number, Timestamp, and Error Estimate fields are the 443 same as specified in section 4.1.2 of [RFC4656] in OWAMP. 445 We note that the format of the Burst Initiation packet has not been 446 changed from the usual Session-Sender test packet format, to simplify 447 adoption. 449 4.2. Reflector Behavior 451 The TWAMP Reflector differs significantly from the procedures and 452 guidelines in section 4.2 of [RFC5357]. The following new functions 453 MUST be performed: 455 o Recognition of the function of the Burst Initiation Packet used in 456 this mode. 458 o Generation of the required burst of test session packets, 459 according to the configuration agreed in Request-TW-Session 460 command, with the agreed number of packets in each burst and size 461 of each packet in the burst. 463 4.2.1. Session-Reflector Burst Packet Format and Contents 465 The Burst Generation feature retains the usual Reflector packet 466 fields, as shown below. When the Burst Generation mode is selected, 467 the Session-Reflector SHALL use the following TWAMP-Test Packet 468 Format in Unauthenticated mode (shown with Reflect Octets feature 469 activated): 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Sequence Number | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Timestamp | 477 | | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Error Estimate | MBZ | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Receive Timestamp | 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Sender Sequence Number | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Sender Timestamp | 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Sender Error Estimate | MBZ | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Sender TTL | Packet Padding (from Session-Sender) | 492 +-+-+-+-+-+-+-+-+ + 493 . . 494 + +-+-+-+-+-+-+-+-+ 495 | Packet Padding (from Session-Sender) | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 497 | | 498 | | 499 . Additional Packet Padding . 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Section 4.2.1 of [RFC5357] describes the above fields as used in 503 TWAMP, with one exception. 505 The Sequence Number field SHALL indicate the sequence number of each 506 packet sent throughout the test session. The Sequence Number SHALL 507 be increased by 1 for each packet. The initial Sequence Number SHALL 508 be 0. 510 When one burst is complete, the Sequence Numbers SHALL continue to 511 increment by 1 in the packets generated in response to the next 512 burst. 514 The total Packet Padding octets SHALL have the length specified in 515 the TWAMP-Control request for the appropriate test session. The 516 Session-Reflector MAY need to generate its own packet padding, if the 517 Burst Request packet does not include this field (or contains 518 insufficient padding). 520 In any case, the Session-Reflector MAY re-use the Sender's Packet 521 Padding (since the requirements for padding generation are the same 522 for each) when possible. 524 The Session-Reflector SHALL send a series of TWAMP-Test Packets in 525 response to reception of the Burst Initiation Packet, according to 526 the configuration agreed in the Request-TW-Session command (number of 527 packets and padding), and as immediately as possible. The Session- 528 Reflector SHALL send all packets in a burst as close to back-to-back 529 as possible (recognizing that lower layers may have spacing 530 requirements that take precedence). 532 5. Burst Measurement in TWAMP Test 534 The Burst Measurement feature modifies the behavior of TWAMP section 535 4[RFC5357]. This mode requires the Session-Sender to send a Burst of 536 test packets, and the Session-Reflector measures the burst of packets 537 and reports the results in the Burst Response packet format(s), as 538 described below. 540 5.1. Sender Behavior 542 This section describes extensions to the behavior of the TWAMP 543 Session-Sender. 545 5.1.1. Packet Timings 547 The Session-Sender SHALL send all packets in a burst as close to 548 back-to-back as possible (recognizing that lower layers may have 549 spacing requirements that take precedence). 551 5.1.2. Packet Formats and Contents 553 The Session-Sender packet format and content SHALL comply with that 554 defined in section 4.1.2 of [RFC4656] (as indicated in section 4.1.2 555 of TWAMP [RFC5357]). 557 This mode uses the original TWAMP-Test Packet Padding Field (see 558 section 4.1.2 of [RFC4656]), or can be used with Reflect Octets 559 feature as shown below for unauthenticated mode: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Burst Sequence Number | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Timestamp | 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Error Estimate | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 571 | | 572 | Packet Padding (to be reflected) | 573 . (length in octets specified in command) . 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 . . 576 . Additional Packet Padding . 577 . . 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Session-Sender Burst Test Packet Format 582 The Burst Sequence Number field SHALL indicate the number of each 583 burst. The Burst Sequence Number SHALL be increased by 1 for each 584 burst, and remain the same for each packet in a burst. The initial 585 number SHALL be 0. 587 When one burst is complete, the Burst Sequence Number used in the all 588 packets of the next burst SHALL be increased by 1. 590 5.2. Reflector Behavior 592 The TWAMP Reflector differs slightly from the procedures and 593 guidelines in section 4.2 of [RFC5357]. The following new functions 594 MUST be performed: 596 o Recognition of the function of the Session-Sender Burst Test 597 Packet Format used in this mode. 599 o Processing the required bursts of test session packets, according 600 to the configuration agreed in Request-TW-Session command, with 601 the agreed length of the burst in packets and size of each packet 602 in the burst, and the agreed Burst Time-out. 604 o Response with an abbreviated Session-Reflector test packet as 605 described below. For discussion, we will call this the 1-to-1 606 response. 608 o OR - Response with the new Burst Measurement Response packet 609 described below. For discussion, we will call this the 610 accumulated response. 612 We seek feedback from the IPPM working group on which of these two 613 alternatives is preferable. 615 5.2.1. Session-Reflector Burst Measurement Response Packet Format and 616 Contents 618 The Burst Measurement feature specifies a standard Session-Reflector 619 packet to communicate the results, as shown below. When the Burst 620 measurement mode is selected, the Session-Sender SHALL use the 621 following Burst Measurement Response packet Format in Unauthenticated 622 mode (shown with Reflect Octets feature also in use): 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Sequence Number | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Timestamp | 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Error Estimate | MBZ | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 634 | Receive Timestamp | 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Sender Burst Sequence Number | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Sender Timestamp B 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Sender Error Estimate | MBZ | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Sender TTL | Packet Padding (from Session-Sender) | 645 +-+-+-+-+-+-+-+-+ + 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 649 Session-Reflector Measurement Packet (1-to-1 response) 651 Section 4.2.1 of [RFC5357] describes the fields in the 1-to-1 652 response packet above; they are the same as used in TWAMP. The main 653 difference is that Packet Padding SHALL be truncated on a 16 octet- 654 word boundary, returning the minimum information to the Session- 655 Sender. 657 All Timestamps SHALL be formatted according to the precedent set in 658 section 4.1.2 of [RFC4656], which is to use [RFC1305] (and updated 659 version), as follows: 661 "The first 32 bits represent the unsigned integer number of seconds 662 elapsed since 0h on 1 January 1900; the next 32 bits represent the 663 fractional part of a second that has elapsed since then." 665 The Session-Reflector MUST truncate the Sender's Packet Padding, 666 unless the Reflect Octets feature is also active in which case the 667 Session_Reflector MAY re-use the Sender's Packet Padding (since the 668 requirements for padding generation are the same for each) to reach a 669 word boundary. 671 The Sender Timestamp field SHALL have the sender's timestamp from 672 each packet received in the burst. 674 In 1-to-1 response mode, the Session-Reflector SHALL send a Session- 675 Reflector Measurement Packet in response to every Session-Sender 676 packet received, and as quickly as possible. 678 ======================================================== 680 In the accumulated response alternative, the Session-Reflector 681 creates and holds all packet headers described above in a buffer, and 682 sends them all at once in a single Session-Reflector test packet. 683 The length of the burst and the path MTU MUST be coordinated to avoid 684 fragmentation. 686 The first Session-Sender packet to arrive with a previously unseen 687 Burst Sequence Number SHALL be designated as the "First" packet in 688 that burst, and its timestamp is used in processing below. 690 As subsequent packets arrive, Session-Reflector SHALL: 692 o Maintain a count of packets with the same Burst Sequence Number 693 (one burst). 695 o Time stamp each packet as it arrives and store the time stamp in a 696 response packet structure with all fields complete, as in the 697 1-to-1 alternative. 699 When 701 o The count of packets with the same Burst Sequence Number equals 702 the agreed Burst Length, OR 704 o The agreed Timeout expires (computed by a the time to the "First" 705 Packet Timestamp), OR 707 o The Burst Sequence Number increases from previous packets 708 (indicating a new Burst is in progress), 710 then the current burst is determined to be complete. 712 When the Burst is complete, the Session-Reflector SHALL terminate the 713 current burst processing as described above and send the Burst 714 Measurement Response Packet to the Session-Sender as immediately as 715 possible. 717 In Accumulated Response, the Burst Measurement Response Packet is a 718 single packet with the concatenation of all previously-generated 719 response packet formats in the information field. 721 6. Special Case of One-packet Bursts 723 When the Number of Packets field in the Request-TW-Session command 724 equals 1, then the Burst Generation and Measurement modes are reduced 725 to test sessions with controlled, asymmetrical packet sizes. A 726 minimal size packet travels in one direction, and the measured 727 direction uses a packet with all Packet Padding specified in the 728 Request-TW-Session command. 730 7. Security Considerations 732 These extended modes of operation do not appear to permit any new 733 attacks on hosts communicating with core TWAMP [RFC5357]. 735 The security considerations that apply to any active measurement of 736 live networks are relevant here as well. See [RFC4656] and 737 [RFC5357]. 739 8. IANA Considerations 741 This memo adds two modes to the IANA registry for the TWAMP Modes 742 Field, and describes behavior when the new modes are used. This 743 field is a recognized extension mechanism for TWAMP. 745 8.1. Registry Specification 747 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 748 TWAMP-Modes are specified in TWAMP Server Greeting messages and Set- 749 up Response messages, as described in section 3.1 of [RFC5357], 750 consistent with section 3.1 of [RFC4656], and extended by this memo. 751 Modes are indicated by setting bits in the 32-bit Modes field that 752 correspond to values in the Modes registry. For the TWAMP-Modes 753 registry, we expect that new features will be assigned increasing 754 registry values that correspond to single bit positions, unless there 755 is a good reason to do otherwise (more complex encoding than single 756 bit positions may be used in the future, to access the 2^32 value 757 space). 759 8.2. Registry Contents 761 TWAMP Modes Registry is recommended to be augmented as follows: 763 Value Description Semantics Definition 764 -------------------------------------------------------- 765 xxx Burst Generation this memo, section 3.1 766 Capability new bit position (X) 767 yyy Burst Measurement this memo, section 3.1 768 new bit position (Y) 770 >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values 772 The suggested values are 774 X=7, xxx=128 776 Y=8, yyy=256 <<<< 778 9. Acknowledgements 780 The authors thank Chistofer Flinta for review and comment. 782 10. References 784 10.1. Normative References 786 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 787 Specification, Implementation", RFC 1305, March 1992. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 793 Zekauskas, "A One-way Active Measurement Protocol 794 (OWAMP)", RFC 4656, September 2006. 796 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 797 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 798 RFC 5357, October 2008. 800 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 801 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 802 August 2009. 804 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 805 Feature for the Two-Way Active Measurement Protocol 806 (TWAMP)", RFC 5938, August 2010. 808 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 809 Protocol (TWAMP) Reflect Octets and Symmetrical Size 810 Features", RFC 6038, October 2010. 812 10.2. Informative References 814 [I-D.ietf-ippm-rate-problem] 815 Morton, A., "Rate Measurement Test Protocol Problem 816 Statement", draft-ietf-ippm-rate-problem-05 (work in 817 progress), December 2013. 819 [I-D.morton-ippm-lmap-path] 820 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 821 A. Morton, "A Reference Path and Measurement Points for 822 LMAP", draft-morton-ippm-lmap-path-01 (work in progress), 823 February 2013. 825 Authors' Addresses 827 Al Morton 828 AT&T Labs 829 200 Laurel Avenue South 830 Middletown,, NJ 07748 831 USA 833 Phone: +1 732 420 1571 834 Fax: +1 732 368 1192 835 Email: acmorton@att.com 836 URI: http://home.comcast.net/~acmacm/ 838 Len Ciavattone 839 AT&T Labs 840 200 Laurel Avenue South 841 Middletown,, NJ 07748 842 USA 844 Phone: +1 732 420 1239 845 Email: lencia@att.com