idnits 2.17.1 draft-ietf-ippm-twamp-reflect-octets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 26, 2008) is 5661 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) == Missing Reference: '0-31' is mentioned on line 588, but not defined == Unused Reference: 'RFC2434' is defined on line 637, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ippm-more-twamp-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Intended status: Standards Track AT&T Labs 5 Expires: April 29, 2009 October 26, 2008 7 TWAMP Reflect Octets Feature 8 draft-ietf-ippm-twamp-reflect-octets-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2009. 35 Abstract 37 The IETF has completed its work on the core specification of TWAMP - 38 the Two-Way Active Measurement Protocol. This memo describes a new 39 feature for TWAMP: an optional capability where the responder host 40 returns some of the command octets or padding octets to the 41 controller, and/or ensures that the same test packet sizes are used 42 in both directions. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 54 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4 55 3.1. Connection Setup with Reflect Padding Feature . . . . . . 4 56 3.2. Request-TW-Session Packet Format . . . . . . . . . . . . . 5 57 3.3. Accept Session Packet Format . . . . . . . . . . . . . . . 7 58 3.4. Additional considerations . . . . . . . . . . . . . . . . 7 59 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 8 60 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 8 61 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 8 62 4.1.2. Packet Formats and Contents . . . . . . . . . . . . . 8 63 4.1.3. Padding Truncation . . . . . . . . . . . . . . . . . . 9 64 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 10 65 4.2.1. Packet Format and Contents . . . . . . . . . . . . . . 10 66 4.2.2. Padding Truncation . . . . . . . . . . . . . . . . . . 11 67 5. Possible Alternative . . . . . . . . . . . . . . . . . . . . . 12 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Registry Specification . . . . . . . . . . . . . . . . . . 15 71 7.2. Registry Management . . . . . . . . . . . . . . . . . . . 15 72 7.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 15 73 7.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 15 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . . . 18 81 1. Introduction 83 The IETF has completed its work on the core specification of TWAMP - 84 the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an 85 extension of the One-way Active Measurement Protocol, OWAMP 86 [RFC4656]. The TWAMP specification gathered wide review as it 87 approached completion, and the by-products were several 88 recommendations for new features in TWAMP. There are a growing 89 number TWAMP implementations at present, and wide-spread usage is 90 expected. There are even devices that are designed to test 91 implementations for protocol compliance. 93 This memo describes a new feature for TWAMP. This feature adds the 94 OPTIONAL capability for the responder host to return a limited number 95 of unassigned (padding) octets to the Control-Client or Session- 96 Sender entities. With this capability, the Control-Client or 97 Session-Sender can embed octets of information it deems useful and 98 have the assurance that the corresponding reply/test packet will 99 contain that information when it is reflected and returned (by the 100 Server or Session-Reflector. The feature also adds the Session- 101 Reflector capability to assure that reflected test packets SHALL have 102 their padding octets truncated, so that TWAMP-Test protocol uses the 103 same packet size in both directions of transmission. 105 The relationship between this memo and TWAMP is intended to be an 106 update to [RFC5357] when published. 108 2. Purpose and Scope 110 The purpose of this memo is to describe a new feature for TWAMP 111 [RFC5357]. The feature enhances the TWAMP responder's capabilities 112 to perform simple operations on control and test packets: the 113 reflection of octets or padding and the guaranteed truncation of 114 padding to compensate for the different sizes of TWAMP fields in the 115 test packets. Motivations include permitting the controller host to 116 tag packets with an index for simplified identification, and/or 117 assert that the same size test packets MUST be used in each 118 direction. 120 The scope of the memo is currently limited to specifications of the 121 following feature: 123 o Extension of the modes of operation through assignment of new 124 values in the Mode Field (see section 3.1 [RFC4656] for the format 125 of the Server Greeting message), while retaining backward 126 compatibility with the core TWAMP [RFC5357] implementations. 127 These two values identify the ability of the Server/ 128 Session-Reflector to reflect specific octets back to the Client/ 129 Session-Sender, and/or to truncate padding octets and ensure that 130 TWAMP-Test protocol uses the same packet size in both directions. 132 3. TWAMP Control Extensions 134 TWAMP-Control protocol [RFC5357] uses the Modes Field to identify and 135 select specific communication capabilities, and this field is a 136 recognized extension mechanism. The following sections describe one 137 such extension. 139 3.1. Connection Setup with Reflect Padding Feature 141 TWAMP connection establishment follows the procedure defined in 142 section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new 143 feature requires two new bit positions (and values) to identify the 144 ability of the Server/Session-Reflector to reflect specific octets 145 back to the Control-Client/Session-Sender, and to truncate padding 146 octets when required. With this added feature, the complete set of 147 TWAMP Modes Field bit positions and values would be as follows: 149 Value Description Reference/Explanation 150 0 Reserved 151 1 Unauthenticated RFC4656, Section 3.1 152 2 Authenticated RFC4656, Section 3.1 153 4 Encrypted RFC4656, Section 3.1 154 8 Unauth. TEST protocol, draft-ietf-more-twamp (3) 155 Encrypted CONTROL 156 -------------------------------------------------------- 157 xxx Reflect Octets new bit position (X) 158 Capability 159 yyy Truncate Padding new bit position (Y) 160 Capability 162 In the original OWAMP Modes Field, setting bit positions 0, 1 or 2 163 indicated the security mode of the Control protocol, and the Test 164 protocol inherited the same mode (see section 4 of [RFC4656]). In 165 the memo [I-D.ietf-ippm-more-twamp], bit position 3 allows 166 unauthenticated TWAMP Test protocol to be used with encryption on the 167 TWAMP-Control protocol. 169 The Server sets one or both of the new bit positions (X and Y) in the 170 Modes Field of the Server Greeting message to indicate its 171 capabilities and willingness to operate in these modes if desired. 172 >>>IANA: change X and Y to the assigned values <<< 173 If the Control-Client intends to operate all test sessions invoked 174 with this control connection using one or both of the new modes, it 175 MUST set the Modes Field bit corresponding to that function in the 176 Setup Response message. 178 3.2. Request-TW-Session Packet Format 180 The bits designated for the Reflect Octets feature in the Request-TW- 181 Session command are as shown in the packet format below. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Number of Schedule Slots | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 . . 191 . ... Many fields (66 octets) not shown ... . 192 . . 193 . . 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Padding Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Start Time, (8 octets) | 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Timeout, (8 octets) | 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type-P Descriptor | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Octets to be reflected | Length of padding to reflect | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | MBZ (4 octets) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 | HMAC (16 octets) | 211 | | 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 The "Padding Length" Field *continues* to specify the number of 216 padding octets that the Session-Sender will append to ALL TWAMP-Test 217 packets associated with this test session. See below for 218 considerations on the minimum length of the padding octets, 219 especially when complying with the options described in this memo, 220 following the definitions of the two new fields that follow the 221 Type-P Descriptor. 223 Note that the number of padding octets appended to the Session- 224 Reflector's test packet depends on support for the OPTIONAL Truncate 225 Padding mode, or the RECOMMENDED truncation process in TWAMP section 226 4.2.1 [RFC5357]. 228 The "Octets to be reflected" Field SHALL be 2 octets long, as shown 229 and contains the octets that the Server MUST reflect in the Accept 230 Session message as specified below. 232 The "Length of padding to reflect" Field SHALL be 2 octets long, and 233 contain an unsigned binary value in units of octets. This field 234 communicates the length of the padding in the TWAMP-Test Packet that 235 the Session-Sender expects to be reflected, and the length of octets 236 that the Session-Reflector SHALL return in include in its TWAMP-Test 237 packet format (see section 4.2). By including this length field in 238 the Request-TW-Session message, a Server is able to determine if it 239 can comply with a specific request to reflect padding in the TWAMP- 240 Test packets, and to arrange for the Session-Reflector processing in 241 advance. 243 The "Padding Length" SHOULD be >= 27 octets when specifying a test 244 session using the Unauthenticated TWAMP-Test mode, to allow for the 245 RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357]. 247 The "Padding Length" SHOULD be >= 56 octets when specifying a test 248 session using the Authenticated or Encrypted TWAMP-Test modes, to 249 allow for the RECOMMENDED truncation process in TWAMP section 4.2.1 250 [RFC5357]. 252 The "Padding Length" SHALL be > the "Length of padding to reflect" 253 when specifying a test session using the OPTIONAL Reflect Octets 254 mode. 256 The "Padding Length" SHALL be >= 27 + "Length of padding to reflect" 257 octets when specifying a test session using BOTH the OPTIONAL Reflect 258 Octets mode and OPTIONAL Truncate Padding mode with the 259 Unauthenticated TWAMP-Test mode. 261 The "Padding Length" SHALL be >= 56 + "Length of padding to reflect" 262 octets when specifying a test session using BOTH the OPTIONAL Reflect 263 Octets mode and OPTIONAL Truncate Padding mode with the Authenticated 264 or Encrypted TWAMP-Test modes. 266 3.3. Accept Session Packet Format 268 The bits designated for the Reflect Padding feature in the Accept 269 Session command are as shown in the packet format below. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Accept | MBZ | Port | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 276 | | 277 | SID (16 octets) | 278 | | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reflected octets | MBZ (2 octets) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | MBZ (8 octets) | 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 | HMAC (16 octets) | 288 | | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 The "Reflected octets" field SHALL contain the octets from the 293 Request-TW-Session "Octets to be reflected" Field, and be 2 octets 294 long, as shown. 296 In Truncate Padding mode, IF calculations on the Padding lengths 297 reveal that there are insufficient octets supplied to produce equal- 298 length Session-Sender and Session-Reflector test packets, then the 299 Accept Field MUST be set to 3 = some aspect of the request is not 300 supported. 302 3.4. Additional considerations 304 The value of the Modes Field sent by the Server in the Server 305 Greeting message is the bit-wise OR of the mode values that it is 306 willing to support during this session. 308 Thus, the last six bits of the Modes 32-bit Field are used. A client 309 conforming to this extension of [RFC5357] MAY ignore the values in 310 the first 24 bits of the Modes Field, or it MAY support other 311 features that are communicated in these bit positions. (The first 24 312 bits are available for future protocol extensions.) 313 Other ways in which TWAMP extends OWAMP are described in [RFC5357]. 315 4. Extended TWAMP Test 317 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 318 protocol with the exception that the Session-Reflector transmits test 319 packets to the Session-Sender in response to each test packet it 320 receives. TWAMP section 4[RFC5357] defines two additional test 321 packet formats for packets transmitted by the Session-Reflector. The 322 appropriate format depends on the security mode chosen. The new 323 modes specified here utilize some of the padding octets within each 324 test packet format, or require truncation of those octets depending 325 on the security mode in use. 327 4.1. Sender Behavior 329 This section describes extensions to the behavior of the TWAMP 330 Session-Sender. 332 4.1.1. Packet Timings 334 The Send Schedule is not utilized in TWAMP, and this is unchanged in 335 this memo. 337 4.1.2. Packet Formats and Contents 339 The Session-Sender packet format and content follow the same 340 procedure and guidelines as defined in section 4.1.2 of [RFC4656] (as 341 indicated in section 4.1.2 of TWAMP [RFC5357]). 343 The Reflect octets mode re-designates the original TWAMP-Test (and 344 OWAMP-Test) Packet Padding Field (see section 4.1.2 of [RFC4656]), as 345 shown below for unauthenticated mode: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Sequence Number | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Timestamp | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Error Estimate | MBZ (2 octets) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 | Packet Padding (to be reflected) | 359 . (length in octets specified elsewhere) . 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 . . 362 . Additional Packet Padding . 363 . . 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 The "Packet Padding (to be reflected)" Field SHALL correspond to the 367 length of octets specified in the Request-TW-Session "Length of 368 padding to reflect" Field to this test session. These are the octets 369 that the Session-Sender expects will be returned by the Session- 370 Reflector. 372 The length of the "Additional Packet Padding" Field is the difference 373 between two fields in the Request-TW-Session command, as follows: 375 "Additional Packet Padding", in octets = 377 "Padding Length" - "Length of padding to reflect" 379 4.1.3. Padding Truncation 381 When the Truncate Padding mode is selected and communicated in the 382 Setup Response message, the Session-Sender MUST anticipate a minimum 383 padding required to achieve equal size test packets in both 384 directions. The amount of padding needed depends on BOTH the 385 security mode (Unauthenticated/Authenticated/Encrypted) and whether 386 the Reflect Octets mode is selected simultaneously. 388 When using the Truncate Padding mode, the Session-Sender MUST append 389 sufficient Packet Padding octets to allow the same IP packet payload 390 lengths to be used in each direction of transmission (this is usually 391 desirable). To compensate for the Session-Reflector's larger test 392 packet format, the Session-Sender MUST append at least 27 octets of 393 padding in Unauthenticated mode, and at least 56 octets in 394 Authenticated and Encrypted modes. 396 When using the Reflect Octets mode simultaneously with the Truncate 397 Padding mode, the Session-Sender MUST append at least 27 octets of 398 padding plus the "Length of the padding to reflect" octets when 399 operating in Unauthenticated mode. The Session-Sender MUST append at 400 least 56 octets of padding plus the "Length of the padding to 401 reflect" octets when operating in Authenticated and Encrypted modes. 403 4.2. Reflector Behavior 405 The TWAMP Reflector follows the procedures and guidelines in section 406 4.2 of [RFC5357], with the following additional functions: 408 o Reflect Octets mode: Designated octets in the "Packet Padding (to 409 be reflected)" field of the Session-Sender's test packet MUST be 410 included in the Session-Reflector's test packet. 412 o Truncate Padding mode: Octets in the packet padding field of the 413 Session-Sender's test packet MUST be truncated so that the length 414 of the Session-Reflector's test packet equals the length of the 415 Session-Sender's test packet. 417 4.2.1. Packet Format and Contents 419 The Reflect Padding feature re-designates the packet padding field, 420 as shown below for unauthenticated mode: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Sequence Number | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Timestamp | 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Error Estimate | MBZ | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Receive Timestamp | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Sender Sequence Number | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Sender Timestamp | 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Sender Error Estimate | MBZ | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Sender TTL | Packet Padding (from Session-Sender) | 443 +-+-+-+-+-+-+-+-+ + 444 . . 445 . Packet Padding (from Session-Sender) . 446 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | | 448 +-+-+-+-+-+-+-+-+ + 449 . Additional Packet Padding . 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 The "Packet Padding (from Session-Sender)" field MUST be the same 452 octets as the "Packet Padding (to be reflected)" field in the 453 Session-Sender's test packet, and therefore MUST conform to the 454 length specified in the Request-TW-Session message. 456 IF the test packet length is truncated within the padding fields in 457 conformance with the RECOMMENDED truncation process in TWAMP section 458 4.2.1 [RFC5357], THEN ALL padding designated to be reflected MUST be 459 reflected by Session-Reflectors using this feature. 461 4.2.2. Padding Truncation 463 Note that the Session-Reflector Test Packet Formats are larger than 464 the Sender's formats. When the Truncate Padding mode is selected and 465 communicated in the Setup Response message, the Session-Reflector 466 must truncate a specific number of padding octets to achieve equal 467 size test packets in both directions. The number of octets truncated 468 depends on BOTH the security mode (Unauthenticated/Authenticated/ 469 Encrypted) and whether the Reflect octets mode is selected 470 simultaneously. 472 When using the Truncate Padding mode, the Session-Reflector MUST 473 truncate exactly 27 octets of padding in Unauthenticated mode, and 474 exactly 56 octets in Authenticated and Encrypted modes. The Session- 475 Reflector MAY re-use the Sender's Packet Padding (since the 476 requirements for padding generation are the same for each), and in 477 this case the Session-Reflector MUST truncate the padding such that 478 the highest number octets are discarded. 480 When simultaneously using the Truncate Padding mode AND Reflect 481 octets mode, the Session-Reflector MUST reflect the designated octets 482 from the Session-Sender's test packet in the "Packet Padding (from 483 Session-Sender)" Field, and MAY re-use additional Packet Padding from 484 the Session-Sender. The Session-Reflector MUST truncate the padding 485 such that the highest number octets are discarded, and the test 486 packet length equals the Session-Sender's packet length. 488 5. Possible Alternative 490 If new TWAMP-Test packet formats are defined, the Reflect Octets and 491 Truncate Padding modes could be folded into one new mode. 493 This Alternative is illustrated for discussion purposes. 495 New Session-Sender Test Packet Format: 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Sequence Number | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Timestamp | 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Error Estimate | MBZ (2 octets) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 | | 509 | | 510 | Discard Fill | 511 | | 512 | | 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | | 516 | Packet Padding (to be reflected) | 517 . (length in octets specified elsewhere) . 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 . . 520 . Additional Packet Padding . 521 . . 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 The "Discard Fill" octets are discarded at the Session-Reflector. 525 New Session-Reflector Test Packet format: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Sequence Number | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Timestamp | 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Error Estimate | MBZ | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Receive Timestamp | 538 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Sender Sequence Number | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Sender Timestamp | 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Sender Error Estimate | MBZ | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Sender TTL | MBZ (3 octets) | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 . . 550 . Packet Padding (from Session-Sender) . 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 . Additional Packet Padding . 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 6. Security Considerations 558 These extended modes of operation do not appear to permit any new 559 attacks on hosts communicating with core TWAMP [RFC5357] ??? 561 The security considerations that apply to any active measurement of 562 live networks are relevant here as well. See [RFC4656] and 563 [RFC5357]. 565 7. IANA Considerations 567 This memo adds two mode combinations to the IANA registry for the 568 TWAMP Modes Field, and describes behavior when the new modes are 569 used. This field is a recognized extension mechanism for TWAMP. 571 7.1. Registry Specification 573 IANA has created a TWAMP-Modes registry (as requested in 574 [I-D.ietf-ippm-more-twamp]). TWAMP-Modes are specified in TWAMP 575 Server Greeting messages and Set-up Response messages, as described 576 in section 3.1 of [RFC5357], consistent with section 3.1 of 577 [RFC4656], and extended by this memo. Modes are indicated by setting 578 bits in the 32-bit Modes field. Thus, this registry can contain a 579 total of 32 possible values. 581 7.2. Registry Management 583 Because the Modes registry can contain only thirty-two values, and 584 because TWAMP is an IETF protocol, this registry must be updated only 585 by "IETF Consensus" as specified in [RFC2434](an RFC documenting 586 registry use that is approved by the IESG). For the Modes registry, 587 we expect that new features will be assigned using monotonically 588 increasing bit positions and in the range [0-31] and the 589 corresponding values, unless there is a good reason to do otherwise. 591 7.3. Experimental Numbers 593 No experimental values are currently assigned for the Modes Registry. 595 7.4. Registry Contents 597 TWAMP Modes Registry is recommended to be augmented as follows: 599 Value Description Semantics Definition 600 0 Reserved 602 1 Unauthenticated RFC4656, Section 3.1 604 2 Authenticated RFC4656, Section 3.1 606 4 Encrypted RFC4656, Section 3.1 608 8 Unauth. TEST protocol, draft-ietf-more-twamp (3) 609 Auth. CONTROL 610 -------------------------------------------------------- 611 xxx Reflect Octets this memo, section 3.1 612 Capability new bit position (X) 613 yyy Truncate Padding this memo, section 3.1 614 Capability new bit position (Y) 615 The suggested values are 617 X=4, xxx=16 618 Y=5, yyy=32 620 8. Acknowledgements 622 The authors would like to thank Walt Steverson for helpful review and 623 comments. 625 9. References 627 9.1. Normative References 629 [I-D.ietf-ippm-more-twamp] 630 Morton, A. and K. Hedayat, "More Features for TWAMP", 631 draft-ietf-ippm-more-twamp-00 (work in progress), 632 October 2008. 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 638 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 639 October 1998. 641 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 642 Zekauskas, "A One-way Active Measurement Protocol 643 (OWAMP)", RFC 4656, September 2006. 645 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 646 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 647 RFC 5357, October 2008. 649 9.2. Informative References 651 [x] "". 653 Authors' Addresses 655 Al Morton 656 AT&T Labs 657 200 Laurel Avenue South 658 Middletown,, NJ 07748 659 USA 661 Phone: +1 732 420 1571 662 Fax: +1 732 368 1192 663 Email: acmorton@att.com 664 URI: http://home.comcast.net/~acmacm/ 666 Len Ciavattone 667 AT&T Labs 668 200 Laurel Avenue South 669 Middletown,, NJ 07748 670 USA 672 Phone: +1 732 420 1239 673 Fax: 674 Email: lencia@att.com 675 URI: 677 Full Copyright Statement 679 Copyright (C) The IETF Trust (2008). 681 This document is subject to the rights, licenses and restrictions 682 contained in BCP 78, and except as set forth therein, the authors 683 retain all their rights. 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 688 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 689 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Intellectual Property 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org.