<?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-reflect-padding-00"
     ipr="full3978">
  <front>
    <title abbrev="TWAMP Reflect Padding">TWAMP Reflect Padding
    Feature</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></facsimile>

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

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

    <date day="6" month="July" year="2008" />

    <abstract>
      <t>The IETF is completing its work on TWAMP - the Two-Way Active
      Measurement Protocol. This memo describes a proposed feature for TWAMP,
      intended for discussion in the IP Performance Metrics WG. The feature
      gives the reflector the ability to return some of the packet padding
      bits to the sender.</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>The IETF is completing its work on TWAMP - the Two-Way Active
      Measurement Protocol <xref target="I-D.ietf-ippm-twamp"></xref>, which
      is an extension to the One-way Active Measurement Protocol, OWAMP <xref
      target="RFC4656"></xref>.</t>

      <t>This memo describes a new proposed feature for TWAMP, so it can be
      discussed and interest to take-up the feature assessed. This feature
      adds the capability for the Session-Reflector to return a limited number
      of unassigned (padding) bits to the Server/Session-Sender. With this
      capability, the Control-Client/Session-Sender can information it deems
      useful and have the assurance that the corresponding test packet will
      contain the information when it is returned.</t>

      <t>The relationship between this memo and TWAMP is intended to be an
      update to the TWAMP RFC when published.</t>
    </section>

    <section title="Purpose and Scope">
      <t>The purpose of this memo is to describe an additional function and
      feature for TWAMP <xref target="I-D.ietf-ippm-twamp"></xref>. The
      feature needs a clear description so it can be discussed and (hopefully)
      adopted in the IP Performance Metrics Charter.</t>

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

      <t><list style="numbers">
          <t>Extension of the modes of operation through assignment of new
          values in the Mode field (see section 3.1 of <xref
          target="RFC4656"></xref>), while retaining backward compatibility
          with TWAMP <xref target="I-D.ietf-ippm-twamp"></xref>
          implementations. These values identify the ability of the
          Server/Session-Reflector to reflect specific octets of Packet
          Padding back to the Client/Sender. The motivation for this extension
          is to permit the Sender to tag packets with a index for simplified
          identification, or other uses.</t>
        </list>(other items may be added)</t>

      <t>When new features are discussed and reach consensus, they may become
      chartered work items in IETF IPPM (and may appear in a different
      memo).</t>
    </section>

    <section title="TWAMP Control Extensions">
      <t>TWAMP-Control protocol is a derivative of the OWAMP-Control protocol,
      and provides two-way measurement capability. TWAMP <xref
      target="I-D.ietf-ippm-twamp"></xref> uses the Mode field to identify and
      select specific communication capabilities, and this field is a
      recognized extension mechanism. The following sections describe one such
      extension.</t>

      <section title="Connection Setup with Reflect Padding Feature">
        <t>TWAMP connection establishment follows the procedure defined in
        section 3.1 of <xref target="RFC4656"></xref>. The Reflect Padding
        feature requires two new bit positions (and values) to identify the
        ability of the Server/Session-Reflector to reflect specific octets of
        Packet Padding back to the Client/Sender. With this added feature, the
        complete set of TWAMP mode values would be as follows:</t>

        <t><figure>
            <preamble></preamble>

            <artwork><![CDATA[Value  Description             Reference/Explanation
0      Reserved
1      Unauthenticated         RFC4656, Section 3.1
2      Authenticated           RFC4656, Section 3.1
4      Encrypted               RFC4656, Section 3.1
8      Unauth. TEST protocol,  draft-...-more-twamp (3)
       Auth. CONTROL 
16     Unauth. TEST protocol,  draft-...-more-twamp (4)
       Encrypted CONTROL 
32     Auth. TEST protocol,    draft-...-more-twamp (5)
       Encrypted CONTROL 
--------------------------------------------------------
xx     Reflect Padding         new bit position (X)
       Capability
yyy    Reflect & Operate       new bit position (Y)
       on Padding Bits

]]></artwork>

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

        <t>In the original OWAMP mode field, setting bit positions 0, 1 or 2
        indicated the security mode of the Control protocol, and the Test
        protocol inherited the same mode (see section 4 of <xref
        target="RFC4656"></xref>). In the <xref
        target="I-D.morton-ippm-more-twamp"></xref> bit positions (3, 4 or 5)
        discontinue the inheritance of the security mode in the Test
        protocol.</t>

        <t>The Server sets one or both of the new bit positions (possibly 6
        and/or 7) in the Server Greeting message to indicate its capabilities
        and willingness to operate in these modes if desired.</t>

        <t>If the Control-Client intends to operate all test sessions under
        this control connection using one of the new modes, it MUST set one of
        mode bits corresponding to that mode in the Setup Response
        message.</t>
      </section>

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

        <t><figure>
            <preamble></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                     |
