[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                          A. Morton
Internet-Draft                                             L. Ciavattone
Updates: 5357 (if approved)                                    AT&T Labs
Intended status: Standards Track                       February 21, 2013
Expires: August 25, 2013


                 TWAMP Burst Rate Measurement Features
                    draft-morton-ippm-twamp-rate-03

Abstract

   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 TCP transport instead of UDP may be desirable, but
   is deferred for future work.

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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 25, 2013.

Copyright Notice



Morton & Ciavattone      Expires August 25, 2013                [Page 1]


Internet-Draft              Burst Rate & Size              February 2013


   Copyright (c) 2013 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Alternate Transport Protocol Selection . . . . . . . . . .  4
   2.  Purpose and Scope  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  TWAMP Control Extensions . . . . . . . . . . . . . . . . . . .  6
     3.1.  Connection Setup with New Features . . . . . . . . . . . .  6
     3.2.  Burst Generation: Request-TW-Session Packet Format . . . .  6
     3.3.  Burst Measurement: Request-TW-Session Packet Format  . . .  8
     3.4.  Burst Gen and Meas: Accept Session Packet Format . . . . .  9
     3.5.  Burst Gen and Meas: Stopping Test Sessions . . . . . . . .  9
     3.6.  Additional considerations  . . . . . . . . . . . . . . . .  9
   4.  Burst Generation in TWAMP Test . . . . . . . . . . . . . . . . 10
     4.1.  Sender Behavior  . . . . . . . . . . . . . . . . . . . . . 10
       4.1.1.  Packet Timings . . . . . . . . . . . . . . . . . . . . 10
       4.1.2.  Packet Formats and Contents  . . . . . . . . . . . . . 10
     4.2.  Reflector Behavior . . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  Session-Reflector Burst Packet Format and Contents . . 11
   5.  Burst Measurement in TWAMP Test  . . . . . . . . . . . . . . . 13
     5.1.  Sender Behavior  . . . . . . . . . . . . . . . . . . . . . 13
       5.1.1.  Packet Timings . . . . . . . . . . . . . . . . . . . . 13
       5.1.2.  Packet Formats and Contents  . . . . . . . . . . . . . 13
     5.2.  Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14
       5.2.1.  Session-Reflector Burst Measurement Response
               Packet Format and Contents . . . . . . . . . . . . . . 15
   6.  Special Case of One-packet Bursts  . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Registry Specification . . . . . . . . . . . . . . . . . . 17
     8.2.  Registry Contents  . . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 19



Morton & Ciavattone      Expires August 25, 2013                [Page 2]


Internet-Draft              Burst Rate & Size              February 2013


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19


















































Morton & Ciavattone      Expires August 25, 2013                [Page 3]


Internet-Draft              Burst Rate & Size              February 2013


1.  Introduction

   TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an
   extension of the One-way Active Measurement Protocol, OWAMP
   [RFC4656].  The TWAMP specification gathered wide review as it was
   deployed, resulting in recommendations for new features.

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

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

   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.

   Both features add the ability to control packet size in each
   direction, enabling asymmetrical packet size testing.  Although TWAMP
   [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.

   This memo is an update to the TWAMP core protocol specified in
   [RFC5357].  Measurement systems are not required to implement the
   features described in this memo to claim compliance with [RFC5357].

   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 [RFC4656].

1.1.  Alternate Transport Protocol Selection

   An open question in the IPPM problem statement draft
   [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.

   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.



Morton & Ciavattone      Expires August 25, 2013                [Page 4]


Internet-Draft              Burst Rate & Size              February 2013


2.  Purpose and Scope

   The purpose of this memo is to define two OPTIONAL closely-related
   features for TWAMP [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.

   This memo is intended to satisfy key requirements contianed in the
   IPPM problem statement [I-D.ietf-ippm-rate-problem].  Referring to
   the reference path defined in [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.

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

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

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

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

   This memo extends the modes of operation through assignment of two
   new values in the Modes Field (see section 3.1 of[RFC4656] for the
   format of the Server Greeting message), while retaining backward
   compatibility with the core TWAMP [RFC5357] implementations.  The two
   new values correspond to the two features defined in this memo.

   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



Morton & Ciavattone      Expires August 25, 2013                [Page 5]


Internet-Draft              Burst Rate & Size              February 2013


   MUST all conform to the requirements of that mode, as identified
   below.

   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.


3.  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.  The following sections describe two
   such extensions.

3.1.  Connection Setup with New Features

   TWAMP connection establishment follows the procedure defined in
   section 3.1 of [RFC4656] and section 3.1 of [RFC5357].  The new
   features require two new bit positions (and values).  See the IANA
   section for details on the assigned values and bit positions.

   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.

   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.

3.2.  Burst Generation: Request-TW-Session Packet Format

   The bits designated for the Burst Generation feature in the Request-
   TW-Session command are as shown in the packet format below.











Morton & Ciavattone      Expires August 25, 2013                [Page 6]


Internet-Draft              Burst Rate & Size              February 2013


    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)                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * = re-interpreted field

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

   1.  Number of Packets: In this mode, re-interpreted as the number of
       packets that the Session-Reflector MUST generate in each Burst.

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



Morton & Ciavattone      Expires August 25, 2013                [Page 7]


Internet-Draft              Burst Rate & Size              February 2013


3.3.  Burst Measurement: Request-TW-Session Packet Format

   The bits designated for the Burst Generation feature in the Request-
   TW-Session command are as shown in the packet format below.

    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)                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * = re-interpreted field

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

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




Morton & Ciavattone      Expires August 25, 2013                [Page 8]


Internet-Draft              Burst Rate & Size              February 2013


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

3.4.  Burst Gen and Meas: Accept Session Packet Format

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

    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)                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


3.5.  Burst Gen and Meas: Stopping Test Sessions

   The Control-Client SHALL stop in-progress test sessions using any
   standardized methods, including section 3.8 of [RFC5357] or the
   optional capability of [RFC5938].

3.6.  Additional considerations

   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.

   We note that Burst Generation and Measurement features are
   incompatible with each other, and with the Symmetrical Size feature



Morton & Ciavattone      Expires August 25, 2013                [Page 9]


Internet-Draft              Burst Rate & Size              February 2013


   described in [RFC6038], and MUST NOT be used in combination with
   those features.

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


4.  Burst Generation in TWAMP Test

   The TWAMP test protocol is similar to the OWAMP [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[RFC5357].  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.

4.1.  Sender Behavior

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

4.1.1.  Packet Timings

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

4.1.2.  Packet Formats and Contents

   The Session-Sender packet format and content follow the same
   procedure and guidelines as defined in section 4.1.2 of [RFC4656] (as
   indicated in section 4.1.2 of TWAMP [RFC5357]).

   This mode uses the original TWAMP-Test Packet Padding Field (see
   section 4.1.2 of [RFC4656]), or can be used with Reflect Octets
   feature as shown below for unauthenticated mode:










Morton & Ciavattone      Expires August 25, 2013               [Page 10]


Internet-Draft              Burst Rate & Size              February 2013


    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                    .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Burst Initiation Packet Format

   The Sequence Number, Timestamp, and Error Estimate fields are the
   same as specified in section 4.1.2 of [RFC4656] in OWAMP.

   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.

4.2.  Reflector Behavior

   The TWAMP Reflector differs significantly from the procedures and
   guidelines in section 4.2 of [RFC5357].  The following new functions
   MUST be performed:

   o  Recognition of the function of the Burst Initiation Packet used in
      this mode.

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

4.2.1.  Session-Reflector Burst Packet Format and Contents

   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):



Morton & Ciavattone      Expires August 25, 2013               [Page 11]


Internet-Draft              Burst Rate & Size              February 2013


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

   Section 4.2.1 of [RFC5357] describes the above fields as used in
   TWAMP, with one exception.

   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.

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

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



Morton & Ciavattone      Expires August 25, 2013               [Page 12]


Internet-Draft              Burst Rate & Size              February 2013


   In any case, the Session-Reflector MAY re-use the Sender's Packet
   Padding (since the requirements for padding generation are the same
   for each) when possible.

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


5.  Burst Measurement in TWAMP Test

   The Burst Measurement feature modifies the behavior of TWAMP section
   4[RFC5357].  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.

5.1.  Sender Behavior

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

5.1.1.  Packet Timings

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

5.1.2.  Packet Formats and Contents

   The Session-Sender packet format and content SHALL comply with that
   defined in section 4.1.2 of [RFC4656] (as indicated in section 4.1.2
   of TWAMP [RFC5357]).

   This mode uses the original TWAMP-Test Packet Padding Field (see
   section 4.1.2 of [RFC4656]), or can be used with Reflect Octets
   feature as shown below for unauthenticated mode:










Morton & Ciavattone      Expires August 25, 2013               [Page 13]


Internet-Draft              Burst Rate & Size              February 2013


      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                    .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Session-Sender Burst Test Packet Format

   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.

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

5.2.  Reflector Behavior

   The TWAMP Reflector differs slightly from the procedures and
   guidelines in section 4.2 of [RFC5357].  The following new functions
   MUST be performed:

   o  Recognition of the function of the Session-Sender Burst Test
      Packet Format used in this mode.

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

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

   o  OR - Response with the new Burst Measurement Response packet
      described below.  For discussion, we will call this the



Morton & Ciavattone      Expires August 25, 2013               [Page 14]


Internet-Draft              Burst Rate & Size              February 2013


      accumulated response.

   We seek feedback from the IPPM working group on which of these two
   alternatives is preferable.

5.2.1.  Session-Reflector Burst Measurement Response Packet Format and
        Contents

   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):

      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
   Session-Reflector Measurement Packet (1-to-1 response)

   Section 4.2.1 of [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.

   All Timestamps SHALL be formatted according to the precedent set in
   section 4.1.2 of [RFC4656], which is to use [RFC1305] (and updated



Morton & Ciavattone      Expires August 25, 2013               [Page 15]


Internet-Draft              Burst Rate & Size              February 2013


   version), as follows:

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

   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's Packet Padding (since the
   requirements for padding generation are the same for each) to reach a
   word boundary.

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

   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.

   ========================================================

   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.

   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.

   As subsequent packets arrive, Session-Reflector SHALL:

   o  Maintain a count of packets with the same Burst Sequence Number
      (one burst).

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

   When

   o  The count of packets with the same Burst Sequence Number equals
      the agreed Burst Length, OR

   o  The agreed Timeout expires (computed by a the time to the "First"
      Packet Timestamp), OR




Morton & Ciavattone      Expires August 25, 2013               [Page 16]


Internet-Draft              Burst Rate & Size              February 2013


   o  The Burst Sequence Number increases from previous packets
      (indicating a new Burst is in progress),

   then the current burst is determined to be complete.

   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.

   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.


6.  Special Case of One-packet Bursts

   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.


7.  Security Considerations

   These extended modes of operation do not appear to permit any new
   attacks on hosts communicating with core TWAMP [RFC5357].

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


8.  IANA Considerations

   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.

8.1.  Registry Specification

   IANA has created a TWAMP-Modes registry (as requested in [RFC5618]).
   TWAMP-Modes are specified in TWAMP Server Greeting messages and
   Set-up Response messages, as described in section 3.1 of [RFC5357],
   consistent with section 3.1 of [RFC4656], and extended by this memo.
   Modes are indicated by setting bits in the 32-bit Modes field that



Morton & Ciavattone      Expires August 25, 2013               [Page 17]


Internet-Draft              Burst Rate & Size              February 2013


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

8.2.  Registry Contents

   TWAMP Modes Registry is recommended to be augmented as follows:

   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)


   >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values

   The suggested values are

   X=7, xxx=128

   Y=8, yyy=256 <<<<


