One document matched: draft-ietf-ippm-owamp-registry-00.xml
<?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-ietf-ippm-owamp-registry-00"
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&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="24" 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>
| PAFTECH AB 2003-2026 | 2026-04-24 13:59:44 |