Network Working Group                                     S. Baillargeon
INTERNET-DRAFT                                                 C. Flinta
Intended Status: Informational                               A. Johnsson
Expires: August 8, 2012                                        S. Ekelin
                                                                Ericsson
                                                        February 8, 2012


                        TWAMP Value-Added Octets
            draft-ietf-ippm-twamp-value-added-octets-00.txt


Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.



Abstract

   This memo describes optional extensions to the TWAMP test protocol
   for identifying and managing packet trains, which enables measuring
   capacity metrics like the available path capacity, tight section
   capacity and UDP delivery rate in the forward and reverse path
   directions.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html



Baillargeon, et al.      Expires August 8, 2012                 [Page 1]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































Baillargeon, et al.      Expires August 8, 2012                 [Page 2]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


Table of Contents

   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      1.1  Requirements Language . . . . . . . . . . . . . . . . . . . 4
   2  Purpose and scope  . . . . . . . . . . . . . . . . . . . . . . . 4
   3  Capacity Measurement Principles  . . . . . . . . . . . . . . . . 5
   4  TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . . 6
   5  Extended TWAMP Test  . . . . . . . . . . . . . . . . . . . . . . 7
      5.1  Sender Behavior . . . . . . . . . . . . . . . . . . . . . . 7
         5.1.1  Packet Timings . . . . . . . . . . . . . . . . . . . . 7
         5.1.2  Session-Sender Packet Format . . . . . . . . . . . . . 7
      5.2  Reflector behavior  . . . . . . . . . . . . . . . . . . .  12
         5.2.1  Session-Reflector Packet Format  . . . . . . . . . .  13
      5.3  Additional Considerations . . . . . . . . . . . . . . . .  14
   6  Security Considerations  . . . . . . . . . . . . . . . . . . .  14
   7  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  14
   8  References . . . . . . . . . . . . . . . . . . . . . . . . . .  15
      8.1  Normative References  . . . . . . . . . . . . . . . . . .  15
      8.2  Informative References  . . . . . . . . . . . . . . . . .  15
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16































Baillargeon, et al.      Expires August 8, 2012                 [Page 3]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


1  Introduction

   The notion of embedding a number of meaningful fields in the padding
   octets has been established as a viable methodology for carrying
   additional information within the TWAMP-Test protocol running between
   a Session-Sender and a Session-Reflector [RFC5357] [RFC6038].

   This memo describes an extension to the Two-Way Active Measurement
   Protocol [RFC5357]. It is called the Value-Added Octets feature.

   This feature enables the controller host to measure capacity metrics
   like the IP-type-P available path capacity (APC) [RFC5136], IP-layer
   tight section capacity (TSC) [Y1540] and UDP delivery rate (e.g. as
   defined in [RFC1242]) on both forward and reverse paths using a
   single TWAMP test session with symmetrical or asymmetrical test
   packet sizes. The actual method to calculate the APC, TSC or the UDP
   delivery rate from packet-level data performance data is not
   discussed in this memo.

   The Valued-Added Octets feature consists of new behaviors for the
   Session-Sender and Session-Reflector, and a set of value-added octets
   of information that are placed at the beginning of the Packet Padding
   field [RFC5357] or at the beginning of the Packet Padding (to be
   reflected) field [RFC6038] by the Session-Sender, and are reflected
   or returned by the Session-Reflector. The length of the value-added
   octets (version 1) is 14 octets.


1.1  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



2  Purpose and scope

   The purpose of this memo is to describe the Valued-Added Octets
   feature for TWAMP [RFC5357].

   The scope of the memo is limited to specifications of the following
   enhancements:

      o  The definition of a structure for embedding a sequence of
         value-added fields at the beginning of the Packet Padding field
         [RFC5037] or Packet Padding (to be reflected) field [RFC6038]
         in the TWAMP test packets and,



