One document matched: draft-morton-ippm-twamp-reflect-padding-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-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&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&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>| PAFTECH AB 2003-2026 | 2026-04-24 05:56:27 |