idnits 2.17.1 draft-ietf-ippm-twamp-value-added-octets-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 == 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 (April 4, 2012) is 4399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5037' is mentioned on line 125, but not defined == Unused Reference: 'MRM' is defined on line 614, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ippm-reporting-metrics-03 Summary: 2 errors (**), 0 flaws (~~), 6 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: October 6, 2012 S. Ekelin 6 Ericsson 7 April 4, 2012 9 Ericsson TWAMP Value-Added Octets 10 draft-ietf-ippm-twamp-value-added-octets-02.txt 12 Abstract 14 This memo describes an extension to the TWAMP test protocol for 15 identifying and managing packet trains, which enables measuring 16 capacity metrics like the available path capacity, tight section 17 capacity and UDP delivery rate in the forward and reverse path 18 directions. 20 This memo contains the description of a working prototype. It does 21 not represent a consensus of the IETF community. The IETF community 22 is currently working on the problem statement and has not reached 23 consensus on the preferred method for measuring capacity metrics. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 6, 2012. 42 Copyright and License Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4 61 2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . 4 62 3 Capacity Measurement Principles . . . . . . . . . . . . . . . . 5 63 4 TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 7 64 5 Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1 Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1.1 Packet Timings . . . . . . . . . . . . . . . . . . . . 8 67 5.1.2 Session-Sender Packet Format . . . . . . . . . . . . . 8 68 5.2 Reflector behavior . . . . . . . . . . . . . . . . . . . 12 69 5.2.1 Session-Reflector Packet Format . . . . . . . . . . 14 70 5.3 Additional Considerations . . . . . . . . . . . . . . . . 14 71 6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7 Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8.1 Normative References . . . . . . . . . . . . . . . . . . 15 75 8.2 Informative References . . . . . . . . . . . . . . . . . 16 76 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1 Introduction 80 The notion of embedding a number of meaningful fields in the padding 81 octets has been established as a viable methodology for carrying 82 additional information within the TWAMP-Test protocol running between 83 a Session-Sender and a Session-Reflector [RFC5357] [RFC6038]. 85 This memo describes an optional extension to the Two-Way Active 86 Measurement Protocol [RFC5357]. It is called the Ericsson TWAMP 87 Value-Added Octets feature. This memo defines version 1. 89 This feature enables the controller host to measure capacity metrics 90 like the IP-type-P available path capacity (APC) [RFC5136], IP-layer 91 tight section capacity (TSC) [Y1540] and UDP delivery rate on both 92 forward and reverse paths using a single TWAMP test session. The 93 actual method to calculate the APC, TSC or the UDP delivery rate from 94 packet-level data performance data is not discussed in this memo. 96 The Valued-Added Octets feature consists of new behaviors for the 97 Session-Sender and Session-Reflector, and a set of value-added octets 98 of information that are placed at the beginning of the Packet Padding 99 field [RFC5357] or at the beginning of the Packet Padding (to be 100 reflected) field [RFC6038] by the Session-Sender, and are reflected 101 or returned by the Session-Reflector. The length of the value-added 102 octets in version 1 is 10 octets. 104 This memo contains the description of a working prototype. It does 105 not represent a consensus of the IETF community. The IETF community 106 is currently working on the problem statement and has not reached 107 consensus on the preferred method for measuring capacity metrics. 109 1.1 Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2 Purpose and scope 117 The purpose of this memo is to describe the Ericsson Valued-Added 118 Octets feature (version 1) for TWAMP [RFC5357]. 120 The scope of the memo is limited to specifications of the following 121 enhancements: 123 o The definition of a structure for embedding a sequence of 124 value-added fields at the beginning of the Packet Padding field 125 [RFC5037] or Packet Padding (to be reflected) field [RFC6038] 126 in the TWAMP test packets and, 128 o The definition of new Session-Sender and Session-Reflector 129 behaviors 131 The motivation for this feature is to enable the measurements of 132 capacity metrics on both the forward and reverse paths using a single 133 TWAMP test session. Multiple TWAMP test sessions between a controller 134 and a responder with different DSCPs may also be used to evaluate the 135 QoS impacts on the capacity metrics. 137 This memo does not extend the standard modes of operation through 138 assignment of a new value in the Modes field (see Section 3.1 of 139 [RFC4656] for the format of the Server Greeting message). A new mode 140 is recommended to communicate feature capability during control 141 connection setup. 143 This memo assumes the TWAMP responder is configured through non- 144 standard means to interpret the value-added padding octets embedded 145 in each TWAMP test packet. Bootstrapping such behavior MAY be 146 achieved using one of the following methods: 148 o Configuration provided through the management interface 150 o Assignment of a proprietary TWAMP mode communicated during 151 TWAMP control connection setup 153 The Value-Added Octets Version 1 mode is intended to work with any 154 TWAMP modes. When the Server and Control-Client are configured or 155 have agreed to use the Value-Added Octets Version 1 mode during 156 control connection setup, then the Control-Client, the Server, the 157 Session-Sender, and the Session-Reflector must all conform to the 158 requirements of that mode, as identified below. 160 The packet padding octets are designed to retain backward 161 compatibility with the original TWAMP test protocol [RFC5357]. 163 3 Capacity Measurement Principles 165 Most capacity estimation methods for APC [RRBNC][PDM][ENHJMMB][SBW] 166 and for UDP delivery rate need to send and receive packets in groups, 167 called packet trains or simply trains. Each train is sent at a 168 specific transmission rate in a given direction. These trains must be 169 identified within each bi-directional test session stream. 171 The first measurement principle is to send multiple trains within a 172 test session stream from one IP node to another IP node in order to 173 estimate the APC, TSC or UDP delivery rate in the forward direction. 174 Each train consists of a group of test packets which are separated 175 from each other by a packet interval, as shown in the picture below. 176 The packet interval is measured using either the first bit or the 177 last bit of two consecutive packets. 179 tt tt tt 180 |<---------->| |<---------->| |<---------->| 181 | | | | | | 182 +------------+ +------------+ +------------+ 183 | Packet 1 | | Packet 2 | | Packet 3 | 184 +------------+ +------------+ +------------+ 185 | | | 186 |<--------------------->|<--------------------->| 187 packet interval 1 packet interval 2 189 The test packet size and interval between consecutive packets for 190 each train sent by the Session-Sender and reflected by the Session- 191 Reflector MUST be calculated and determined by the controller or an 192 application or entity communicating with the controller. The packet 193 size and interval MAY vary within a train and/or between trains. 194 Determination of the packet size and interval is implementation- 195 specific. 197 The transmission time tt to send one packet (i.e. determined by the 198 interface speed and the IP packet size) is also shown in the picture. 199 Observe that the packet interval MUST be larger than or equal to tt. 201 At the Session-Reflector, each received test packet within a forward 202 train is time stamped. This provides a second set of packet interval 203 values. Methods for measuring the APC, TSC and UDP delivery rate use 204 the packet intervals obtained from both end points in the estimation 205 process. The method to measuring the UDP delivery rate may also 206 require the packet loss. The estimation process itself as well as any 207 requirements on software or hardware is implementation-specific. 209 The second measurement principle is referred to as self-induced 210 congestion. According to this principle, in order to measure APC, TSC 211 and UDP delivery rate, some trains MUST cause momentary congestion on 212 the network path. In essence this means that some trains MUST be sent 213 at a higher rate than what is available on the network path. 215 In order to fulfill the above measurement principles and to measure 216 the APC, TSC and UDP delivery rate in the reverse direction, the test 217 packets at the Session-Reflector MUST be re-grouped into trains and 218 then transmitted back to the Session-Sender with a provided packet 219 interval. 221 4 TWAMP Control Extensions 223 TWAMP-Control protocol [RFC5357] uses the Modes field to identify and 224 select specific communication capabilities, and this field is a 225 recognized extension mechanism. 227 TWAMP connection establishment follows the procedure defined in 228 Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. For 229 interoperability, the Value-added octet feature require one new bit 230 position (and value) to identify the ability of the Server/Session- 231 Reflector to read and act upon the new fields in the value-added 232 octets. Such bit position (and value) is not defined in this memo. A 233 proprietary value MAY be used. 235 Both the Reflect Octets mode and Symmetrical Size mode MAY be 236 selected to ensure the reflection of the value-added padding octets 237 by the Session-Reflector and symmetrical size TWAMP-Test packets in 238 the forward and reverse directions of transmission. 240 5 Extended TWAMP Test 242 The forward and reverse APC, TSC and UDP delivery rate measurement 243 characteristics depend on the size and packet intervals of the test 244 packets. This memo allows variable packet sizes and packet intervals 245 between trains and even between packets in the same train. The 246 functionality is described below. 248 The TWAMP-test protocol carrying the value-added padding octets is 249 identical to TWAMP [RFC5357] except for the definition of first 10 250 octets in Packet Padding that the Session-Sender expects to be 251 reflected. The new octets define fields for Value-Added Octets 252 Version, Flags, Last Sequence Number in Train and Desired Reverse 253 Packet Interval. Each of these fields are described in detail below. 255 The Session-Sender and Session-Reflector behaviors are also modified. 257 5.1 Sender Behavior 259 This section describes the extensions to the behavior of the TWAMP 260 Session-Sender. 262 5.1.1 Packet Timings 264 The Send Schedule is not utilized in TWAMP and this is unchanged in 265 this memo. 267 5.1.2 Session-Sender Packet Format 269 The Session-Sender packet format follows the same procedure and 270 guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and 271 Symmetrical Size Features [RFC6038]. 273 This feature allows the Session-Sender to set the first few octets in 274 the TWAMP-Test Packet Padding field with information to communicate 275 value-added padding version number, flag bits, sequence number of the 276 last packet in a train and desired reverse packet interval (or per- 277 packet waiting time) for the reverse path direction of transmission. 279 A version number and a sequence of flag bits are defined at the very 280 beginning of the value-added padding octets. The version number 281 identifies the version of the value-added padding octets and meaning 282 of the flag bits and corresponding fields. Each flag bit indicates if 283 a specific field is used in the valued-added padding octets. The 284 version number and flag bits provide an effective method for 285 extracting information at Session-Reflector and Session-Sender. This 286 document defines version 1 with two flag bits: L and I. 288 The format of the test packet depends on the TWAMP modes. The Value- 289 Added Octets Version 1 mode is intended to work with any TWAMP 290 modes. 292 The Session-Sender SHALL use the following TWAMP test packet format 293 when the Value-Added Octets version 1 is selected in conjunction with 294 the Unauthenticated mode: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Sequence Number | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Timestamp | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Error Estimate | Ver |L|I| Reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Last Seqno In Train | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Desired Reverse Packet Interval | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Additional Packet Padding | 311 . . 312 . . 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 The Session-Sender SHALL use the following TWAMP test packet format 316 when the Value-Added Octets Version 1 is selected in conjunction with 317 the Unauthenticated mode, Symmetrical Size mode and Reflect Octets 318 mode: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Sequence Number | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Timestamp | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Error Estimate | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 330 | | 331 | | 332 | MBZ (27 octets) | 333 | | 334 | | 335 | | 336 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | Ver |L|I| Reserved | Last... | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Seqno in Train | Desired... | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Reverse Packet Interval | Additional... | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Packet Padding | 344 . . 345 . . 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 The Session-Sender SHALL use the following TWAMP test packet format 349 when the Value-Added Octets Version 1 is selected in conjunction with 350 the Unauthenticated mode, Symmetrical Size mode and Reflect Octets 351 mode with a non-zero value in the Server Octets field: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sequence Number | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Timestamp | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Error Estimate | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 363 | | 364 | | 365 | MBZ (27 octets) | 366 | | 367 | | 368 | | 369 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | Server Octets | Ver |L|I| | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Reserved | Last Seqno in Train | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | Desired Reverse Packet Interval | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | Additional Packet Padding | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 . . 380 . . 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 In the mode using Reflect Octets illustrated above, the value-added 384 padding octets are embedded in the Packet Padding (to be reflected) 385 field. 387 The Version (Ver) field MUST be encoded in the first 4 bits. It 388 identifies the version number of the value-added padding octets and 389 meaning of the flag bits and the corresponding fields. This memo 390 defines version 1 with two flag bits: L and I. When the Value-Added 391 Octets Version 1 mode is selected, the Session-Sender MUST set the 392 Ver field to 1. 394 The 2 bits after the Version field are used for flags: L and I. 396 The Last Seqno in Train bit (L) is the first flag. When the Value- 397 Added Octets Version 1 mode is selected, the Session-Sender MAY set 398 the Last Seqno in Train bit L to 1. 400 The Desired Reverse Packet Interval bit (I) is the second flag. When 401 the Value-Added Octets Version 1 mode is selected, the Session-Sender 402 MAY set the Desired Reverse Packet Interval bit I to 1. 404 The Reserved field is reserved for future use. All 10 bits of the 405 Reserved field MUST be transmitted as zero by the Session-Sender. 407 If the Last Seqno in Train bit is set to 1, then the Last Seqno in 408 Train field MUST contain an unsigned 32 bit integer generated by the 409 Session-Sender. It MUST indicate the expected sequence number of the 410 last packet in the train. It SHOULD be used by the Session-Sender and 411 Session-reflector to identify the train a test packet belongs to. The 412 packets belonging to a train are determined by observing the test 413 packet sequence number in relation to the Last Seqno for a train. The 414 Last Seqno in Train MUST be higher or equal to the sequence number of 415 the packet. It must also be higher than the Last Seqno in Train for 416 the previous train. If the L bit is set to 0, the Session-Sender 417 shall set all the bits in the Last Seqno in Train field to zero. 419 If the Desired Reverse Packet Interval bit is set to 1, then the 420 Desired Reverse Packet Interval field MUST contain an unsigned 32 bit 421 integer generated by the Session-Sender. It MUST indicate the desired 422 packet interval (or the waiting time) that the Session-Reflector 423 SHOULD use when transmitting the reflected test packets towards the 424 Session-Sender. The value 0 means the The Session-Reflector SHOULD 425 return the test packet to the Session-Sender as quickly as possible. 426 The format of this field MUST be a fractional part of a second as 427 defined in OWAMP [RFC4656]. If I bit is set to 0, the Session-Sender 428 shall set all the bits in the Desired Reverse Packet Interval field 429 to zero. 431 The values of the above fields are usually provided by a measurement 432 method, tool or algorithm. This measurement algorithm is outside the 433 scope of this specification. 435 5.2 Reflector behavior 437 The TWAMP Session-Reflector follows the procedures and guidelines in 438 Section 4.2 of [RFC5357], with some changes and additional functions. 440 When the Value-Added Octets Version 1 is selected, the behavior of 441 the Session-Reflector SHALL be as follows: 443 o The Session-Reflector MUST read the Version field. If Ver = 1, 444 the Session-Reflector MUST read the L and I flag bits. 446 o If L=1 and I=1, the Session-Reflector MUST read and extract the 447 information from the Last Seqno in Train field and the Desired 448 Reverse Packet Interval field in the value-added padding 449 octets. 451 - The Last Seqno in Train field MUST be compared to Sequence 452 number in the same packet in order to determine when a 453 complete train has been collected. The Session-Reflector 454 SHOULD buffer the packets belonging to the current train (or 455 store the packet-level performance data). After the last 456 packet of the train has been received, the Session-Reflector 457 SHOULD transmit the packets belonging to a reverse train 458 with a waiting time (packet interval) for each packet 459 indicated in the Desired Reverse Packet Interval field. If 460 the Desired Reverse Packet Interval field is set to zero, 461 then the Session-Reflector SHOULD transmit the packet as 462 quickly as possible. The last packet within a train has 463 Sender Sequence Number = Last Seqno in Train. 465 - The Last Seqno in Train of a packet MUST also be compared to 466 the Last Seqno in Train of the previous packet in order to 467 determine if a new train needs to be collected. In case of 468 packet loss, the Session-Reflector MUST transmit the 469 incomplete train when it receives a packet with a Last SeqNo 470 in Train belonging to the another train (e.g. next train) of 471 the test session, or after a timeout. The timeout MAY be the 472 REFWAIT timer specified in section 4.2 of [RFC5357]. 474 - Packets arriving out-of-order within a train MUST be 475 buffered at the Session-Reflector if the train is not yet 476 transmitted to the Session-Sender. If the train is already 477 transmitted, the test packet SHOULD be returned to the 478 Session-Sender as quickly as possible. The Session-Reflector 479 MUST not reorder the test packets if they happen to arrive 480 out-of-sequence. 482 - Duplicate packets within a train MUST be buffered at the 483 Session-Reflector if the train is not yet transmitted to the 484 Session-Sender. If the train is already transmitted, the 485 duplicate test packet SHOULD be returned to the Session- 486 Sender as quickly as possible. The Session-Reflector MUST 487 not discard duplicate test packets. 489 For any other combinations of the Version field and the L and I 490 flags, the Session-Reflector SHOULD return the test packet to the 491 Session-Sender as quickly as possible. 493 The Session-Reflector MUST implement the changes described above when 494 the Value-Added Octets Version 1 mode is selected. 496 5.2.1 Session-Reflector Packet Format 498 The Session-Reflector packet format follows the same procedure and 499 guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and 500 Symmetrical Size Features [RFC6038], with the following changes: 502 o The Session-Reflector MUST re-use (reflect) the value-added 503 padding octets (10 octets) provided in the Sender's Packet 504 Padding. 506 o The Session-Reflector MAY re-use the rest of the padding octets 507 in the Sender's Packet Padding. 509 The truncation process [RFC5357] is recommended when the Symmetrical 510 mode is not used. The Session-Reflector MUST truncate exactly 27 511 octets of padding in Unauthenticated mode,and exactly 56 octets in 512 Authenticated and Encrypted modes. 514 5.3 Additional Considerations 516 Capacity measurements introduce an additional consideration when the 517 test sessions operate in TWAMP Light. When the Session-Reflector does 518 not have knowledge of the session state, the measurement system may 519 be restricted to estimate or calculate the capacity metrics in the 520 forward path direction of transmission only. Capacity measurements in 521 the reverse path direction is best handled with a Session-Reflector 522 supporting knowledge of the session state and being capable to 523 identify the test packets belonging to a specific test session. A 524 method for creating a session state from the initial test packet may 525 be implemented on the TWAMP Light Session-Reflector. This is outside 526 the scope of this specification. 528 6 Experiments 530 This memo describes the protocol used in the current working 531 prototype implementation of the Value-Added Octets feature in the 532 Ericsson lab. The prototype has been tested in real network 533 environments. The conclusion from these tests is that the Value-Added 534 Octets feature is able to enable estimation of capacity metrics such 535 as available path capacity in both the forward and reverse direction 536 of the network path. 538 During the experiments with the protocol described in this memo we 539 have identified a need for the controller and responder to use the 540 same maximum train length. The reflector must be able to buffer the 541 whole trains received from the controller. In order to reduce the 542 risk for buffer overrun the maximum train length should be 543 negotiated. This can be resolved through configuration, introduction 544 of new field in the value-added octets or with a new maximum train 545 length field in the Request-TW-Session message. 547 The Sender Discriminator (SD) field that is defined in the first 548 draft has been removed because of complications with different 549 Session-Reflector implementations. A Session-Reflector may not be 550 able to easily identify the SD field or associate it with a specific 551 Session-Sender which may skew the test results. 553 The flags defined in the value-added octets now indicate the usage of 554 fields and not the presence of fields. This modification was needed 555 to simplify the responder implementation in the working prototype. 557 7 Security Considerations 559 The value-added padding octets permit DoS attacks on the responder 560 host communicating with core TWAMP [RFC5357]. The responder host MUST 561 provide a mechanism to protect or limit the use of its local memory, 562 buffer space or maximum transmission time for a train. 564 The security considerations that apply to any active measurement of 565 live networks are relevant here as well. See [RFC4656] and [RFC5357]. 567 8 References 569 8.1 Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 575 Zekauskas, "A One-way Active Measurement 576 Protocol(OWAMP)", RFC 4656, September 2006. 578 [RFC5136] Chimento, P. and Ishac,J., "Defining Network Capacity", 579 RFC 5136, February 2008. 581 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 582 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 583 RFC 5357, October 2008. 585 [RFC6038] Morton, A., Ciavattone, L., TWAMP Reflect Octets and 586 Symmetrical Size Features, RFC6038 , October 2010. 588 8.2 Informative References 590 [RRBNC] Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J., 591 Cottrel, L., Pathchirp: Efficient available bandwidth 592 estimation for network paths, Passive and Active 593 Measurement Workshop, 2003. 595 [PDM] Dovrolis, C., Ramanathan, P., and Moore D., Packet 596 Dispersion Techniques and a Capacity Estimation 597 Methodology, IEEE/ACM Transactions on Networking, 598 December 2004. 600 [ENHJMMB] Ekelin, S., Nilsson, M., Hartikainen, E., Johnsson, A., 601 Mangs, J., Melander, B., Bjorkman, M., Real-time 602 measurement of end-to-end available bandwidth using 603 kalman filtering, Proceedings to the IEEE IFIP Network 604 Operations and Management Symposium, 2006. 606 [SBW] Sommers, J., Barford, P., Willinger, W., Laboratory-based 607 calibration of available bandwidth estimation tools, 608 Microprocess Microsyst., 2007. 610 [Y1540] ITU-T Y.1540, Internet protocol data communication service 611 - IP packet transfer and availability performance 612 parameters, 2011. 614 [MRM] Morton, A., Ramachandran, G., Maguluri, G., Reporting 615 Metrics Different Points of View, draft-ietf-ippm- 616 reporting-metrics-03, June 2010. 618 Author's Addresses 620 Steve Baillargeon 621 Ericsson 622 3500 Carling Avenue 623 Ottawa, Ontario K2H 8E9 624 Canada 625 EMail: steve.baillargeon@ericsson.com 626 Christofer Flinta 627 Ericsson 628 Farogatan 6 629 Stockholm, 164 80 630 Sweden 631 EMail: christofer.flinta@ericsson.com 633 Andreas Johnsson 634 Ericsson 635 Farogatan 6 636 Stockholm, 164 80 637 Sweden 638 EMail: andreas.a.johnsson@ericsson.com 640 Svante Ekelin 641 Ericsson 642 Farogatan 6 643 Stockholm, 164 80 644 Sweden 645 EMail: svante.ekelin@ericsson.com