Baillargeon, et al.      Expires August 8, 2012                 [Page 4]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


      o  The definition of new Session-Sender and Session-Reflector
         behaviors

   The motivation for this feature is to enable the measurements of
   capacity metrics on both the forward and reverse paths with
   symmetrical or asymmetrical test packet sizes.

   This memo does not extend the modes of operation through assignment
   of a new value in the Modes field (see Section 3.1 of [RFC4656] for
   the format of the Server Greeting message). However a new mode is
   required to communicate feature capability and use in an
   interoperable manner. For instance, when the Server and Control-
   Client have agreed to use the Value-Added Octets Version 1 mode
   during control connection setup, then the Control-Client, the Server,
   the Session-Sender, and the Session-Reflector must all conform to the
   requirements of that mode, as identified below.

   The packet padding octets are designed to retain backward
   compatibility with the original TWAMP test protocol [RFC5357].

3  Capacity Measurement Principles

   Most capacity estimation methods for APC [RRBNC][PDM][ENHJMMB][SBW]
   and for UDP delivery rate need to send and receive packets in groups,
   called packet trains or simply trains. Each train is sent at a
   specific transmission rate in a given direction. These trains must be
   identified within each bi-directional test session stream.

   The first measurement principle is to send multiple trains within a
   test session stream from one IP node to another IP node in order to
   estimate the APC, TSC or UDP delivery rate in the forward direction.
   Each train consists of a group of test packets which are separated
   from each other by a packet interval, as shown in the picture below.
   The packet interval is measured using either the first bit or the
   last bit of two consecutive packets.

         tt                      tt                      tt
   |<---------->|          |<---------->|          |<---------->|
   |            |          |            |          |            |
   +------------+          +------------+          +------------+
   |  Packet 1  |          |  Packet 2  |          |  Packet 3  |
   +------------+          +------------+          +------------+
   |                       |                       |
   |<--------------------->|<--------------------->|
       packet interval 1       packet interval 2


   The test packet size and interval between consecutive packets for



Baillargeon, et al.      Expires August 8, 2012                 [Page 5]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   each train sent by the Session-Sender and reflected by the Session-
   Reflector MUST be calculated and determined by the controller or an
   application or entity communicating with the controller. The packet
   size and interval MAY vary within a train, between trains and MAY
   also be different depending on forward or reverse transmission
   direction. Determination of the packet size and interval is
   implementation-specific.

   The transmission time tt to send one packet (i.e. determined by the
   interface speed and the IP packet size) is also shown in the picture.
   Observe that the packet interval MUST be larger than or equal to tt.

   At the Session-Reflector, each received test packet within a forward
   train is time stamped. This provides a second set of packet interval
   values. Methods for measuring the APC, TSC and UDP delivery rate use
   the packet intervals obtained from both end points in the estimation
   process. The method to measuring the UDP delivery rate may also
   require the packet loss at the receiving end. The estimation process
   itself as well as any requirements on software or hardware is
   implementation-specific.

   The second measurement principle is referred to as self-induced
   congestion. According to this principle, in order to measure APC, TSC
   and UDP delivery rate, some trains MUST cause momentary congestion on
   the network path. In essence this means that some trains MUST be sent
   at a higher rate than what is available on the network path.

   In order to fulfill the above measurement principles and to measure
   the APC, TSC and UDP delivery rate in the reverse direction, the test
   packets at the Session-Reflector MUST be re-grouped into trains and
   then transmitted back to the Session-Sender with a provided packet
   interval.


4  TWAMP Control Extensions

   TWAMP-Control protocol [RFC5357] uses the Modes field to identify and
   select specific communication capabilities, and this field is a
   recognized extension mechanism.

   TWAMP connection establishment follows the procedure defined in
   Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357].  For
   interoperability, the Value-added octet feature require one new bit
   position (and value) to identify the ability of the Server/Session-
   Reflector to read and act upon the new fields in the value-added
   octets. Such bit position (and value) is not defined in this memo.

   Both the Reflect Octets mode and Symmetrical Size mode MAY be