.
.               ... Many fields not shown ...
.
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Type-P Descriptor                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Padding (to be reflected)   |     MBZ (2 octets)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

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

        <t>The "Packet Padding (to be reflected)" field SHALL be 2 octets
        long, as shown.</t>
      </section>

      <section title="Accept Session Packet Format">
        <t>The bits designated for the Reflect Padding feature in the Accept
        Session command are as shown in the packet format below.</t>

        <t><figure>
            <preamble></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)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Padding (to be reflected)   |     MBZ (2 octets)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (8 octets)                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>

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

        <t>The "Packet Padding (to be reflected)" field SHALL be 2 octets
        long, as shown.</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>If BOTH the above modes are adopted, the last eight bits of the
        Modes 32-bit field are used. The first 24 bits MUST be zero. A client
        conforming to this version of the specification MUST ignore the values
        in the first 24 bits of the Modes value. (This way, the bits are
        available for future protocol extensions.)</t>

        <t>Other ways in which TWAMP extends OWAMP are described in <xref
        target="I-D.ietf-ippm-twamp"></xref>.</t>
      </section>
    </section>

    <section title="Extended TWAMP Test ">
      <t>The TWAMP test protocol is similar to the OWAMP <xref
      target="RFC4656"></xref> test protocol with the exception that the
      Session-Reflector transmits test packets to the Session-Sender in
      response to each test packet it receives. TWAMP <xref
      target="I-D.ietf-ippm-twamp"></xref> section 4 defines two additional
      test packet formats for packets transmitted by the Session-Reflector.
      The appropriate format depends on the security mode chosen. This feature
      utilizes some of the bits within each test packet format.</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 Format and Content">
          <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"></xref> (as indicated in section 4.1.2 of TWAMP
          <xref target="I-D.ietf-ippm-twamp"></xref>).</t>

          <t>The Reflect Padding feature re-designates the packet padding
          field, as shown below for unauthenticated mode:</t>

          <t><figure>
              <preamble></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        |           MBZ                 |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|      MBZ      |       Length (2 oct)          |     Ext ID    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                                                               | 
|                  Packet Padding (to be reflected)             | 
|                                                               | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Additional Packet Padding                    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>

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

          <t>The "Packet Padding (to be reflected)" field MAY be as long as 12
          octets, as shown. IF the test packet length is truncated within this
          field, THEN ALL packet padding MUST be reflected by
          Session-Reflectors using this feature.</t>
        </section>
      </section>

      <section title="Reflector Behavior">
        <t>The TWAMP Reflector follows the procedures and guidelines in
        section 4.2 of <xref target="I-D.ietf-ippm-twamp"></xref>, with the
        following additional functions:</t>

        <t><list style="symbols">
            <t>bits in the packet padding field of the Session-Sender's test
            packet MUST be inserted in the Session-Reflector's test
            packet.</t>
          </list>The Reflect Padding feature re-designates the packet padding
        field, as shown below for unauthenticated mode:</t>

        <t><figure>
            <preamble></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        |           MBZ                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                          Receive Timestamp                    | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                        Sender Sequence Number                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                      Sender Timestamp                         | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |      Sender Error Estimate    |           MBZ                 | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |  Sender TTL   |       Length (2 oct)          |     Ext ID    | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                                                               | 
 |               Packet Padding (from Session-Sender)            | 
 |                                                               | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Additional Packet Padding                    | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ]]></artwork>

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

        <t>The "Packet Padding (to be reflected)" field MAY be as long as 12
        octets, as shown. IF the test packet length is truncated within this
        field, THEN ALL packet padding MUST be reflected by Session-Reflectors
        using this feature.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>These extended modes of operation permit stronger integrity
      protection on the TWAMP-Control protocol while simultaneously
      emphasizing accuracy or efficiency on the TWAMP-Test protocol, thus
      enhancing overall security when compared to the previous options.</t>

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

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo adds two mode combinations to the IANA registry for the
      TWAMP Mode 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="I-D.morton-ippm-more-twamp"></xref>). TWAMP-Modes are
        specified in TWAMP Server Greeting messages and Set-up Response
        messages, as described in section 3.1 of <xref
        target="I-D.ietf-ippm-twamp"></xref>, consistent with section 3.1 of
        <xref target="RFC4656"></xref>, and extended by this memo. Modes are
        indicated by setting bits in the 32-bit Modes field. Thus, this
        registry can contain a total of 32 possible values.</t>
      </section>

      <section title="Registry Management">
        <t>Because the Modes registry can contain only thirty-two values, and
        because TWAMP is an IETF protocol, this registry must be updated only
        by "IETF Consensus" as specified in <xref target="RFC2434"></xref>(an
        RFC documenting registry use that is approved by the IESG). For the
        Modes registry, we expect that new features will be assigned using
        monotonically increasing bit positions and in the range [0-31] and the
        corresponding values, unless there is a good reason to do
        otherwise.</t>
      </section>

      <section title="Experimental Numbers">
        <t>No experimental values are currently assigned for the Modes
        Registry.</t>
      </section>

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

            <artwork><![CDATA[Value  Description             Semantics Definition
0      Reserved

1      Unauthenticated         RFC4656, Section 3.1

2      Authenticated           RFC4656, Section 3.1

4      Encrypted               RFC4656, Section 3.1

8      Unauth. TEST protocol,  draft-...-more-twamp (3)
       Auth. CONTROL 
16     Unauth. TEST protocol,  draft-...-more-twamp (4)
       Encrypted CONTROL 
32     Auth. TEST protocol,    draft-...-more-twamp (5)
       Encrypted CONTROL 
--------------------------------------------------------
xx     Reflect Padding         this memo, section 3.1
       Capability              new bit position (X)
yyy    Reflect & Operate       this memo, section 3.1
       on Padding Bits         new bit position (Y)]]></artwork>

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

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank future readers for helpful review and
      comments.</t>
    </section>
  </middle>

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

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

      <?rfc include='reference.I-D.ietf-ippm-twamp'?>

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

      <?rfc include='reference.I-D.morton-ippm-more-twamp'?>

      <?rfc ?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc ?>

      <reference anchor="x">
        <front>
          <title></title>

          <author fullname="" surname="">
            <organization></organization>
          </author>

          <date month="" year="" />
        </front>
      </reference>
    </references>
  </back>
</rfc>