<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-morton-ippm-twamp-rate-05"
     ipr="trust200902" updates="5357">
  <front>
    <title abbrev="Burst Rate &amp; Size">TWAMP Burst Rate Measurement
    Features</title>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acmorton@att.com</email>

        <uri>http://home.comcast.net/~acmacm/</uri>
      </address>
    </author>

    <author fullname="Len Ciavattone" initials="L." surname="Ciavattone">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1239</phone>

        <facsimile/>

        <email>lencia@att.com</email>

        <uri/>
      </address>
    </author>

    <date day="13" month="February" year="2014"/>

    <abstract>
      <t>This memo describes two rate-measurement features for the core
      specification of TWAMP - the Two-Way Active Measurement Protocol: an
      optional capability where the reflector host responds with a controlled
      burst of test-session packets (instead of a single packet), and an
      optional test mode that requires the responder to measure a burst of
      test packets and communicate the results in truncated packet(s). Both
      features add the ability to control packet size in the tested direction,
      enabling asymmetrical packet size testing. This draft defines the modes
      in terms of traditional UDP test packets. Use of TCP transport instead
      of UDP may be desirable, but is deferred to other work.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>TWAMP - the Two-Way Active Measurement Protocol <xref
      target="RFC5357"/> is an extension of the One-way Active Measurement
      Protocol, OWAMP <xref target="RFC4656"/>. The TWAMP specification
      gathered wide review as it was deployed, resulting in recommendations
      for new features.</t>

      <t>This memo describes two closely-related features for TWAMP. When
      measuring packet delivery rate to end-systems, unique control and
      measurement capabilities become useful, especially when the path tested
      includes asymmetrical link speeds (as are often deployed in consumer
      Internet access services).</t>

      <t>One feature is the OPTIONAL capability for the responder host to
      return a controlled burst of test-session packets (instead of a single
      packet).</t>

      <t>Another is an optional sender packet format that requires the
      responder to measure a burst of test packets and communicate the results
      in a single packet.</t>

      <t>Both features add the ability to control packet size in each
      direction, enabling asymmetrical packet size testing. Although TWAMP
      <xref target="RFC5357"/> recommends padding truncation to achieve
      symmetrical sizes (to compensate for the Session-Reflector's larger test
      packet header), these features configure test packet sizes when the test
      session is requested using the TWAMP-Control protocol.</t>

      <t>This memo is an update to the TWAMP core protocol specified in <xref
      target="RFC5357"/>. Measurement systems are not required to implement
      the features described in this memo to claim compliance with <xref
      target="RFC5357"/>.</t>

      <t>Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set
      to zero by senders and MUST be ignored by receivers. Also, the HMAC
      (Hashed Message Authentication Code) MUST be calculated as defined in
      Section 3.2 of <xref target="RFC4656"/>.</t>

      <section title="Alternate Transport Protocol Selection">
        <t>An open question in the IPPM problem statement draft <xref
        target="I-D.ietf-ippm-rate-problem"/> is whether testing with TCP
        transport protocol is a needed capability. The current TWAMP test
        protocol capability is limited to UDP transport.</t>

        <t>This is clearly a topic where coordination is required between the
        testing sender and receiver devices. It could be specified as an
        independent TWAMP feature, and although it is clearly related to the
        features described here, the work is deferred to a future memo.</t>
      </section>
    </section>

    <section title="Purpose and Scope">
      <t>The purpose of this memo is to define two OPTIONAL closely-related
      features for TWAMP <xref target="RFC5357"/>. The features enhance the
      TWAMP responder's capabilities to perform a simple operations on test
      packets, and the capability to demand asymmetrical size TWAMP-Test
      packets.</t>

      <t>This memo is intended to satisfy key requirements contianed in the
      IPPM problem statement <xref target="I-D.ietf-ippm-rate-problem"/>.
      Referring to the reference path defined in <xref
      target="I-D.morton-ippm-lmap-path"/>, possible measurement points
      include a Subscriber's host (mp000), the access service demarcation
      point (mp100), Intra IP access where a globally routable address is
      present (mp150), or the gateway between the measured access network and
      other networks (mp190). The requirements of this testing environment
      make it difficult to "correctly" generate fixed rate packet ensembles.
      Some of the devices doing the generation and/or measurement were
      designed for low-cost-large-scale deployment and primarily for a purpose
      other than measurement.</t>

      <t>The scope of the memo is limited to specifications of the following
      features:</t>

      <t><list style="symbols">
          <t>Burst Generation: the capability of the Session-Reflector to
          generate a burst of packets for return to the Session-Sender, and
          the corresponding TWAMP-Control messages to activate the capability
          between compliant hosts.</t>

          <t>Burst Measurement: the capability of the Session-Reflector to
          measure a burst of packets from the Session-Sender, report the key
          information (receive timestamps) in the response packet(s), and the
          corresponding TWAMP-Control messages to activate the capability
          between compliant hosts.</t>

          <t>Asymmetrical Size: the capability to ensure that TWAMP-Test
          protocol uses a specific packet size in each direction. This feature
          is combined with the Burst features, and essentially adds a third
          simple capability when the Burst size = 1.</t>
        </list>This memo extends the modes of operation through assignment of
      two new values in the Modes Field (see section 3.1 of<xref
      target="RFC4656"/> for the format of the Server Greeting message), while
      retaining backward compatibility with the core TWAMP <xref
      target="RFC5357"/> implementations. The two new values correspond to the
      two features defined in this memo.</t>

      <t>When the Server and Control-Client have agreed to use the Burst
      Generation 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.</t>

      <t>When the Server and Control-Client have agreed to use the Burst
      Measurement 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.</t>
    </section>

    <section title="TWAMP Control Extensions">
      <t>TWAMP-Control protocol <xref target="RFC5357"/> uses the Modes Field
      to identify and select specific communication capabilities, and this
      field is a recognized extension mechanism. The following sections
      describe two such extensions.</t>

      <section title="Connection Setup with New Features">
        <t>TWAMP connection establishment follows the procedure defined in
        section 3.1 of <xref target="RFC4656"/> and section 3.1 of <xref
        target="RFC5357"/>. The new features require two new bit positions
        (and values). See the IANA section for details on the assigned values
        and bit positions.</t>

        <t>The Server sets one or both of the new bit positions in the Modes
        Field of the Server Greeting message to indicate its capabilities and
        willingness to operate in either of these modes if desired.</t>

        <t>If the Control-Client intends to operate all test sessions invoked
        with this control connection using one of the new modes, it MUST set
        the Mode Field bit corresponding to each function in the Setup
        Response message. With this and other extensions, the Control-Client
        MAY set multiple Mode Field bits in the Setup Response message, but
        these new features are mutually exclusive, and MUST NOT be used
        together.</t>
      </section>

      <section title="Burst Generation: Request-TW-Session Packet Format">
        <t>The bits designated for the Burst Generation feature in the
        Request-TW-Session command are as shown in the packet format
        below.</t>

        <t><figure>
            <preamble/>

            <artwork><![CDATA[ 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      5        |  MBZ  | IPVN  |  Conf-Sender  | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Number of Schedule Slots                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Number of Packets*                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.           ... Many fields (62 octets) not shown ...           .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Padding Length*  (4 octets)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Start Time, (8 octets)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Timeout, (8 octets)                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Type-P Descriptor                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Octets to be reflected    |  Length of padding to reflect |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (2 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

            <postamble>* = re-interpreted field</postamble>
          </figure></t>

        <t>Two re-interpreted fields appear in the Request-TW-Session command
        when using Burst Generation mode:</t>

        <t><list style="numbers">
            <t>Number of Packets: In this mode, re-interpreted as the number
            of packets that the Session-Reflector MUST generate in each
            Burst.</t>

            <t>Packet Padding Length: In the mode, re-interpreted as the
            number of octets the Session-Reflector MUST append to the Test
            packet header of each packet it generates as part of the burst.
            The Session-Reflector MUST NOT assume that the Session-Sender will
            use any packet padding, and MUST be prepared to generate the
            padding itself.</t>
          </list></t>
      </section>

      <section title="Burst Measurement: Request-TW-Session Packet Format">
        <t>The bits designated for the Burst Generation feature in the
        Request-TW-Session command are as shown in the packet format
        below.</t>

        <t><figure>
            <preamble/>

            <artwork><![CDATA[ 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      5        |  MBZ  | IPVN  |  Conf-Sender  | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Number of Schedule Slots                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Number of Packets*                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.           ... Many fields (62 octets) not shown ...           .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Padding Length  (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Start Time, (8 octets)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Timeout*, (8 octets)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Type-P Descriptor                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Octets to be reflected    |  Length of padding to reflect |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (2 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

            <postamble>* = re-interpreted field</postamble>
          </figure></t>

        <t>Two re-interpreted fields appear in the Request-TW-Session command
        when using Burst Measurement mode:</t>

        <t><list style="numbers">
            <t>Number of Packets: In this mode, re-interpreted as the number
            of packets that the Session-Reflector MUST expect to measure as
            part of each Burst.</t>

            <t>Timeout: In this mode, re-interpreted as the time to wait for
            all packets in a burst to arrive, expressed in the existing
            timestamp format used in TWAMP and OWAMP. In the case of lost
            packets, the Session-Reflector is commanded to wait through this
            time-out for packets in a burst to arrive.</t>
          </list></t>
      </section>

      <section title="Burst Gen and Meas: Accept Session Packet Format">
        <t>The Accept Session command for the Burst feature is as shown in the
        packet format below (assuming the Reflect Octets feature is also in
        use).</t>

        <t><figure>
            <preamble/>

            <artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Accept     |      MBZ      |            Port               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                                                               |
|                        SID (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Reflected octets        |         Server octets         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (8 octets)                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>

            <postamble/>
          </figure></t>
      </section>

      <section title="Burst Gen and Meas: Stopping Test Sessions">
        <t>The Control-Client SHALL stop in-progress test sessions using any
        standardized methods, including section 3.8 of <xref
        target="RFC5357"/> or the optional capability of <xref
        target="RFC5938"/>.</t>
      </section>

      <section title="Additional considerations">
        <t>The value of the Modes Field sent by the Server in the Server
        Greeting message is the bit-wise OR of the mode values that it is
        willing to support during this session.</t>

        <t>We note that Burst Generation and Measurement features are
        incompatible with each other, and with the Symmetrical Size feature
        described in <xref target="RFC6038"/>, and MUST NOT be used in
        combination with those features.</t>

        <t>With the publication of this memo as an RFC, the last 9 bit
        positions of the Modes 32-bit Field are used. A Control-Client
        conforming to this extension of <xref target="RFC5357"/> MAY ignore
        the values in the higher bits of the Modes Field, or it MAY support
        other features that are communicated in those bit positions. The other
        bits are available for future protocol extensions.</t>
      </section>
    </section>

    <section title="Burst Generation in TWAMP Test">
      <t>The TWAMP test protocol is similar to the OWAMP <xref
      target="RFC4656"/> test protocol with the exception that the
      Session-Reflector transmits test packets to the Session-Sender in
      response to each test packet it receives. The Burst Generation feature
      modifies the behavior of TWAMP section 4<xref target="RFC5357"> </xref>.
      This mode requires the Session-Sender to send a Burst-Initiation packet,
      and the Session-Reflector generates test session packets according to
      the configuration agreed using the TWAMP-Control protocol.</t>

      <section title="Sender Behavior">
        <t>This section describes extensions to the behavior of the TWAMP
        Session-Sender.</t>

        <section title="Packet Timings">
          <t>The Send Schedule is not utilized in TWAMP, and this is unchanged
          in this memo.</t>
        </section>

        <section title="Packet Formats and Contents">
          <t>The Session-Sender packet format and content follow the same
          procedure and guidelines as defined in section 4.1.2 of <xref
          target="RFC4656"/> (as indicated in section 4.1.2 of TWAMP <xref
          target="RFC5357"/>).</t>

          <t>This mode uses the original TWAMP-Test Packet Padding Field (see
          section 4.1.2 of <xref target="RFC4656"/>), or can be used with
          Reflect Octets feature as shown below for unauthenticated mode:</t>

          <t><figure>
              <preamble/>

              <artwork><![CDATA[ 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        |                               |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
|                                                               | 
|                  Packet Padding (to be reflected)             | 
.               (length in octets specified in command)         . 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                  Additional Packet Padding                    .
.                                                               . 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>

              <postamble>Burst Initiation Packet Format</postamble>
            </figure></t>

          <t>The Sequence Number, Timestamp, and Error Estimate fields are the
          same as specified in section 4.1.2 of <xref target="RFC4656"/> in
          OWAMP.</t>

          <t>We note that the format of the Burst Initiation packet has not
          been changed from the usual Session-Sender test packet format, to
          simplify adoption.</t>
        </section>
      </section>

      <section title="Reflector Behavior">
        <t>The TWAMP Reflector differs significantly from the procedures and
        guidelines in section 4.2 of <xref target="RFC5357"/>. The following
        new functions MUST be performed:</t>

        <t><list style="symbols">
            <t>Recognition of the function of the Burst Initiation Packet used
            in this mode.</t>

            <t>Generation of the required burst of test session packets,
            according to the configuration agreed in Request-TW-Session
            command, with the agreed number of packets in each burst and size
            of each packet in the burst.</t>
          </list></t>

        <section title="Session-Reflector Burst Packet Format and Contents">
          <t>The Burst Generation feature retains the usual Reflector packet
          fields, as shown below. When the Burst Generation mode is selected,
          the Session-Reflector SHALL use the following TWAMP-Test Packet
          Format in Unauthenticated mode (shown with Reflect Octets feature
          activated):</t>

          <t><figure>
              <preamble/>

              <artwork align="center"><![CDATA[ 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                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                       Receive Timestamp                       | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                     Sender Sequence Number                    | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                       Sender Timestamp                        | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |      Sender Error Estimate    |           MBZ                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |  Sender TTL   |         Packet Padding (from Session-Sender)  | 
 +-+-+-+-+-+-+-+-+                                               +
 .                                                               . 
 +                                               +-+-+-+-+-+-+-+-+ 
 |          Packet Padding (from Session-Sender) |               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               + 
 |                                                               | 
 |                                                               |
 .                  Additional Packet Padding                    . 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ]]></artwork>

              <postamble/>
            </figure></t>

          <t>Section 4.2.1 of <xref target="RFC5357"/> describes the above
          fields as used in TWAMP, with one exception.</t>

          <t>The Sequence Number field SHALL indicate the sequence number of
          each packet sent throughout the test session. The Sequence Number
          SHALL be increased by 1 for each packet. The initial Sequence Number
          SHALL be 0.</t>

          <t>When one burst is complete, the Sequence Numbers SHALL continue
          to increment by 1 in the packets generated in response to the next
          burst.</t>

          <t>The total Packet Padding octets SHALL have the length specified
          in the TWAMP-Control request for the appropriate test session. The
          Session-Reflector MAY need to generate its own packet padding, if
          the Burst Request packet does not include this field (or contains
          insufficient padding).</t>

          <t>In any case, the Session-Reflector MAY re-use the Sender&rsquo;s
          Packet Padding (since the requirements for padding generation are
          the same for each) when possible.</t>

          <t>The Session-Reflector SHALL send a series of TWAMP-Test Packets
          in response to reception of the Burst Initiation Packet, according
          to the configuration agreed in the Request-TW-Session command
          (number of packets and padding), and as immediately as possible. The
          Session-Reflector SHALL send all packets in a burst as close to
          back-to-back as possible (recognizing that lower layers may have
          spacing requirements that take precedence).</t>
        </section>
      </section>
    </section>

    <section title="Burst Measurement in TWAMP Test">
      <t>The Burst Measurement feature modifies the behavior of TWAMP section
      4<xref target="RFC5357"> </xref>. This mode requires the Session-Sender
      to send a Burst of test packets, and the Session-Reflector measures the
      burst of packets and reports the results in the Burst Response packet
      format(s), as described below.</t>

      <section title="Sender Behavior">
        <t>This section describes extensions to the behavior of the TWAMP
        Session-Sender.</t>

        <section title="Packet Timings">
          <t>The Session-Sender SHALL send all packets in a burst as close to
          back-to-back as possible (recognizing that lower layers may have
          spacing requirements that take precedence).</t>
        </section>

        <section title="Packet Formats and Contents">
          <t>The Session-Sender packet format and content SHALL comply with
          that defined in section 4.1.2 of <xref target="RFC4656"/> (as
          indicated in section 4.1.2 of TWAMP <xref target="RFC5357"/>).</t>

          <t>This mode uses the original TWAMP-Test Packet Padding Field (see
          section 4.1.2 of <xref target="RFC4656"/>), or can be used with
          Reflect Octets feature as shown below for unauthenticated mode:</t>

          <t><figure>
              <preamble/>

              <artwork align="center"><![CDATA[ 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                     Burst Sequence Number                     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                          Timestamp                            | 
|                                                               | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|         Error Estimate        |                               |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
|                                                               | 
|                  Packet Padding (to be reflected)             | 
.               (length in octets specified in command)         . 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                  Additional Packet Padding                    .
.                                                               . 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>

              <postamble>Session-Sender Burst Test Packet Format</postamble>
            </figure></t>

          <t>The Burst Sequence Number field SHALL indicate the number of each
          burst. The Burst Sequence Number SHALL be increased by 1 for each
          burst, and remain the same for each packet in a burst. The initial
          number SHALL be 0.</t>

          <t>When one burst is complete, the Burst Sequence Number used in the
          all packets of the next burst SHALL be increased by 1.</t>
        </section>
      </section>

      <section title="Reflector Behavior">
        <t>The TWAMP Reflector differs slightly from the procedures and
        guidelines in section 4.2 of <xref target="RFC5357"/>. The following
        new functions MUST be performed:</t>

        <t><list style="symbols">
            <t>Recognition of the function of the Session-Sender Burst Test
            Packet Format used in this mode.</t>

            <t>Processing the required bursts of test session packets,
            according to the configuration agreed in Request-TW-Session
            command, with the agreed length of the burst in packets and size
            of each packet in the burst, and the agreed Burst Time-out.</t>

            <t>Response with an abbreviated Session-Reflector test packet as
            described below. For discussion, we will call this the 1-to-1
            response.</t>

            <t>OR - Response with the new Burst Measurement Response packet
            described below. For discussion, we will call this the accumulated
            response.</t>
          </list>We seek feedback from the IPPM working group on which of
        these two alternatives is preferable.</t>

        <section title="Session-Reflector Burst Measurement Response Packet Format and Contents">
          <t>The Burst Measurement feature specifies a standard
          Session-Reflector packet to communicate the results, as shown below.
          When the Burst measurement mode is selected, the Session-Sender
          SHALL use the following Burst Measurement Response packet Format in
          Unauthenticated mode (shown with Reflect Octets feature also in
          use):</t>

          <t><figure>
              <preamble/>

              <artwork align="center"><![CDATA[ 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                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B 
 |                       Receive Timestamp                       | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                  Sender Burst Sequence Number                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                        Sender Timestamp                       B 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |      Sender Error Estimate    |           MBZ                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |  Sender TTL   |         Packet Padding (from Session-Sender)  | 
 +-+-+-+-+-+-+-+-+                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B]]></artwork>

              <postamble>Session-Reflector Measurement Packet (1-to-1
              response)</postamble>
            </figure></t>

          <t>Section 4.2.1 of <xref target="RFC5357"/> describes the fields in
          the 1-to-1 response packet above; they are the same as used in
          TWAMP. The main difference is that Packet Padding SHALL be truncated
          on a 16 octet-word boundary, returning the minimum information to
          the Session-Sender.</t>

          <t>All Timestamps SHALL be formatted according to the precedent set
          in section 4.1.2 of <xref target="RFC4656"/>, which is to use <xref
          target="RFC1305"/> (and updated version), as follows:</t>

          <t>"The first 32 bits represent the unsigned integer number of
          seconds elapsed since 0h on 1 January 1900; the next 32 bits
          represent the fractional part of a second that has elapsed since
          then."</t>

          <t>The Session-Reflector MUST truncate the Sender's Packet Padding,
          unless the Reflect Octets feature is also active in which case the
          Session_Reflector MAY re-use the Sender&rsquo;s Packet Padding
          (since the requirements for padding generation are the same for
          each) to reach a word boundary.</t>

          <t>The Sender Timestamp field SHALL have the sender's timestamp from
          each packet received in the burst.</t>

          <t>In 1-to-1 response mode, the Session-Reflector SHALL send a
          Session-Reflector Measurement Packet in response to every
          Session-Sender packet received, and as quickly as possible.</t>

          <t>========================================================</t>

          <t>In the accumulated response alternative, the Session-Reflector
          creates and holds all packet headers described above in a buffer,
          and sends them all at once in a single Session-Reflector test
          packet. The length of the burst and the path MTU MUST be coordinated
          to avoid fragmentation.</t>

          <t>The first Session-Sender packet to arrive with a previously
          unseen Burst Sequence Number SHALL be designated as the "First"
          packet in that burst, and its timestamp is used in processing
          below.</t>

          <t>As subsequent packets arrive, Session-Reflector SHALL:</t>

          <t><list style="symbols">
              <t>Maintain a count of packets with the same Burst Sequence
              Number (one burst).</t>

              <t>Time stamp each packet as it arrives and store the time stamp
              in a response packet structure with all fields complete, as in
              the 1-to-1 alternative.</t>
            </list>When</t>

          <t><list style="symbols">
              <t>The count of packets with the same Burst Sequence Number
              equals the agreed Burst Length, OR</t>

              <t>The agreed Timeout expires (computed by a the time to the
              "First" Packet Timestamp), OR</t>

              <t>The Burst Sequence Number increases from previous packets
              (indicating a new Burst is in progress),</t>
            </list>then the current burst is determined to be complete.</t>

          <t>When the Burst is complete, the Session-Reflector SHALL terminate
          the current burst processing as described above and send the Burst
          Measurement Response Packet to the Session-Sender as immediately as
          possible.</t>

          <t>In Accumulated Response, the Burst Measurement Response Packet is
          a single packet with the concatenation of all previously-generated
          response packet formats in the information field.</t>
        </section>
      </section>
    </section>

    <section title="Special Case of One-packet Bursts">
      <t>When the Number of Packets field in the Request-TW-Session command
      equals 1, then the Burst Generation and Measurement modes are reduced to
      test sessions with controlled, asymmetrical packet sizes. A minimal size
      packet travels in one direction, and the measured direction uses a
      packet with all Packet Padding specified in the Request-TW-Session
      command.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>These extended modes of operation do not appear to permit any new
      attacks on hosts communicating with core TWAMP <xref
      target="RFC5357"/>.</t>

      <t>The security considerations that apply to any active measurement of
      live networks are relevant here as well. See <xref target="RFC4656"/>
      and <xref target="RFC5357"/>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo adds two modes to the IANA registry for the TWAMP Modes
      Field, and describes behavior when the new modes are used. This field is
      a recognized extension mechanism for TWAMP.</t>

      <section title="Registry Specification">
        <t>IANA has created a TWAMP-Modes registry (as requested in <xref
        target="RFC5618"/>). TWAMP-Modes are specified in TWAMP Server
        Greeting messages and Set-up Response messages, as described in
        section 3.1 of <xref target="RFC5357"/>, consistent with section 3.1
        of <xref target="RFC4656"/>, and extended by this memo. 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, we expect
        that new features will be assigned increasing registry values that
        correspond to single bit positions, unless there is a good reason to
        do otherwise (more complex encoding than single bit positions may be
        used in the future, to access the 2^32 value space).</t>
      </section>

      <section title="Registry Contents">
        <t>TWAMP Modes Registry is recommended to be augmented as
        follows:<figure>
            <preamble/>

            <artwork><![CDATA[Value  Description             Semantics Definition
--------------------------------------------------------
xxx    Burst Generation        this memo, section 3.1
       Capability              new bit position (X)
yyy    Burst Measurement       this memo, section 3.1
                               new bit position (Y)

]]></artwork>

            <postamble/>
          </figure></t>

        <t>&gt;&gt;&gt;IANA: change xxx, yyy, X, Y, and RFC???? to the
        assigned values</t>

        <t>The suggested values are</t>

        <t>X=7, xxx=128</t>

        <t>Y=8, yyy=256 &lt;&lt;&lt;&lt;</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank Chistofer Flinta for review and comment.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.1305'?>

      <?rfc include='reference.RFC.5618'?>

      <?rfc include='reference.RFC.5938'?>

      <?rfc include='reference.RFC.6038'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.morton-ippm-lmap-path'?>

      <?rfc include='reference.I-D.ietf-ippm-rate-problem'?>
    </references>
  </back>
</rfc>