Baillargeon, et al.      Expires August 8, 2012                 [Page 6]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   selected to ensure the reflection of the value-added padding octets
   by the Session-Reflector and symmetrical size TWAMP-Test packets in
   the forward and reverse directions of transmission.


5  Extended TWAMP Test

   The forward and reverse APC, TSC and UDP delivery rate measurement
   characteristics depend on the size and packet intervals of the test
   packets. This memo allows variable packet sizes and packet intervals
   between trains in different transmission directions, trains in the
   same transmission direction and even between packets in the same
   train. The functionality is described below.

   The TWAMP-test protocol carrying the value-added padding octets is
   identical to TWAMP [RFC5357] except for the definition of first 14
   octets in Packet Padding that the Session-Sender expects to be
   reflected. The new octets define fields for Value-Added Octets
   Version, Flags, Last Sequence Number in Train, Desired Reverse Packet
   Interval and Desired Reverse Padding Length. Each of these fields are
   described in detail below.

   The Session-Sender and Session-Reflector behaviors are also modified.

5.1  Sender Behavior

   This section describes the extensions to the behavior of the TWAMP
   Session-Sender.

5.1.1  Packet Timings

   The Send Schedule is not utilized in TWAMP and this is unchanged in
   this memo.

5.1.2  Session-Sender Packet Format

   The Session-Sender packet format follows the same procedure and
   guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and
   Symmetrical Size Features [RFC6038].

   This feature allows the Session-Sender to set the first few octets in
   the TWAMP-Test Packet Padding field with information to communicate
   value-added padding version number, flag bits, sequence number of the
   last packet in a train, desired reverse packet interval (or per-
   packet waiting time) and desired reverse padding length for the
   reverse path direction of transmission.

   A version number and a sequence of flag bits are defined at the very



Baillargeon, et al.      Expires August 8, 2012                 [Page 7]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   beginning of the value-added padding octets. The version number
   identifies the version of the value-added padding octets and meaning
   of the flag bits and corresponding fields. Each flag bit indicates if
   a specific field is used in the valued-added padding octets. The
   version number and flag bits provide an effective method for
   extracting information at Session-Reflector and Session-Sender. This
   document defines version 1 with three flag bits: L, I and P.

   The format of the test packet depends on the TWAMP mode and flag bits
   being used. The Value-Added Octets Version 1 mode is intended to work
   with any TWAMP modes.

   The Session-Sender SHALL use the following TWAMP test packet format
   when the Value-Added Octets Version 1 is selected in conjunction with
   the unauthenticated mode:


          0                   1                   2                   3
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Sequence Number                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          Timestamp                            |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Error Estimate        |  Ver  |L|I|P|   Reserved      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                      Last Seqno In Train                      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                Desired Reverse Packet Interval                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                Desired Reverse Padding Length                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
         |                   Additional Packet Padding                   |
         .                                                               .
         .                                                               .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+














Baillargeon, et al.      Expires August 8, 2012                 [Page 8]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   The Session-Sender SHALL use the following TWAMP test packet format
   when the Value-Added Octets Version 1 is selected in conjunction with
   the unauthenticated mode, Symmetrical Size mode and Reflect Octets
   mode:


          0                   1                   2                   3
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Sequence Number                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          Timestamp                            |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Error Estimate        |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
         |                                                               |
         |                                                               |
         |                         MBZ (27 octets)                       |
         |                                                               |
         |                                                               |
         |                                                               |
         |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |  Ver  |L|I|P|    Reserved     |    Last...    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               Seqno in Train                  |   Desired...  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Reverse Packet Interval               |   Desired...  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Reverse Padding Length                |               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
         |         Additional Packet Padding                             |
         .                                                               .
         .                                                               .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
















