<?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-owamp-registry-01"
     ipr="pre5378Trust200902" updates="4656">
  <front>
    <title abbrev="TWAMP Extensions">Registries for the One-Way Active
    Measurement Protocol - OWAMP</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="6" month="July" year="2015"/>

    <abstract>
      <t>This memo describes the registries for OWAMP - the One-Way Active
      Measurement Protocol. The registries allow assignment of MODE bit
      positions and OWAMP Command numbers. The memo also requests that IANA
      establish the registries for new features, called the OWAMP-Modes
      registry and the OWAMP Control Command Number registry.</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 One-way Active Measurement Protocol, OWAMP <xref
      target="RFC4656"/> was prepared to support measurements of metrics
      specified by the IP Performance Metrics (IPPM) working group in the
      IETF. The Two-Way Active Measurement Protocol, TWAMP <xref
      target="RFC5357"/> is an extension of OWAMP. The TWAMP specification
      gathered wide review as it approached completion, and the by-products
      were several recommendations for new features in TWAMP. As a result, a
      registry of new features was established for TWAMP. However, there were
      no new features proposed for OWAMP until recently.</t>

      <t>This memo establishes the needed registries for OWAMP, and updates
      <xref target="RFC4656"/>.</t>
    </section>

    <section title="Purpose and Scope">
      <t>The purpose and scope of this memo is to describe and request the
      establishment of registries for future OWAMP <xref target="RFC4656"/>
      extensions. IANA already administrates the "Two-way Active Measurement
      Protocol (TWAMP) Parameters", and this request follows a similar form
      (with one exception identified below).</t>

      <t>This memo also provides the initial contents for the registries.</t>
    </section>

    <section title="IANA Considerations for OWAMP Control Registries">
      <t>OWAMP-Control protocol coordinates the measurement capability. All
      OWAMP-Control messages follow specifications defined in section 3 of
      <xref target="RFC4656"/>.</t>

      <section title="Control Command Number Registry">
        <t>IANA is requested to create a OWAMP-Control Command Number
        registry.</t>

        <t>OWAMP-Control Commands follow specifications defined in section 3.4
        of <xref target="RFC4656"/>.</t>

        <section title="Registry Specification">
          <t>OWAMP-Control Commands Numbers are specified in the first octet
          of OWAMP-Control-Client command messages consistent with section 3
          of <xref target="RFC4656"/>. There are a maximum of 256 command
          numbers.</t>
        </section>

        <section title="Registry Management">
          <t>Because the "OWAMP-Control Command Numbers" registry can contain
          only 256 values, and because OWAMP is an IETF protocol, these
          registries must be updated only by "IETF Consensus" as specified in
          <xref target="RFC5226"/> (an RFC that documents registry use and is
          approved by the IESG).</t>
        </section>

        <section title="Experimental Numbers">
          <t>One experimental value is currently assigned in the Command
          Numbers Registry, as indicated in the initial contents below.</t>
        </section>

        <section title="OWAMP-Control Command Numbers Initial Contents">
          <t>OWAMP-Control Commands follows the procedure defined in section
          3.5 of <xref target="RFC4656"/> (and in the remainder of section
          3).</t>

          <t>The complete set of OWAMP-Control Command Numbers are as follows
          (including one reserved bit position):</t>

          <t><figure>
              <preamble/>

              <artwork><![CDATA[   OWAMP-Control Command Numbers Registry

   Value  Description             Semantics Definition
    0      Reserved
    1      Request-Session         RFC 4656, Section 3.5
    2      Start-Sessions          RFC 4656, Section 3.7
    3      Stop-Sessions           RFC 4656, Section 3.8
    4      Fetch-Sessions          RFC 4656, Section 3.9
    5      Experimentation         This Memo
    6-255  Unassigned
       
]]></artwork>

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

          <t/>
        </section>
      </section>

      <section title="OWAMP-Modes">
        <t>IANA is requested to create a OWAMP-Modes registry.</t>

        <section title="Registry Specification">
          <t>OWAMP-Modes are specified in OWAMP Server Greeting messages and
          Set-up Response messages consistent with section 3.1 of <xref
          target="RFC4656"/>. Modes are currently indicated by setting single
          bits in the 32-bit Modes Field. However, more complex encoding may
          be used in the future.</t>
        </section>

        <section title="Registry Management">
          <t>Because the "OWAMP-Modes" are based on only 32 bit positions with
          each position conveying a unique feature, and because TWAMP is an
          IETF protocol, these registries must be updated only by "IETF
          Consensus" as specified in <xref target="RFC5226"/> (an RFC that
          documents registry use and is approved by the IESG).</t>
        </section>

        <section title="Experimental Numbers">
          <t>No experimental bit positions are currently assigned in the Modes
          Registry, as indicated in the initial contents below.</t>
        </section>

        <section title="OWAMP-Modes Initial Contents">
          <t>OWAMP-Control connection establishment follows the procedure
          defined in section 3.1 of <xref target="RFC4656"/>.</t>

          <t>In the OWAMP-Modes registry, assignments are straightforward on
          the basis of bit positions, and there are no references to values -
          this is a difference from the comparable TWAMP registry (and a topic
          for improvement in the TWAMP-Modes registry).</t>

          <t>An Extension of the OWAMP-Modes is proposed in <xref
          target="I-D.ietf-ippm-ipsec"/>. With this extension, the complete
          set of OWAMP Mode bit positions are as follows (including one
          reserved bit position):</t>

          <t><figure>
              <preamble/>

              <artwork><![CDATA[OWAMP-Modes Registry

Bit
Posit.  Description            Reference/Explanation
0      Unauthenticated         RFC4656, Section 3.1
1      Authenticated           RFC4656, Section 3.1
2      Encrypted               RFC4656, Section 3.1
3      Reserved                bit position (3)
4      IKEv2-derived Shared    RFC_TBD and this memo
       Secret Key              new bit position (4)
5-31   Unassigned
       
]]></artwork>

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

          <t>In the original OWAMP and TWAMP Modes field, setting bit position
          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"/>).</t>

          <t>The value of the Modes Field sent by the Server in the
          Server-Greeting message is the bit-wise OR of the modes (bit
          positions) that it is willing to support during this session. Thus,
          the last four bits of the Modes 32-bit Field are used. When no other
          features are activated, the first 28 bits MUST be zero. A client
          conforming to this extension of <xref target="RFC5357"/> MAY ignore
          the values in the first 28 bits of the Modes Field, or it MAY
          support other features that are communicated in these bit
          positions.</t>

          <t>OWAMP and TWAMP registries for Modes may grow to contain
          different features and functions due to the inherent differences in
          one-way and two-way measurement configurations and the metrics they
          measure. No attempt will be made to coordinate them unnecessarily,
          except the Reserved bit position 3 above. This is available for
          assignment if a mixed security mode <xref target="RFC5618"/> is
          defined for OWAMP, and would allow alignment with the comparable
          TWAMP feature.</t>
        </section>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>As this memo simply requests creation of a registry, it presents no
      new security or privacy issues for the Internet.</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>

      <t>Privacy considerations for measurement systems, particularly when
      Internet users participate in the tests in some way, are described in
      <xref target="I-D.ietf-lmap-framework"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The author would like to thank Kostas Pentikousis, Nalini Elkins, and
      Mike Ackermann for insightful reviews and comments.</t>
    </section>
  </middle>

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-ippm-ipsec'?>

      <?rfc include='reference.I-D.ietf-lmap-framework'?>

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