<?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-tcp-00" ipr="trust200902"
     updates="5357">
  <front>
    <title abbrev="TWAMP TCP Connection">TWAMP Control of a TCP
    Connection</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>

    <date day="15" month="July" year="2013"/>

    <abstract>
      <t>This memo describes a feature for the core specification of TWAMP -
      the Two-Way Active Measurement Protocol: an optional capability where a
      TCP connection can be coordinated between two participating hosts. The
      feature includes the ability to control TCP configuration settings and
      byte stream characteristics, enabling diagnostic testing.</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>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 memo describes a feature for the core specification of TWAMP -
      the Two-Way Active Measurement Protocol: an optional capability where a
      TCP connection can be coordinated between two participating hosts. The
      feature includes the ability to control TCP configuration settings and
      byte stream characteristics, enabling diagnostic testing.</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>TWAMP was selected to host the TCP Connection feature because OWAMP
      <xref target="RFC4656"/> was not extended to use the Mixed Security
      mode, and this is a distinct advantage in testing.</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>

    <section title="Purpose and Scope">
      <t>The purpose of this memo is to define an OPTIONAL feature for TWAMP
      <xref target="RFC5357"/>. The feature controls capability to setup a TCP
      connection and coordinate the configuration details of that connection
      between the test sender and the reflector hosts.</t>

      <t>This memo is intended to satisfy key requirements contained 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).</t>

      <t>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 roles (connection initiator or connection listener) defined in this
      memo.</t>

      <t>When the Server and Control-Client have agreed to use one of the TCP
      Connection modes 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 below for details on the assigned
        values and bit positions.</t>

        <t>The Server sets one or both of the TCP Connection bit positions in
        the Modes Field of the Server Greeting message to indicate its
        capabilities and willingness to operate in either of these modes
        (connection initiator or connection listener) 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 *compatible* extensions, the
        Control-Client MAY set multiple Mode Field bits in the Setup Response
        message. The TCP Connection features are mutually exclusive, and MUST
        NOT be used together.</t>

        <t>The following Mode settings are compatible with either TCP
        Connection Mode:<list style="symbols">
            <t>Unauthenticated mode (value 1)</t>

            <t>Unauthenticated TEST protocol, Encrypted CONTROL (value 8)</t>
          </list></t>

        <t>The latter is referred to as the Mixed Security Mode.</t>

        <t>The function of Integrity Protections and Values of the Accept
        Field (sections 3.2 and 3.3 of <xref target="RFC5357"/>) remain as
        described.</t>
      </section>

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

        <t>This is a new command, designated by the TWAMP-Control Command
        Number XX (where XX will be assigned by IANA).</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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     XX        |  MBZ  | IPVN  |            MBZ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

.                                                               .
.         ... Many fields (?? octets) not formatted ...         .
.                                                               .
Session ID (SID)
Initiator Address (v4 or v6)
Initiator Port
Listener Address (v4 or v6)
Listener Port
TCP Configuration Fields (for Initiator and Listener)
  (such as Max Advertised Sender Window,
           Initial Window,
           MSS (recommended)
           Congestion Control (selection from a list?)
           
Stream Configuration Fields (for Initiator and Listener)
  (such as Length of PDU to write,
           Number of PDUs to write,
           Max Duration of the TCP connection

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Type-P Descriptor                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

            <postamble>field formatting is TBD</postamble>
          </figure></t>

        <t/>
      </section>

      <section title="TCP Connection: Accept Session Packet Format">
        <t>The Accept Session command for the TCP Connection feature is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Accept     |      MBZ      |            Port               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                                                               |
|                        SID (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (4 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (8 octets)                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 octets)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>

            <postamble/>
          </figure>If a TWAMP Server receives an unrecognized command number,
        it MUST respond with the Accept field = 3 in the Accept-Session
        message. The augmented Accept Field values are listed below.<list
            style="symbols">
            <t>0 = OK (Accept the session)</t>

            <t>1 = Failure, reason unspecified</t>

            <t>2 = Internal Error</t>

            <t>3 = Some aspect of the request is not supported</t>

            <t>4 = Cannot perform request due to permanent resource
            limitations</t>

            <t>5 = Cannot perform request due to temporary resource
            limitations</t>

            <t>6 = Requested Port Not Available</t>

            <t>7 = Requested Address Not Available</t>
          </list></t>

        <t>All other values are reserved for future use. Reception of a
        non-designated value MUST be interpreted as 1 = Failure.</t>
      </section>

      <section title="Stopping Test Sessions">
        <t>The Control-Client SHALL stop in-progress test sessions using
        standardized methods, section 3.8 of <xref target="RFC5357"/>.</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>With the publication of this memo as an RFC, the last ?? 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="TWAMP Test for TCP Connection Feature">
      <t>This section will include additional considerations for the TCP
      Connection Initiator and Listener, once a session has been requested and
      accepted.</t>

      <section title="Initiater Behavior">
        <t>This section describes extensions to the behavior of the TWAMP TCP
        Initiator.</t>
      </section>

      <section title="Listener Behavior">
        <t>The TWAMP TCP Listener</t>
      </section>
    </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="Modes Registry Contents">
        <t>TWAMP Modes Registry is recommended to be augmented as
        follows:<figure>
            <preamble/>

            <artwork><![CDATA[Value  Description             Semantics Definition
--------------------------------------------------------
xxx    TCP Connection         this memo, section 3.1
       Initiator              new bit position (X)
yyy    TCP Connection         this memo, section 3.1
       Listener               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=?, xxx=???</t>

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

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

            <artwork><![CDATA[Value  Description             Semantics Definition
--------------------------------------------------------
XX     TCP Connection          this memo, section 3.2

]]></artwork>

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

        <t>&gt;&gt;&gt;IANA: change XX to the assigned values</t>

        <t>The suggested values are</t>

        <t>XX=11, &lt;&lt;&lt;&lt;</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The author will complete this section as appropriate.</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>