Baillargeon, et al.      Expires August 8, 2012                 [Page 9]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   The Session-Sender SHALL use the following TWAMP test packet format
   when the Value-Added Octets Version 1 is selected in conjunction with
   the unauthenticated mode, Symmetrical Size mode and Reflect Octets
   mode with a non-zero value in the Server octets field:


          0                   1                   2                   3
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Sequence Number                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          Timestamp                            |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Error Estimate        |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
         |                                                               |
         |                                                               |
         |                         MBZ (27 octets)                       |
         |                                                               |
         |                                                               |
         |                                                               |
         |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |         Server octets         |  Ver  |L|I|P| |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Reserved   |         Last Seqno in Train                   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |         Desired Reverse Packet Interval       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |         Desired  Reverse Padding Length       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |         Additional Packet Padding             |
         +-+-+-+-+-+-+-+-+                                               |
         |                                                               |
         .                                                               .
         .                                                               .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   In the mode using Reflect Octets illustrated above, the value-added
   padding octets are embedded in the Packet Padding (to be reflected)
   field.







Baillargeon, et al.      Expires August 8, 2012                [Page 10]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   The Version (Ver) field MUST be encoded in the first 4 bits. It
   identifies the version number of the value-added padding octets and
   meaning of the flag bits and the corresponding fields. This memo
   defines version 1. When the Value-Added Octets Version 1 mode is
   selected, the Session-Sender MUST set the Ver field to 1.

   The 3 bits after the Version field are used for flags: L, I and P.

   The Last Seqno in Train bit (L) is the first flag. When the Value-
   Added Octets Version 1 mode is selected, the Session-Sender MAY set
   the Last Seqno in Train bit L to 1.

   The Desired Reverse Packet Interval bit (I) is the second flag. When
   the Value-Added Octets Version 1 mode is selected, the Session-Sender
   MAY set the Desired Reverse Packet Interval bit I to 1.

   The Desired Reverse Padding Length bit (P) is the third flag. When
   the Value-Added Octets Version 1 mode is selected, the Session-Sender
   MAY set the Desired Reverse Padding Length bit P to 1.

   The Reserved field is reserved for future use. All 9 bits of the
   Reserved field MUST be transmitted as zero by the Session-Sender.

   If the Last Seqno in Train bit is set to 1, then the Last Seqno in
   Train field MUST contain an unsigned 32 bit integer generated by the
   Session-Sender. It MUST indicate the expected sequence number of the
   last packet in the train. It SHOULD be used by the Session-Sender and
   Session-reflector to identify the train a test packet belongs to. The
   packets belonging to a train are determined by observing the test
   packet sequence number in relation to the Last Seqno for a train. The
   Last Seqno in Train MUST be higher or equal to the sequence number of
   the packet. It must also be higher than the Last Seqno in Train for
   the previous train. If the L bit is set to 0, the Session-Sender
   shall set all the bits in the Last Seqno in Train field to zero.

   If the Desired Reverse Packet Interval bit is set to 1, then the
   Desired Reverse Packet Interval field MUST contain an unsigned 32 bit
   integer generated by the Session-Sender. It MUST indicate the desired
   packet interval (or the waiting time) that the Session-Reflector
   SHOULD use when transmitting the reflected test packets towards the
   Session-Sender. The value 0 means the The Session-Reflector SHOULD
   return the test packet to the Session-Sender as quickly as possible.
   The format of this field MUST be a fractional part of a second as
   defined in OWAMP [RFC4656]. If I bit is set to 0, the Session-Sender
   shall set all the bits in the Desired Reverse Packet Interval field
   to zero.

   If the Desired Reverse Padding Length bit is set to 1, then the



Baillargeon, et al.      Expires August 8, 2012                [Page 11]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   Desired Reverse Padding Length field MUST contain an unsigned 32 bit
   integer generated by the Session-Sender. It MUST specify the number
   of padding octets that the Session-Reflector will append to the
   TWAMP-Test packet to be reflected. The Desired Reverse Padding Length
   includes the Value-added octets. If P bit is set to 0, the Session-
   Sender shall set all the bits in the Desired Reverse Padding Length
   field to zero.

   The values of the above fields are usually provided by a measurement
   method, tool or algorithm. This measurement algorithm is outside the
   scope of this specification.