9.  Acknowledgements

   The authors thank Chistofer Flinta for review and comment.


10.  References

10.1.  Normative References

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

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

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.



Morton & Ciavattone      Expires August 25, 2013               [Page 18]


Internet-Draft              Burst Rate & Size              February 2013


              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, October 2008.

   [RFC5618]  Morton, A. and K. Hedayat, "Mixed Security Mode for the
              Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
              August 2009.

   [RFC5938]  Morton, A. and M. Chiba, "Individual Session Control
              Feature for the Two-Way Active Measurement Protocol
              (TWAMP)", RFC 5938, August 2010.

   [RFC6038]  Morton, A. and L. Ciavattone, "Two-Way Active Measurement
              Protocol (TWAMP) Reflect Octets and Symmetrical Size
              Features", RFC 6038, October 2010.

10.2.  Informative References

   [I-D.ietf-ippm-rate-problem]
              Morton, A., "Rate Measurement Test Protocol Problem
              Statement", draft-ietf-ippm-rate-problem-02 (work in
              progress), February 2013.

   [I-D.morton-ippm-lmap-path]
              Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
              A. Morton, "A Reference Path and Measurement Points for
              LMAP", draft-morton-ippm-lmap-path-00 (work in progress),
              January 2013.


Authors' Addresses

   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748
   USA

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   Email: acmorton@att.com
   URI:   http://home.comcast.net/~acmacm/










Morton & Ciavattone      Expires August 25, 2013               [Page 19]


Internet-Draft              Burst Rate & Size              February 2013


   Len Ciavattone
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748
   USA

   Phone: +1 732 420 1239
   Fax:
   Email: lencia@att.com
   URI:









































Morton & Ciavattone      Expires August 25, 2013               [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/