idnits 2.17.1 draft-ietf-ippm-twamp-value-added-octets-09.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 71 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 -- The document date (September 26, 2012) is 4227 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: March 30, 2013 Ericsson 6 September 26, 2012 8 Ericsson TWAMP Value-Added Octets 9 draft-ietf-ippm-twamp-value-added-octets-09.txt 11 Abstract 13 This memo describes an extension to the TWAMP test protocol for 14 identifying and managing packet trains, which enables measuring 15 capacity metrics like the available path capacity, tight section 16 capacity and UDP delivery rate in the forward and reverse path 17 directions. 19 This memo contains the description of a working prototype. It does 20 not represent a consensus of the IETF community. The IETF community 21 is currently working on the problem statement and has not reached 22 consensus on the preferred method for measuring capacity metrics. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 30, 2013. 41 Copyright and License Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4 59 2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4 60 3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 6 61 4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 7 62 4.1 Additional Considerations . . . . . . . . . . . . . . . . . 7 63 5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 8 66 5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 8 67 5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 13 68 5.2.1 Session-Reflector Packet Format . . . . . . . . . . 15 69 5.3 Additional Considerations . . . . . . . . . . . . . . . . 15 70 6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 7 Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 74 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 10.1 Normative References . . . . . . . . . . . . . . . . . . 17 76 10.2 Informative References . . . . . . . . . . . . . . . . . 17 77 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 79 1 Introduction 81 The notion of embedding a number of meaningful fields in the padding 82 octets has been established as a viable methodology for carrying 83 additional information within the TWAMP-Test protocol running between 84 a Session-Sender and a Session-Reflector [RFC5357] [RFC6038]. 86 This memo describes an optional extension to the Two-Way Active 87 Measurement Protocol [RFC5357]. It is called the Ericsson TWAMP 88 Value-Added Octets feature. This memo defines version 1. 90 This feature enables the controller host to measure capacity metrics 91 like the IP-type-P available path capacity (APC) [RFC5136], IP-layer 92 tight section capacity (TSC) [Y1540] and UDP delivery rate on both 93 forward and reverse paths using a single TWAMP test session. The 94 actual method to calculate the APC, TSC or the UDP delivery rate from 95 packet-level data performance data is not discussed in this memo. 97 The Valued-Added Octets feature consists of new behaviors for the 98 Session-Sender and Session-Reflector, and a set of value-added octets 99 of information that are placed at the beginning of the Packet Padding 100 field [RFC5357] or immediately after the Server Octets in the Packet 101 Padding (to be reflected) field [RFC6038] by the Session-Sender, and 102 are reflected or returned by the Session-Reflector. The length of the 103 value-added octets in version 1 is 10 octets. The Valued-Added Octets 104 feature does not change the basic roles and functions of the TWAMP 105 hosts which are still responsible to include timestamp(s) and 106 sequence number(s) in the test packets. 108 This memo contains the description of a working prototype. It does 109 not represent a consensus of the IETF community. The IETF community 110 is currently working on the problem statement and has not reached 111 consensus on the preferred method for measuring capacity metrics. 113 1.1 Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2 Purpose and scope 121 The purpose of this memo is to describe the Ericsson TWAMP Valued- 122 Added Octets feature (version 1) for TWAMP [RFC5357]. 124 The scope of the memo is limited to specifications of the following 125 enhancements: 127 o The definition of a structure for embedding a sequence of 128 value-added fields at the beginning of the Packet Padding field 129 [RFC5357] or Packet Padding (to be reflected) field [RFC6038] 130 in the TWAMP test packets and, 132 o The definition of new Session-Sender and Session-Reflector 133 behaviors 135 The motivation for this feature is to enable the measurement of 136 capacity metrics on both the forward and reverse paths using a single 137 TWAMP test session. Multiple TWAMP test sessions between a controller 138 and a responder with different DSCPs may also be used to evaluate the 139 QoS impacts on the capacity metrics. 141 The motivation for this document is to capture the prototype 142 presented and demonstrated at the IETF 80. It may be used as a 143 reference for future work or may be used during benchmark analysis to 144 compare the accuracy or performance of the available path capacity 145 estimates under various condition or use cases. 147 This memo does not extend the standard modes of operation through 148 assignment of a new value in the Modes field (see Section 3.1 of 149 [RFC4656] for the format of the Server Greeting message). This memo 150 does not define a vendor specific or experimental mode since the 151 Modes field as currently defined does not explicitly reserve a value 152 or range of values for this purpose. 154 This memo assumes the TWAMP controller is capable to send test 155 packets with value-added padding octets and the TWAMP responder is 156 configured to interpret the value-added padding octets embedded in 157 each TWAMP test packet. Bootstrapping such behavior at the TWAMP 158 responder is implementation-specific. By default, the feature MUST be 159 disabled on the TWAMP host. The Value-Added Octets feature MUST be 160 deployed in an environment where both controller and responder are 161 managed by the same administrative entity and such entity has 162 established an agreement to operate the Value-Added Octets feature 163 between the pair of hosts or between specific UDP endpoints between 164 the pair of hosts. See section 4 and section 5.3 for additional 165 considerations. 167 The Value-Added Octets Version 1 feature is intended to work in 168 conjunction with any TWAMP modes. When the Server and Control-Client 169 are configured or have agreed to use the Value-Added Octets Version 1 170 feature, then the Control-Client, the Server, the Session-Sender, and 171 the Session-Reflector must all conform to the requirements of that 172 feature, as identified below. 174 3 Capacity Measurement Principles 176 Most capacity estimation methods for APC [RRBNC][PDM][ENHJMMB][SBW] 177 and for UDP delivery rate need to send and receive packets in 178 groups,called packet trains or simply trains. Each train is sent at a 179 specific transmission rate in a given direction. These trains must be 180 identified within each bi-directional test session stream. 182 The first measurement principle is to send multiple trains within a 183 test session stream from one IP node to another IP node in order to 184 estimate the APC, TSC or UDP delivery rate in the forward direction. 185 Each train consists of a group of test packets which are separated 186 from each other by a packet interval, as shown in the picture below. 187 The packet interval is measured using either the first bit or the 188 last bit of two consecutive packets. 190 tt tt tt 191 |<---------->| |<---------->| |<---------->| 192 | | | | | | 193 +------------+ +------------+ +------------+ 194 | Packet 1 | | Packet 2 | | Packet 3 | 195 +------------+ +------------+ +------------+ 196 | | | 197 |<--------------------->|<--------------------->| 198 packet interval 1 packet interval 2 200 The test packet size and interval between consecutive packets for 201 each train sent by the Session-Sender and reflected by the Session- 202 Reflector MUST be calculated and determined by the controller or an 203 application or entity communicating with the controller. The packet 204 size and interval MAY vary within a train and/or between trains. 205 Determination of the packet size and interval is implementation- 206 specific. 208 The transmission time tt to send one packet (i.e. determined by the 209 interface speed and the IP packet size) is also shown in the picture. 210 Observe that the packet interval MUST be larger than or equal to tt. 212 At the Session-Reflector, each received test packet within a forward 213 train is time stamped. This provides a second set of packet interval 214 values. Methods for measuring the APC, TSC and UDP delivery rate use 215 the packet intervals obtained from both end points in the estimation 216 process. The method to measuring the UDP delivery rate may also 217 require the rate of packet loss. The estimation process itself as 218 well as any requirements on software or hardware is implementation- 219 specific. 221 The second measurement principle is referred to as self-induced 222 congestion. According to this principle, in order to measure APC, TSC 223 and UDP delivery rates, some trains MUST cause momentary congestion 224 on the network path. In essence this means that some trains MUST be 225 sent at a higher rate than what is available on the network path. 227 In order to fulfill the above measurement principles and to measure 228 the APC, TSC and UDP delivery rates in the reverse direction, the 229 test packets at the Session-Reflector MUST be re-grouped into trains 230 and then transmitted back to the Session-Sender with a provided 231 packet interval. 233 4 TWAMP Control Extensions 235 TWAMP connection establishment follows the procedure defined in 236 Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. The TWAMP- 237 Control protocol [RFC5357] uses the Modes field to identify and 238 select specific communication capabilities. According to the standard 239 specifications, the Value-Added Octets feature requires one new bit 240 position (and value) to identify the ability of the Server/Session- 241 Reflector to read and act upon the new fields in the value-added 242 octets. Such bit position (and value) is not defined in this memo. 243 Bootstrapping the TWAMP Value-Added Octets Version 1 feature is 244 implementation-specific. 246 Both the Reflect Octets mode and Symmetrical Size mode MAY be 247 selected to ensure the reflection of the value-added padding octets 248 by the Session-Reflector and symmetrical size TWAMP-Test packets in 249 the forward and reverse directions of transmission. 251 4.1 Additional Considerations 253 In the TWAMP control architecture, the TWAMP reflector (server) 254 signals the modes it wishes to operate and the TWAMP controller 255 (control-cient) selects the mode or modes supported by the responder. 256 This feature is designed to retain backward compatibility with the 257 original TWAMP control and test protocols. As an alternative, the 258 user may opt for TWAMP light architecture which does not require the 259 TWAMP control protocol. 261 The methods to determine if the Value-Added Octets feature is 262 supported on a TWAMP reflector is implementation-specific. When the 263 Value-Added Octets feature is not supported on a TWAMP reflector, the 264 TWAMP controller MUST NOT select the Value-Added Octets feature and 265 MUST NOT include any value-added octets in the test packets. If the 266 TWAMP controller inadvertently sends value-added octets in the test 267 packets to a TWAMP responder that does not support such feature, the 268 TWAMP responder shall treat the value-added octets as regular padding 269 octets and return the test packets as quickly as possible to the 270 Session-Sender as defined in [RFC5357]. 272 5 Extended TWAMP Test 274 The forward and reverse APC, TSC and UDP delivery rate measurement 275 characteristics depend on the size and packet intervals of the test 276 packets. This memo allows variable packet sizes and packet intervals 277 between trains and even between packets in the same train. The 278 functionality is described below. 280 The TWAMP-test protocol carrying the value-added padding octets is 281 identical to TWAMP [RFC5357] except for the definition of the first 282 10 octets in Packet Padding that the Session-Sender expects to be 283 reflected. The new octets define fields for Value-Added Octets 284 Version, Flags, Last Sequence Number in Train and Desired Reverse 285 Packet Interval. Each of these fields are described in detail below. 287 The Session-Sender and Session-Reflector behaviors are also modified. 289 5.1 Sender Behavior 291 This section describes the extensions to the behavior of the TWAMP 292 Session-Sender. 294 5.1.1 Packet Timings 296 The Send Schedule is not utilized in TWAMP and this is unchanged in 297 this memo. 299 5.1.2 Session-Sender Packet Format 301 The Session-Sender packet format follows the same procedure and 302 guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and 303 Symmetrical Size Features [RFC6038]. 305 This feature allows the Session-Sender to set the first few octets in 306 the TWAMP-Test Packet Padding field with information to communicate 307 value-added padding version number, flag bits, sequence number of the 308 last packet in a train and desired reverse packet interval (or per- 309 packet waiting time) for the reverse path direction of transmission. 311 The Valued-Added Octets feature must be immediately placed after the 312 TWAMP header or immediately after any new field that could be added 313 to the TWAMP header or added to the beginning of the padding octets 314 in the future. Therefore the placement of the first bit from the 315 valued-added octets depends on the mode(s) being selected. 317 A version number and a sequence of flag bits are defined at the very 318 beginning of the value-added padding octets. The version number 319 identifies the version of the value-added padding octets and meaning 320 of the flag bits and corresponding fields. Each flag bit indicates if 321 a specific field is used in the valued-added padding octets. The 322 version number and flag bits provide an effective method for 323 extracting information at Session-Reflector and Session-Sender. This 324 document defines version 1 with two flag bits: L and I. 326 The format of the test packet depends on the TWAMP modes. The Value- 327 Added Octets Version 1 feature is intended to work with any TWAMP 328 modes. 330 The Session-Sender SHALL use the following TWAMP test packet format 331 when the Value-Added Octets version 1 is selected in conjunction with 332 the Unauthenticated mode: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Sequence Number | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Timestamp | 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Error Estimate | Ver |L|I| Reserved | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Last Seqno In Train | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Desired Reverse Packet Interval | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Additional Packet Padding | 349 . . 350 . . 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 The Session-Sender SHALL use the following TWAMP test packet format 354 when the Value-Added Octets Version 1 is selected in conjunction with 355 the Unauthenticated mode, Symmetrical Size mode and Reflect Octets 356 mode: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Sequence Number | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Timestamp | 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Error Estimate | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 368 | | 369 | | 370 | MBZ (27 octets) | 371 | | 372 | | 373 | | 374 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | Ver |L|I| Reserved | Last... | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Seqno in Train | Desired... | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Reverse Packet Interval | Additional... | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Packet Padding | 382 . . 383 . . 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 The Session-Sender SHALL use the following TWAMP test packet format 387 when the Value-Added Octets Version 1 is selected in conjunction with 388 the Unauthenticated mode, Symmetrical Size mode and Reflect Octets 389 mode with a non-zero value in the Server Octets field: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Sequence Number | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Timestamp | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Error Estimate | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 401 | | 402 | | 403 | MBZ (27 octets) | 404 | | 405 | | 406 | | 407 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | Server Octets | Ver |L|I|...| 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Reserved | Last Seqno in... | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Train | Desired Reverse Packet... | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Interval | Additional Packet Padding | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 . . 418 . . 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 In the mode using Reflect Octets illustrated above, the value-added 422 padding octets are embedded in the Packet Padding (to be 423 reflected)field. 425 The Version (Ver) field MUST be encoded in the first 4 bits. It 426 identifies the version number of the value-added padding octets and 427 meaning of the flag bits and the corresponding fields. This memo 428 defines version 1 with two flag bits: L and I. When the Value-Added 429 Octets Version 1 feature is selected, the Session-Sender MUST set the 430 Ver field to 1. 432 The 2 bits after the Version field are used for flags: L and I. 434 The Last Seqno in Train bit (L) is the first flag. When the Value- 435 Added Octets Version 1 feature is selected, the Session-Sender MAY 436 set the Last Seqno in Train bit L to 1. 438 The Desired Reverse Packet Interval bit (I) is the second flag. When 439 the Value-Added Octets Version 1 feature is selected, the Session- 440 Sender MAY set the Desired Reverse Packet Interval bit I to 1. 442 The Reserved field is reserved for future use. All 10 bits of the 443 Reserved field MUST be transmitted as zero by the Session-Sender. 445 If the Last Seqno in Train bit is set to 1, then the Last Seqno in 446 Train field MUST contain an unsigned 32 bit integer generated by the 447 Session-Sender. It MUST indicate the expected sequence number of the 448 last packet in the train. It SHOULD be used by the Session-Sender and 449 Session-reflector to identify the train a test packet belongs to. The 450 packets belonging to a train are determined by observing the test 451 packet sequence number in relation to the Last Seqno for a train. The 452 Last Seqno in Train MUST be higher or equal to the sequence number of 453 the packet. It must also be higher than the Last Seqno in Train for 454 the previous train. If the L bit is set to 0, the Session-Sender 455 shall set all the bits in the Last Seqno in Train field to zero. 457 If the Desired Reverse Packet Interval bit is set to 1, then the 458 Desired Reverse Packet Interval field MUST contain an unsigned 32 bit 459 integer generated by the Session-Sender. It MUST indicate the desired 460 packet interval (or the waiting time) that the Session-Reflector 461 SHOULD use when transmitting the reflected test packets towards the 462 Session-Sender. The value 0 means the The Session-Reflector SHOULD 463 return the test packet to the Session-Sender as quickly as possible. 464 The format of this field MUST be a fractional part of a second as 465 defined in OWAMP [RFC4656]. If the I bit is set to 0, the Session- 466 Sender shall set all the bits in the Desired Reverse Packet Interval 467 field to zero. 469 The values of the above fields are usually provided by a measurement 470 method, tool or algorithm. This measurement algorithm is outside the 471 scope of this specification. 473 5.2 Reflector behavior 475 The TWAMP Session-Reflector follows the procedures and guidelines in 476 Section 4.2 of [RFC5357], with some changes and additional functions. 478 When the Value-Added Octets Version 1 is selected, the behavior of 479 the Session-Reflector SHALL be as follows: 481 o The Session-Reflector MUST read the Version field. If Ver = 1, 482 the Session-Reflector MUST read the L and I flag bits. 484 o If L=1 and I=1, the Session-Reflector MUST read and extract the 485 information from the Last Seqno in Train field and the Desired 486 Reverse Packet Interval field in the value-added padding 487 octets. 489 - The Last Seqno in Train field MUST be compared to Sequence 490 number in the same packet in order to determine when a 491 complete train has been collected. The Session-Reflector 492 SHOULD buffer the packets belonging to the current train (or 493 store the packet-level performance data). After the last 494 packet of the train has been received, the Session-Reflector 495 SHOULD transmit the packets belonging to a reverse train 496 with a waiting time (packet interval) for each packet 497 indicated in the Desired Reverse Packet Interval field. If 498 the Desired Reverse Packet Interval field is set to zero, 499 then the Session-Reflector SHOULD transmit the packet as 500 quickly as possible. The last packet within a train has 501 Sender Sequence Number = Last Seqno in Train. 503 - The Last Seqno in Train of a packet MUST also be compared to 504 the Last Seqno in Train of the previous packet in order to 505 determine if a new train needs to be collected. In case of 506 packet loss, the Session-Reflector MUST transmit the 507 incomplete train when it receives a packet with a Last SeqNo 508 in Train belonging to another train (e.g. next train) of the 509 test session, or after a timeout. The timeout MAY be the 510 REFWAIT timer specified in section 4.2 of [RFC5357]. 512 - Packets arriving out-of-order within a train MUST be 513 buffered at the Session-Reflector if the train is not yet 514 transmitted to the Session-Sender. If the train is already 515 transmitted, the test packet SHOULD be returned to the 516 Session-Sender as quickly as possible. The Session-Reflector 517 MUST NOT reorder the test packets if they happen to arrive 518 out-of-sequence. 520 - Duplicate packets within a train MUST be buffered at the 521 Session-Reflector if the train is not yet transmitted to the 522 Session-Sender. If the train is already transmitted, the 523 duplicate test packet SHOULD be returned to the Session- 524 Sender as quickly as possible. The Session-Reflector MUST 525 NOT discard duplicate test packets. 527 For any other combinations of the Version field and the L and I 528 flags, the Session-Reflector SHOULD return the test packet to the 529 Session-Sender as quickly as possible. 531 The Session-Reflector MUST implement the changes described above when 532 the Value-Added Octets Version 1 feature is selected. 534 5.2.1 Session-Reflector Packet Format 536 The Session-Reflector packet format follows the same procedure and 537 guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and 538 Symmetrical Size Features [RFC6038], with the following changes: 540 o The Session-Reflector MUST re-use (reflect) the value-added 541 padding octets (10 octets) provided in the Sender's Packet 542 Padding. 544 o The Session-Reflector MAY re-use the rest of the padding octets 545 in the Sender's Packet Padding. 547 The truncation process [RFC5357] is recommended when the Symmetrical 548 mode is not used. The Session-Reflector MUST truncate exactly 27 549 octets of padding in Unauthenticated mode,and exactly 56 octets in 550 Authenticated and Encrypted modes. 552 5.3 Additional Considerations 554 The Session-Reflector supporting the Value-Added Octets feature 555 should revert back to the standard Session-Reflector behavior if it 556 cannot interpret the value-added padding octets in a given test 557 packet. Section 5.2 also describes such behavior. For instance, the 558 test packet is returned as quickly as possible to the Session-Sender 559 when the Last Seqno in the Train is not what is expected. 561 Capacity measurements introduce an additional consideration when the 562 test sessions operate in TWAMP Light. When the Session-Reflector does 563 not have knowledge of the session state, the measurement system may 564 be restricted to estimating or calculating the capacity metrics in 565 the forward path direction of transmission only. Capacity 566 measurements in the reverse path direction is best handled with a 567 Session-Reflector supporting knowledge of the session state and being 568 capable of identifying the test packets belonging to a specific test 569 session. A method for creating a session state from the initial test 570 packet may be implemented on the TWAMP Light Session-Reflector. This 571 is outside the scope of this specification. 573 6 Experiments 575 This memo describes the protocol used in the current working 576 prototype implementation of the Value-Added Octets feature in the 577 Ericsson lab. The prototype has been tested in real network 578 environments. The conclusion from these tests is that the Value-Added 579 Octets feature is able to enable estimation of capacity metrics such 580 as available path capacity in both the forward and reverse directions 581 of the network path. 583 During the experiments with the protocol described in this memo we 584 have identified a need for the controller and responder to use the 585 same maximum train length. The reflector must be able to buffer the 586 whole train received from the controller. In order to reduce the risk 587 for buffer overrun the maximum train length should be negotiated. 588 This can be resolved through configuration, introduction of a new 589 field in the value-added octets or with a new maximum train length 590 field in the Request-TW-Session message. 592 The Sender Discriminator (SD) field that is defined in the first 593 draft has been removed because of complications with different 594 Session-Reflector implementations. A Session-Reflector may not be 595 able to easily identify the SD field or associate it with a specific 596 Session-Sender which may skew the test results. 598 The flags defined in the value-added octets now indicate the usage of 599 fields and not the presence of fields. This modification was needed 600 to simplify the responder implementation in the working prototype. 602 7 Security Considerations 604 The value-added padding octets permit DoS attacks on the responder 605 host communicating with core TWAMP [RFC5357]. For instance, a DOS 606 condition could arise when the Last Seqno in Train is too large to 607 handle potentially causing undesirable processing delay or discard of 608 the TWAMP test packets. The responder host MUST provide a mechanism 609 to protect or limit the use of its local memory, buffer space or 610 maximum transmission time for a train. 612 The security considerations that apply to any active measurement of 613 live networks are relevant here as well. See [RFC4656] and [RFC5357]. 615 8 IANA Considerations 617 This document has no actions for IANA. 619 9 Acknowledgements 621 The authors thank Svante Ekelin for providing direction and comments 622 on this document. 624 10 References 626 10.1 Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 632 Zekauskas, "A One-way Active Measurement 633 Protocol(OWAMP)", RFC 4656, September 2006. 635 [RFC5136] Chimento, P. and Ishac,J., "Defining Network Capacity", 636 RFC 5136, February 2008. 638 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 639 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 640 RFC 5357, October 2008. 642 [RFC6038] Morton, A., Ciavattone, L., TWAMP Reflect Octets and 643 Symmetrical Size Features, RFC6038 , October 2010. 645 10.2 Informative References 647 [RRBNC] Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J., 648 Cottrel, L., Pathchirp: Efficient available bandwidth 649 estimation for network paths, Passive and Active 650 Measurement Workshop, 2003. 652 [PDM] Dovrolis, C., Ramanathan, P., and Moore D., Packet 653 Dispersion Techniques and a Capacity Estimation 654 Methodology, IEEE/ACM Transactions on Networking, 655 December 2004. 657 [ENHJMMB] Ekelin, S., Nilsson, M., Hartikainen, E., Johnsson, A., 658 Mangs, J., Melander, B., Bjorkman, M., Real-time 659 measurement of end-to-end available bandwidth using 660 kalman filtering, Proceedings to the IEEE IFIP Network 661 Operations and Management Symposium, 2006. 663 [SBW] Sommers, J., Barford, P., Willinger, W., Laboratory-based 664 calibration of available bandwidth estimation tools, 665 Microprocess Microsyst., 2007. 667 [Y1540] ITU-T Y.1540, Internet protocol data communication service 668 - IP packet transfer and availability performance 669 parameters, 2011. 671 Author's Addresses 673 Steve Baillargeon 674 Ericsson 675 3500 Carling Avenue 676 Ottawa, Ontario K2H 8E9 677 Canada 678 EMail: steve.baillargeon@ericsson.com 680 Christofer Flinta 681 Ericsson 682 Farogatan 6 683 Stockholm, 164 80 684 Sweden 685 EMail: christofer.flinta@ericsson.com 687 Andreas Johnsson 688 Ericsson 689 Farogatan 6 690 Stockholm, 164 80 691 Sweden 692 EMail: andreas.a.johnsson@ericsson.com