5.2  Reflector behavior

   The TWAMP Session-Reflector follows the procedures and guidelines in
   Section 4.2 of [RFC5357], with some changes and additional functions.

   When the Value-Added Octets Version 1 is selected, the behavior of
   the Session-Reflector SHALL be as follows:

      o  The Session-Reflector MUST read the Version field. If Ver = 1,
         the Session-Reflector MUST read the L, I and P flag bits.

      o  If L=1 and I=1, the Session-Reflector MUST read and extract the
         information from the Last Seqno in Train field and the Desired
         Reverse Packet Interval field in the value-added padding
         octets.

         -  The Last Seqno in Train field MUST be compared to Sequence
            number in the same packet in order to determine when a
            complete train has been collected. The Session-Reflector
            SHOULD buffer the packets belonging to the current train (or
            store the packet-level performance data). After the last
            packet of the train has been received, the Session-Reflector
            SHOULD transmit the packets belonging to a reverse train
            with a waiting time (packet interval) for each packet
            indicated in the Desired Reverse Packet Interval field. If
            the Desired Reverse Packet Interval field is set to zero,
            then the Session-Reflector SHOULD transmit the packets as



Baillargeon, et al.      Expires August 8, 2012                [Page 12]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


            quickly as possible. The last packet within a train has
            Sender Sequence Number = Last Seqno in Train.

         -  The Last Seqno in Train of a packet MUST also be compared to
            the Last Seqno in Train of the previous packet in order to
            determine if a new train needs to be collected. In case of
            packet loss, the Session-Reflector MUST transmit the
            incomplete train when it receives a packet with a Last SeqNo
            in Train belonging to the another train (e.g. next train) of
            the test session, or after a timeout. The timeout MAY be the
            REFWAIT timer specified in section 4.2 of [RFC5357].

         -  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.

         -  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.

      o If P=1, the Session-Reflector MUST read and extract the
         information from the Desired Reverse Padding Length field in
         the value-added padding octets.

         - The Session-Reflector SHOULD transmit the packet with the
            Desired Reverse Padding Length. If Symmetrical-Size mode is
            used the Desired Reverse Padding Length must be ignored by
            the Session-Reflector. The actual reflected packet size MUST
            be large enough to contain all data required to be reflected
            according to selected modes. If the Desired Reverse Padding
            Length is larger than the Session-Reflector MTU, the MTU
            MUST be used.


   The Session-Reflector MUST implement the changes described above when
   the Value-Added Octets Version 1 mode is selected.


5.2.1  Session-Reflector Packet Format

   The Session-Reflector packet format follows the same procedure and



Baillargeon, et al.      Expires August 8, 2012                [Page 13]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and
   Symmetrical Size Features [RFC6038], with the following changes:

      o  The Session-Reflector MUST re-use (reflect) the value-added
         padding octets (14 octets) provided in the Sender's Packet
         Padding.

      o  The Session-Reflector MAY re-use the rest of the padding octets
         in the Sender's Packet Padding.

   The truncation process [RFC5357] is recommended when the Desired
   Reverse Padding Length (P) bit is 0 and the Symmetrical mode is not
   used. The Session-Reflector MUST truncate exactly 27 octets of
   padding in Unauthenticated mode,and exactly 56 octets in
   Authenticated and Encrypted modes.


5.3  Additional Considerations



   Capacity measurements introduce an additional consideration when the
   test sessions operate in TWAMP Light. When the Session-Reflector does
   not have knowledge of the session state, the measurement system will
   only be capable to estimate or calculate the capacity metrics in the
   forward path direction of transmission. Capacity measurements in the
   reverse path direction requires the Session-Reflector to have
   knowledge of the session state and be capable to identify the test
   packets belonging to a specific test session. The method for creating
   a session state from the initial test packets on the TWAMP Light
   Session-Reflector is outside the scope of this specification.




