idnits 2.17.1 draft-baillargeon-ippm-twamp-value-added-octets-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 : ---------------------------------------------------------------------------- ** There are 77 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - Packets arriving out-of-order within a train MUST be buffered at the Session-Reflector if the train is not yet transmitted to the Session-Sender. If the train is already transmitted, the test packet SHOULD be returned to the Session-Sender as quickly as possible. The Session-Reflector MUST not reorder the test packets if they happen to arrive out-of-sequence. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - Duplicate packets within a train MUST be buffered at the Session-Reflector if the train is not yet transmitted to the Session-Sender. If the train is already transmitted, the duplicate test packet SHOULD be returned to the Session-Sender as quickly as possible. The Session-Reflector MUST not discard duplicate test packets. -- The document date (January 24, 2012) is 4476 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1242' is mentioned on line 96, but not defined == Missing Reference: 'RFC5037' is mentioned on line 126, but not defined == Missing Reference: 'RFC5618' is mentioned on line 556, but not defined == Unused Reference: 'MRM' is defined on line 617, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-reporting-metrics-03 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Baillargeon 3 INTERNET-DRAFT C. Flinta 4 Intended Status: Informational A. Johnsson 5 Expires: July 24, 2012 S. Ekelin 6 Ericsson 7 January 24, 2012 9 TWAMP Value-Added Octets 10 draft-baillargeon-ippm-twamp-value-added-octets-03.txt 12 Status of This Memo 14 This memo provides information for the Internet community. It does 15 not specify an Internet standard of any kind. Distribution of this 16 memo is unlimited. 18 Abstract 20 This memo describes optional extensions to the TWAMP test protocol 21 for identifying and managing packet trains, which enables measuring 22 capacity metrics like the available path capacity, tight section 23 capacity and UDP delivery rate in the forward and reverse path 24 directions. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2011 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 Requirements Language . . . . . . . . . . . . . . . . . . . 4 66 2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4 67 3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 5 68 4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 6 69 5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 7 70 5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 7 72 5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 7 73 5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 12 74 5.2.1 Session-Reflector Packet Format . . . . . . . . . . 13 75 5.3 Additional Considerations . . . . . . . . . . . . . . . . 14 76 6 Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1 Normative References . . . . . . . . . . . . . . . . . . 15 80 8.2 Informative References . . . . . . . . . . . . . . . . . 15 81 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1 Introduction 85 The notion of embedding a number of meaningful fields in the padding 86 octets has been established as a viable methodology for carrying 87 additional information within the TWAMP-Test protocol running between 88 a Session-Sender and a Session-Reflector [RFC5357] [RFC6038]. 90 This memo describes an extension to the Two-Way Active Measurement 91 Protocol [RFC5357]. It is called the Value-Added Octets feature. 93 This feature enables the controller host to measure capacity metrics 94 like the IP-type-P available path capacity (APC) [RFC5136], IP-layer 95 tight section capacity (TSC) [Y1540] and UDP delivery rate (e.g. as 96 defined in [RFC1242]) on both forward and reverse paths using a 97 single TWAMP test session with symmetrical or asymmetrical test 98 packet sizes. The actual method to calculate the APC, TSC or the UDP 99 delivery rate from packet-level data performance data is not 100 discussed in this memo. 102 The Valued-Added Octets feature consists of new behaviors for the 103 Session-Sender and Session-Reflector, and a set of value-added octets 104 of information that are placed at the beginning of the Packet Padding 105 field [RFC5357] or at the beginning of the Packet Padding (to be 106 reflected) field [RFC6038] by the Session-Sender, and are reflected 107 or returned by the Session-Reflector. The length of the value-added 108 octets (version 1) is 14 octets. 110 1.1 Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2 Purpose and scope 118 The purpose of this memo is to describe the Valued-Added Octets 119 feature for TWAMP [RFC5357]. 121 The scope of the memo is limited to specifications of the following 122 enhancements: 124 o The definition of a structure for embedding a sequence of 125 value-added fields at the beginning of the Packet Padding field 126 [RFC5037] or Packet Padding (to be reflected) field [RFC6038] 127 in the TWAMP test packets and, 129 o The definition of new Session-Sender and Session-Reflector 130 behaviors 132 The motivation for this feature is to enable the measurements of 133 capacity metrics on both the forward and reverse paths with 134 symmetrical or asymmetrical test packet sizes. 136 This memo does not extend the modes of operation through assignment 137 of a new value in the Modes field (see Section 3.1 of [RFC4656] for 138 the format of the Server Greeting message). However a new mode is 139 required to communicate feature capability and use in an 140 interoperable manner. For instance, when the Server and Control- 141 Client have agreed to use the Value-Added Octets Version 1 mode 142 during control connection setup, then the Control-Client, the Server, 143 the Session-Sender, and the Session-Reflector must all conform to the 144 requirements of that mode, as identified below. 146 The packet padding octets are designed to retain backward 147 compatibility with the original TWAMP test protocol [RFC5357]. 149 3 Capacity Measurement Principles 151 Most capacity estimation methods for APC [RRBNC][PDM][ENHJMMB][SBW] 152 and for UDP delivery rate need to send and receive packets in groups, 153 called packet trains or simply trains. Each train is sent at a 154 specific transmission rate in a given direction. These trains must be 155 identified within each bi-directional test session stream. 157 The first measurement principle is to send multiple trains within a 158 test session stream from one IP node to another IP node in order to 159 estimate the APC, TSC or UDP delivery rate in the forward direction. 160 Each train consists of a group of test packets which are separated 161 from each other by a packet interval, as shown in the picture below. 162 The packet interval is measured using either the first bit or the 163 last bit of two consecutive packets. 165 tt tt tt 166 |<---------->| |<---------->| |<---------->| 167 | | | | | | 168 +------------+ +------------+ +------------+ 169 | Packet 1 | | Packet 2 | | Packet 3 | 170 +------------+ +------------+ +------------+ 171 | | | 172 |<--------------------->|<--------------------->| 173 packet interval 1 packet interval 2 175 The test packet size and interval between consecutive packets for 176 each train sent by the Session-Sender and reflected by the Session- 177 Reflector MUST be calculated and determined by the controller or an 178 application or entity communicating with the controller. The packet 179 size and interval MAY vary within a train, between trains and MAY 180 also be different depending on forward or reverse transmission 181 direction. Determination of the packet size and interval is 182 implementation-specific. 184 The transmission time tt to send one packet (i.e. determined by the 185 interface speed and the IP packet size) is also shown in the picture. 186 Observe that the packet interval MUST be larger than or equal to tt. 188 At the Session-Reflector, each received test packet within a forward 189 train is time stamped. This provides a second set of packet interval 190 values. Methods for measuring the APC, TSC and UDP delivery rate use 191 the packet intervals obtained from both end points in the estimation 192 process. The method to measuring the UDP delivery rate may also 193 require the packet loss at the receiving end. The estimation process 194 itself as well as any requirements on software or hardware is 195 implementation-specific. 197 The second measurement principle is referred to as self-induced 198 congestion. According to this principle, in order to measure APC, TSC 199 and UDP delivery rate, some trains MUST cause momentary congestion on 200 the network path. In essence this means that some trains MUST be sent 201 at a higher rate than what is available on the network path. 203 In order to fulfill the above measurement principles and to measure 204 the APC, TSC and UDP delivery rate in the reverse direction, the test 205 packets at the Session-Reflector MUST be re-grouped into trains and 206 then transmitted back to the Session-Sender with a provided packet 207 interval. 209 4 TWAMP Control Extensions 211 TWAMP-Control protocol [RFC5357] uses the Modes field to identify and 212 select specific communication capabilities, and this field is a 213 recognized extension mechanism. 215 TWAMP connection establishment follows the procedure defined in 216 Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. For 217 interoperability, the Value-added octet feature require one new bit 218 position (and value) to identify the ability of the Server/Session- 219 Reflector to read and act upon the new fields in the value-added 220 octets. Such bit position (and value) is not defined in this memo. 222 Both the Reflect Octets mode and Symmetrical Size mode MAY be 223 selected to ensure the reflection of the value-added padding octets 224 by the Session-Reflector and symmetrical size TWAMP-Test packets in 225 the forward and reverse directions of transmission. 227 5 Extended TWAMP Test 229 The forward and reverse APC, TSC and UDP delivery rate measurement 230 characteristics depend on the size and packet intervals of the test 231 packets. This memo allows variable packet sizes and packet intervals 232 between trains in different transmission directions, trains in the 233 same transmission direction and even between packets in the same 234 train. The functionality is described below. 236 The TWAMP-test protocol carrying the value-added padding octets is 237 identical to TWAMP [RFC5357] except for the definition of first 14 238 octets in Packet Padding that the Session-Sender expects to be 239 reflected. The new octets define fields for Value-Added Octets 240 Version, Flags, Last Sequence Number in Train, Desired Reverse Packet 241 Interval and Desired Reverse Padding Length. Each of these fields are 242 described in detail below. 244 The Session-Sender and Session-Reflector behaviors are also modified. 246 5.1 Sender Behavior 248 This section describes the extensions to the behavior of the TWAMP 249 Session-Sender. 251 5.1.1 Packet Timings 253 The Send Schedule is not utilized in TWAMP and this is unchanged in 254 this memo. 256 5.1.2 Session-Sender Packet Format 258 The Session-Sender packet format follows the same procedure and 259 guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and 260 Symmetrical Size Features [RFC6038]. 262 This feature allows the Session-Sender to set the first few octets in 263 the TWAMP-Test Packet Padding field with information to communicate 264 value-added padding version number, flag bits, sequence number of the 265 last packet in a train, desired reverse packet interval (or per- 266 packet waiting time) and desired reverse padding length for the 267 reverse path direction of transmission. 269 A version number and a sequence of flag bits are defined at the very 270 beginning of the value-added padding octets. The version number 271 identifies the version of the value-added padding octets and meaning 272 of the flag bits and corresponding fields. Each flag bit indicates if 273 a specific field is used in the valued-added padding octets. The 274 version number and flag bits provide an effective method for 275 extracting information at Session-Reflector and Session-Sender. This 276 document defines version 1 with three flag bits: L, I and P. 278 The format of the test packet depends on the TWAMP mode and flag bits 279 being used. The Value-Added Octets Version 1 mode is intended to work 280 with any TWAMP modes. 282 The Session-Sender SHALL use the following TWAMP test packet format 283 when the Value-Added Octets Version 1 is selected in conjunction with 284 the unauthenticated mode: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Sequence Number | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Timestamp | 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Error Estimate | Ver |L|I|P| Reserved | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Last Seqno In Train | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Desired Reverse Packet Interval | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Desired Reverse Padding Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 302 | Additional Packet Padding | 303 . . 304 . . 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 The Session-Sender SHALL use the following TWAMP test packet format 308 when the Value-Added Octets Version 1 is selected in conjunction with 309 the unauthenticated mode, Symmetrical Size mode and Reflect Octets 310 mode: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Sequence Number | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Timestamp | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Error Estimate | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 322 | | 323 | | 324 | MBZ (27 octets) | 325 | | 326 | | 327 | | 328 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | Ver |L|I|P| Reserved | Last... | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Seqno in Train | Desired... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Reverse Packet Interval | Desired... | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Reverse Padding Length | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 337 | Additional Packet Padding | 338 . . 339 . . 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 The Session-Sender SHALL use the following TWAMP test packet format 343 when the Value-Added Octets Version 1 is selected in conjunction with 344 the unauthenticated mode, Symmetrical Size mode and Reflect Octets 345 mode with a non-zero value in the Server octets field: 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 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 357 | | 358 | | 359 | MBZ (27 octets) | 360 | | 361 | | 362 | | 363 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | Server octets | Ver |L|I|P| | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Reserved | Last Seqno in Train | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | Desired Reverse Packet Interval | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | Desired Reverse Padding Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | Additional Packet Padding | 373 +-+-+-+-+-+-+-+-+ | 374 | | 375 . . 376 . . 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 In the mode using Reflect Octets illustrated above, the value-added 380 padding octets are embedded in the Packet Padding (to be reflected) 381 field. 383 The Version (Ver) field MUST be encoded in the first 4 bits. It 384 identifies the version number of the value-added padding octets and 385 meaning of the flag bits and the corresponding fields. This memo 386 defines version 1. When the Value-Added Octets Version 1 mode is 387 selected, the Session-Sender MUST set the Ver field to 1. 389 The 3 bits after the Version field are used for flags: L, I and P. 391 The Last Seqno in Train bit (L) is the first flag. When the Value- 392 Added Octets Version 1 mode is selected, the Session-Sender MAY set 393 the Last Seqno in Train bit L to 1. 395 The Desired Reverse Packet Interval bit (I) is the second flag. When 396 the Value-Added Octets Version 1 mode is selected, the Session-Sender 397 MAY set the Desired Reverse Packet Interval bit I to 1. 399 The Desired Reverse Padding Length bit (P) is the third flag. When 400 the Value-Added Octets Version 1 mode is selected, the Session-Sender 401 MAY set the Desired Reverse Padding Length bit P to 1. 403 The Reserved field is reserved for future use. All 9 bits of the 404 Reserved field MUST be transmitted as zero by the Session-Sender. 406 If the Last Seqno in Train bit is set to 1, then the Last Seqno in 407 Train field MUST contain an unsigned 32 bit integer generated by the 408 Session-Sender. It MUST indicate the expected sequence number of the 409 last packet in the train. It SHOULD be used by the Session-Sender and 410 Session-reflector to identify the train a test packet belongs to. The 411 packets belonging to a train are determined by observing the test 412 packet sequence number in relation to the Last Seqno for a train. The 413 Last Seqno in Train MUST be higher or equal to the sequence number of 414 the packet. It must also be higher than the Last Seqno in Train for 415 the previous train. If the L bit is set to 0, the Session-Sender 416 shall set all the bits in the Last Seqno in Train field to zero. 418 If the Desired Reverse Packet Interval bit is set to 1, then the 419 Desired Reverse Packet Interval field MUST contain an unsigned 32 bit 420 integer generated by the Session-Sender. It MUST indicate the desired 421 packet interval (or the waiting time) that the Session-Reflector 422 SHOULD use when transmitting the reflected test packets towards the 423 Session-Sender. The value 0 means the The Session-Reflector SHOULD 424 return the test packet to the Session-Sender as quickly as possible. 425 The format of this field MUST be a fractional part of a second as 426 defined in OWAMP [RFC4656]. If I bit is set to 0, the Session-Sender 427 shall set all the bits in the Desired Reverse Packet Interval field 428 to zero. 430 If the Desired Reverse Padding Length bit is set to 1, then the 431 Desired Reverse Padding Length field MUST contain an unsigned 32 bit 432 integer generated by the Session-Sender. It MUST specify the number 433 of padding octets that the Session-Reflector will append to the 434 TWAMP-Test packet to be reflected. The Desired Reverse Padding Length 435 includes the Value-added octets. If P bit is set to 0, the Session- 436 Sender shall set all the bits in the Desired Reverse Padding Length 437 field to zero. 439 The values of the above fields are usually provided by a measurement 440 method, tool or algorithm. This measurement algorithm is outside the 441 scope of this specification. 443 5.2 Reflector behavior 445 The TWAMP Session-Reflector follows the procedures and guidelines in 446 Section 4.2 of [RFC5357], with some changes and additional functions. 448 When the Value-Added Octets Version 1 is selected, the behavior of 449 the Session-Reflector SHALL be as follows: 451 o The Session-Reflector MUST read the Version field. If Ver = 1, 452 the Session-Reflector MUST read the L, I and P flag bits. 454 o If L=1 and I=1, the Session-Reflector MUST read and extract the 455 information from the Last Seqno in Train field and the Desired 456 Reverse Packet Interval field in the value-added padding 457 octets. 459 - The Last Seqno in Train field MUST be compared to Sequence 460 number in the same packet in order to determine when a 461 complete train has been collected. The Session-Reflector 462 SHOULD buffer the packets belonging to the current train (or 463 store the packet-level performance data). After the last 464 packet of the train has been received, the Session-Reflector 465 SHOULD transmit the packets belonging to a reverse train 466 with a waiting time (packet interval) for each packet 467 indicated in the Desired Reverse Packet Interval field. If 468 the Desired Reverse Packet Interval field is set to zero, 469 then the Session-Reflector SHOULD transmit the packets as 470 quickly as possible. The last packet within a train has 471 Sender Sequence Number = Last Seqno in Train. 473 - The Last Seqno in Train of a packet MUST also be compared to 474 the Last Seqno in Train of the previous packet in order to 475 determine if a new train needs to be collected. In case of 476 packet loss, the Session-Reflector MUST transmit the 477 incomplete train when it receives a packet with a Last SeqNo 478 in Train belonging to the another train (e.g. next train) of 479 the test session, or after a timeout. The timeout MAY be the 480 REFWAIT timer specified in section 4.2 of [RFC5357]. 482 - Packets arriving out-of-order within a train MUST be 483 buffered at the Session-Reflector if the train is not yet 484 transmitted to the Session-Sender. If the train is already 485 transmitted, the test packet SHOULD be returned to the 486 Session-Sender as quickly as possible. The Session-Reflector 487 MUST not reorder the test packets if they happen to arrive 488 out-of-sequence. 490 - Duplicate packets within a train MUST be buffered at the 491 Session-Reflector if the train is not yet transmitted to the 492 Session-Sender. If the train is already transmitted, the 493 duplicate test packet SHOULD be returned to the Session- 494 Sender as quickly as possible. The Session-Reflector MUST 495 not discard duplicate test packets. 497 o If P=1, the Session-Reflector MUST read and extract the 498 information from the Desired Reverse Padding Length field in 499 the value-added padding octets. 501 - The Session-Reflector SHOULD transmit the packet with the 502 Desired Reverse Padding Length. If Symmetrical-Size mode is 503 used the Desired Reverse Padding Length must be ignored by 504 the Session-Reflector. The actual reflected packet size MUST 505 be large enough to contain all data required to be reflected 506 according to selected modes. If the Desired Reverse Padding 507 Length is larger than the Session-Reflector MTU, the MTU 508 MUST be used. 510 The Session-Reflector MUST implement the changes described above when 511 the Value-Added Octets Version 1 mode is selected. 513 5.2.1 Session-Reflector Packet Format 515 The Session-Reflector packet format follows the same procedure and 516 guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and 517 Symmetrical Size Features [RFC6038], with the following changes: 519 o The Session-Reflector MUST re-use (reflect) the value-added 520 padding octets (14 octets) provided in the Sender's Packet 521 Padding. 523 o The Session-Reflector MAY re-use the rest of the padding octets 524 in the Sender's Packet Padding. 526 The truncation process [RFC5357] is recommended when the Desired 527 Reverse Padding Length (P) bit is 0 and the Symmetrical mode is not 528 used. The Session-Reflector MUST truncate exactly 27 octets of 529 padding in Unauthenticated mode,and exactly 56 octets in 530 Authenticated and Encrypted modes. 532 5.3 Additional Considerations 534 Capacity measurements introduce an additional consideration when the 535 test sessions operate in TWAMP Light. When the Session-Reflector does 536 not have knowledge of the session state, the measurement system will 537 only be capable to estimate or calculate the capacity metrics in the 538 forward path direction of transmission. Capacity measurements in the 539 reverse path direction requires the Session-Reflector to have 540 knowledge of the session state and be capable to identify the test 541 packets belonging to a specific test session. The method for creating 542 a session state from the initial test packets on the TWAMP Light 543 Session-Reflector is outside the scope of this specification. 545 6 Security Considerations 547 The value-added padding octets permit DoS attacks on the responder 548 host communicating with core TWAMP [RFC5357]. The responder host MUST 549 provide a mechanism to protect or limit the use of its local memory, 550 buffer space or maximum transmission time for a train. 552 The security considerations that apply to any active measurement of 553 live networks are relevant here as well. See [RFC4656] and [RFC5357]. 555 7 IANA Considerations 556 IANA has created a TWAMP-Modes registry (as requested in [RFC5618]). 557 TWAMP-Modes are specified in TWAMP Server Greeting messages and Setup 558 Response messages, as described in Section 3.1 of [RFC5357], 559 consistent with Section 3.1 of [RFC4656]. Modes are indicated by 560 setting bits in the 32-bit Modes field that correspond to values in 561 the Modes registry. For the TWAMP-Modes registry, new features are 562 usually assigned increasing registry values that correspond to single 563 bit positions. 565 This memo does not define a new TWAMP mode. Therefore it is not a 566 recognized extension mechanism for TWAMP. A new mode is required to 567 communicate feature capability and use in an interoperable manner. 568 This is outside the scope of this memo. 570 8 References 572 8.1 Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 578 Zekauskas, "A One-way Active Measurement 579 Protocol(OWAMP)", RFC 4656, September 2006. 581 [RFC5136] Chimento, P. and Ishac,J., "Defining Network Capacity", 582 RFC 5136, February 2008. 584 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 585 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 586 RFC 5357, October 2008. 588 [RFC6038] Morton, A., Ciavattone, L., TWAMP Reflect Octets and 589 Symmetrical Size Features, RFC6038 , October 2010. 591 8.2 Informative References 593 [RRBNC] Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J., 594 Cottrel, L., Pathchirp: Efficient available bandwidth 595 estimation for network paths, Passive and Active 596 Measurement Workshop, 2003. 598 [PDM] Dovrolis, C., Ramanathan, P., and Moore D., Packet 599 Dispersion Techniques and a Capacity Estimation 600 Methodology, IEEE/ACM Transactions on Networking, 601 December 2004. 603 [ENHJMMB] Ekelin, S., Nilsson, M., Hartikainen, E., Johnsson, A., 604 Mangs, J., Melander, B., Bjorkman, M., Real-time 605 measurement of end-to-end available bandwidth using 606 kalman filtering, Proceedings to the IEEE IFIP Network 607 Operations and Management Symposium, 2006. 609 [SBW] Sommers, J., Barford, P., Willinger, W., Laboratory-based 610 calibration of available bandwidth estimation tools, 611 Microprocess Microsyst., 2007. 613 [Y1540] ITU-T Y.1540, Internet protocol data communication service 614 - IP packet transfer and availability performance 615 parameters, 2011. 617 [MRM] Morton, A., Ramachandran, G., Maguluri, G., Reporting 618 Metrics Different Points of View, draft-ietf-ippm- 619 reporting-metrics-03, June 2010. 621 Author's Addresses 623 Steve Baillargeon 624 Ericsson 625 3500 Carling Avenue 626 Ottawa, Ontario K2H 8E9 627 Canada 628 EMail: steve.baillargeon@ericsson.com 630 Christofer Flinta 631 Ericsson 632 Farogatan 6 633 Stockholm, 164 80 634 Sweden 635 EMail: christofer.flinta@ericsson.com 637 Andreas Johnsson 638 Ericsson 639 Farogatan 6 640 Stockholm, 164 80 641 Sweden 642 EMail: andreas.a.johnsson@ericsson.com 644 Svante Ekelin 645 Ericsson 646 Farogatan 6 647 Stockholm, 164 80 648 Sweden 649 EMail: svante.ekelin@ericsson.com