6  Security Considerations

   The value-added padding octets permit DoS attacks on the responder
   host communicating with core TWAMP [RFC5357]. The responder host MUST
   provide a mechanism to protect or limit the use of its local memory,
   buffer space or maximum transmission time for a train.

   The security considerations that apply to any active measurement of
   live networks are relevant here as well. See [RFC4656] and [RFC5357].


7  IANA Considerations




Baillargeon, et al.      Expires August 8, 2012                [Page 14]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   IANA has created a TWAMP-Modes registry (as requested in [RFC5618]).
   TWAMP-Modes are specified in TWAMP Server Greeting messages and Setup
   Response messages, as described in Section 3.1 of [RFC5357],
   consistent with Section 3.1 of [RFC4656]. Modes are indicated by
   setting bits in the 32-bit Modes field that correspond to values in
   the Modes registry. For the TWAMP-Modes registry, new features are
   usually assigned increasing registry values that correspond to single
   bit positions.

   This memo does not define a new TWAMP mode. Therefore it is not a
   recognized extension mechanism for TWAMP. A new mode is required to
   communicate feature capability and use in an interoperable manner.
   This is outside the scope of this memo.



8  References

8.1  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4656]   Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
               Zekauskas, "A One-way Active Measurement
               Protocol(OWAMP)", RFC 4656, September 2006.

   [RFC5136]   Chimento, P. and Ishac,J., "Defining Network Capacity",
               RFC 5136, February 2008.

   [RFC5357]   Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
               Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
               RFC 5357, October 2008.

   [RFC6038]   Morton, A., Ciavattone, L., TWAMP Reflect Octets and
               Symmetrical Size Features, RFC6038 , October 2010.


8.2  Informative References

   [RRBNC]     Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J.,
               Cottrel, L., Pathchirp: Efficient available bandwidth
               estimation for network paths, Passive and Active
               Measurement Workshop, 2003.

   [PDM]       Dovrolis, C., Ramanathan, P., and Moore D., Packet
               Dispersion Techniques and a Capacity Estimation
               Methodology, IEEE/ACM Transactions on Networking,



Baillargeon, et al.      Expires August 8, 2012                [Page 15]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


               December 2004.

   [ENHJMMB]   Ekelin, S., Nilsson, M., Hartikainen, E., Johnsson, A.,
               Mangs, J., Melander, B., Bjorkman, M., Real-time
               measurement of end-to-end available bandwidth using
               kalman filtering, Proceedings to the IEEE IFIP Network
               Operations and Management Symposium, 2006.

   [SBW]       Sommers, J., Barford, P., Willinger, W., Laboratory-based
               calibration of available bandwidth estimation tools,
               Microprocess Microsyst., 2007.

   [Y1540]   ITU-T Y.1540, Internet protocol data communication service
               - IP packet transfer and availability performance
               parameters, 2011.

   [MRM]       Morton, A., Ramachandran, G., Maguluri, G., Reporting
               Metrics Different Points of View, draft-ietf-ippm-
               reporting-metrics-03, June 2010.


Author's Addresses

   Steve Baillargeon
   Ericsson
   3500 Carling Avenue
   Ottawa, Ontario K2H 8E9
   Canada
   EMail: steve.baillargeon@ericsson.com


   Christofer Flinta
   Ericsson
   Farogatan 6
   Stockholm, 164 80
   Sweden
   EMail: christofer.flinta@ericsson.com


   Andreas Johnsson
   Ericsson
   Farogatan 6
   Stockholm, 164 80
   Sweden
   EMail: andreas.a.johnsson@ericsson.com


   Svante Ekelin



Baillargeon, et al.      Expires August 8, 2012                [Page 16]


INTERNET DRAFT          Value-Added TWAMP Octets        February 8, 2012


   Ericsson
   Farogatan 6
   Stockholm, 164 80
   Sweden
   EMail: svante.ekelin@ericsson.com














































Baillargeon, et al.      Expires August 8, 2012                [Page 17]