One document matched: draft-morton-ippm-twamp-rate-05.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-rate-05"
ipr="trust200902" updates="5357">
<front>
<title abbrev="Burst Rate & Size">TWAMP Burst Rate Measurement
Features</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/>
<email>lencia@att.com</email>
<uri/>
</address>
</author>
<date day="13" month="February" year="2014"/>
<abstract>
<t>This memo describes two rate-measurement features for the core
specification of TWAMP - the Two-Way Active Measurement Protocol: an
optional capability where the reflector host responds with a controlled
burst of test-session packets (instead of a single packet), and an
optional test mode that requires the responder to measure a burst of
test packets and communicate the results in truncated packet(s). Both
features add the ability to control packet size in the tested direction,
enabling asymmetrical packet size testing. This draft defines the modes
in terms of traditional UDP test packets. Use of TCP transport instead
of UDP may be desirable, but is deferred to other work.</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>This memo describes two closely-related features for TWAMP. When
measuring packet delivery rate to end-systems, unique control and
measurement capabilities become useful, especially when the path tested
includes asymmetrical link speeds (as are often deployed in consumer
Internet access services).</t>
<t>One feature is the OPTIONAL capability for the responder host to
return a controlled burst of test-session packets (instead of a single
packet).</t>
<t>Another is an optional sender packet format that requires the
responder to measure a burst of test packets and communicate the results
in a single packet.</t>
<t>Both features add the ability to control packet size in each
direction, enabling asymmetrical packet size testing. Although TWAMP
<xref target="RFC5357"/> recommends padding truncation to achieve
symmetrical sizes (to compensate for the Session-Reflector's larger test
packet header), these features configure test packet sizes when the test
session is requested using the TWAMP-Control protocol.</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>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 title="Alternate Transport Protocol Selection">
<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 is clearly a topic where coordination is required between the
testing sender and receiver devices. It could be specified as an
independent TWAMP feature, and although it is clearly related to the
features described here, the work is deferred to a future memo.</t>
</section>
</section>
<section title="Purpose and Scope">
<t>The purpose of this memo is to define two OPTIONAL closely-related
features for TWAMP <xref target="RFC5357"/>. The features enhance the
TWAMP responder's capabilities to perform a simple operations on test
packets, and the capability to demand asymmetrical size TWAMP-Test
packets.</t>
<t>This memo is intended to satisfy key requirements contianed 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). The requirements of this testing environment
make it difficult to "correctly" generate fixed rate packet ensembles.
Some of the devices doing the generation and/or measurement were
designed for low-cost-large-scale deployment and primarily for a purpose
other than measurement.</t>
<t>The scope of the memo is limited to specifications of the following
features:</t>
<t><list style="symbols">
<t>Burst Generation: the capability of the Session-Reflector to
generate a burst of packets for return to the Session-Sender, and
the corresponding TWAMP-Control messages to activate the capability
between compliant hosts.</t>
<t>Burst Measurement: the capability of the Session-Reflector to
measure a burst of packets from the Session-Sender, report the key
information (receive timestamps) in the response packet(s), and the
corresponding TWAMP-Control messages to activate the capability
between compliant hosts.</t>
<t>Asymmetrical Size: the capability to ensure that TWAMP-Test
protocol uses a specific packet size in each direction. This feature
is combined with the Burst features, and essentially adds a third
simple capability when the Burst size = 1.</t>
</list>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 features defined in this memo.</t>
<t>When the Server and Control-Client have agreed to use the Burst
Generation mode 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>
<t>When the Server and Control-Client have agreed to use the Burst
Measurement mode 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 for details on the assigned values
and bit positions.</t>
<t>The Server sets one or both of the new bit positions in the Modes
Field of the Server Greeting message to indicate its capabilities and
willingness to operate in either of these modes 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 extensions, the Control-Client
MAY set multiple Mode Field bits in the Setup Response message, but
these new features are mutually exclusive, and MUST NOT be used
together.</t>
</section>
<section title="Burst Generation: Request-TW-Session Packet Format">
<t>The bits designated for the Burst Generation feature in the
Request-TW-Session command are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. ... Many fields (62 octets) not shown ... .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length* (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octets to be reflected | Length of padding to reflect |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>* = re-interpreted field</postamble>
</figure></t>
<t>Two re-interpreted fields appear in the Request-TW-Session command
when using Burst Generation mode:</t>
<t><list style="numbers">
<t>Number of Packets: In this mode, re-interpreted as the number
of packets that the Session-Reflector MUST generate in each
Burst.</t>
<t>Packet Padding Length: In the mode, re-interpreted as the
number of octets the Session-Reflector MUST append to the Test
packet header of each packet it generates as part of the burst.
The Session-Reflector MUST NOT assume that the Session-Sender will
use any packet padding, and MUST be prepared to generate the
padding itself.</t>
</list></t>
</section>
<section title="Burst Measurement: Request-TW-Session Packet Format">
<t>The bits designated for the Burst Generation feature in the
Request-TW-Session command are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. ... Many fields (62 octets) not shown ... .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout*, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octets to be reflected | Length of padding to reflect |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>* = re-interpreted field</postamble>
</figure></t>
<t>Two re-interpreted fields appear in the Request-TW-Session command
when using Burst Measurement mode:</t>
<t><list style="numbers">
<t>Number of Packets: In this mode, re-interpreted as the number
of packets that the Session-Reflector MUST expect to measure as
part of each Burst.</t>
<t>Timeout: In this mode, re-interpreted as the time to wait for
all packets in a burst to arrive, expressed in the existing
timestamp format used in TWAMP and OWAMP. In the case of lost
packets, the Session-Reflector is commanded to wait through this
time-out for packets in a burst to arrive.</t>
</list></t>
</section>
<section title="Burst Gen and Meas: Accept Session Packet Format">
<t>The Accept Session command for the Burst feature is as shown in the
packet format below (assuming the Reflect Octets feature is also in
use).</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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected octets | Server octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble/>
</figure></t>
</section>
<section title="Burst Gen and Meas: Stopping Test Sessions">
<t>The Control-Client SHALL stop in-progress test sessions using any
standardized methods, including section 3.8 of <xref
target="RFC5357"/> or the optional capability of <xref
target="RFC5938"/>.</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>We note that Burst Generation and Measurement features are
incompatible with each other, and with the Symmetrical Size feature
described in <xref target="RFC6038"/>, and MUST NOT be used in
combination with those features.</t>
<t>With the publication of this memo as an RFC, the last 9 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="Burst Generation in TWAMP Test">
<t>The TWAMP test protocol is similar to the OWAMP <xref
target="RFC4656"/> test protocol with the exception that the
Session-Reflector transmits test packets to the Session-Sender in
response to each test packet it receives. The Burst Generation feature
modifies the behavior of TWAMP section 4<xref target="RFC5357"> </xref>.
This mode requires the Session-Sender to send a Burst-Initiation packet,
and the Session-Reflector generates test session packets according to
the configuration agreed using the TWAMP-Control protocol.</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 Formats and Contents">
<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"/> (as indicated in section 4.1.2 of TWAMP <xref
target="RFC5357"/>).</t>
<t>This mode uses the original TWAMP-Test Packet Padding Field (see
section 4.1.2 of <xref target="RFC4656"/>), or can be used with
Reflect Octets feature as shown below for unauthenticated mode:</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Packet Padding (to be reflected) |
. (length in octets specified in command) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Additional Packet Padding .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
<postamble>Burst Initiation Packet Format</postamble>
</figure></t>
<t>The Sequence Number, Timestamp, and Error Estimate fields are the
same as specified in section 4.1.2 of <xref target="RFC4656"/> in
OWAMP.</t>
<t>We note that the format of the Burst Initiation packet has not
been changed from the usual Session-Sender test packet format, to
simplify adoption.</t>
</section>
</section>
<section title="Reflector Behavior">
<t>The TWAMP Reflector differs significantly from the procedures and
guidelines in section 4.2 of <xref target="RFC5357"/>. The following
new functions MUST be performed:</t>
<t><list style="symbols">
<t>Recognition of the function of the Burst Initiation Packet used
in this mode.</t>
<t>Generation of the required burst of test session packets,
according to the configuration agreed in Request-TW-Session
command, with the agreed number of packets in each burst and size
of each packet in the burst.</t>
</list></t>
<section title="Session-Reflector Burst Packet Format and Contents">
<t>The Burst Generation feature retains the usual Reflector packet
fields, as shown below. When the Burst Generation mode is selected,
the Session-Reflector SHALL use the following TWAMP-Test Packet
Format in Unauthenticated mode (shown with Reflect Octets feature
activated):</t>
<t><figure>
<preamble/>
<artwork align="center"><![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 | Packet Padding (from Session-Sender) |
+-+-+-+-+-+-+-+-+ +
. .
+ +-+-+-+-+-+-+-+-+
| Packet Padding (from Session-Sender) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| |
. Additional Packet Padding .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
<postamble/>
</figure></t>
<t>Section 4.2.1 of <xref target="RFC5357"/> describes the above
fields as used in TWAMP, with one exception.</t>
<t>The Sequence Number field SHALL indicate the sequence number of
each packet sent throughout the test session. The Sequence Number
SHALL be increased by 1 for each packet. The initial Sequence Number
SHALL be 0.</t>
<t>When one burst is complete, the Sequence Numbers SHALL continue
to increment by 1 in the packets generated in response to the next
burst.</t>
<t>The total Packet Padding octets SHALL have the length specified
in the TWAMP-Control request for the appropriate test session. The
Session-Reflector MAY need to generate its own packet padding, if
the Burst Request packet does not include this field (or contains
insufficient padding).</t>
<t>In any case, the Session-Reflector MAY re-use the Sender’s
Packet Padding (since the requirements for padding generation are
the same for each) when possible.</t>
<t>The Session-Reflector SHALL send a series of TWAMP-Test Packets
in response to reception of the Burst Initiation Packet, according
to the configuration agreed in the Request-TW-Session command
(number of packets and padding), and as immediately as possible. The
Session-Reflector SHALL send all packets in a burst as close to
back-to-back as possible (recognizing that lower layers may have
spacing requirements that take precedence).</t>
</section>
</section>
</section>
<section title="Burst Measurement in TWAMP Test">
<t>The Burst Measurement feature modifies the behavior of TWAMP section
4<xref target="RFC5357"> </xref>. This mode requires the Session-Sender
to send a Burst of test packets, and the Session-Reflector measures the
burst of packets and reports the results in the Burst Response packet
format(s), as described below.</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 Session-Sender SHALL send all packets in a burst as close to
back-to-back as possible (recognizing that lower layers may have
spacing requirements that take precedence).</t>
</section>
<section title="Packet Formats and Contents">
<t>The Session-Sender packet format and content SHALL comply with
that defined in section 4.1.2 of <xref target="RFC4656"/> (as
indicated in section 4.1.2 of TWAMP <xref target="RFC5357"/>).</t>
<t>This mode uses the original TWAMP-Test Packet Padding Field (see
section 4.1.2 of <xref target="RFC4656"/>), or can be used with
Reflect Octets feature as shown below for unauthenticated mode:</t>
<t><figure>
<preamble/>
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Packet Padding (to be reflected) |
. (length in octets specified in command) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Additional Packet Padding .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
<postamble>Session-Sender Burst Test Packet Format</postamble>
</figure></t>
<t>The Burst Sequence Number field SHALL indicate the number of each
burst. The Burst Sequence Number SHALL be increased by 1 for each
burst, and remain the same for each packet in a burst. The initial
number SHALL be 0.</t>
<t>When one burst is complete, the Burst Sequence Number used in the
all packets of the next burst SHALL be increased by 1.</t>
</section>
</section>
<section title="Reflector Behavior">
<t>The TWAMP Reflector differs slightly from the procedures and
guidelines in section 4.2 of <xref target="RFC5357"/>. The following
new functions MUST be performed:</t>
<t><list style="symbols">
<t>Recognition of the function of the Session-Sender Burst Test
Packet Format used in this mode.</t>
<t>Processing the required bursts of test session packets,
according to the configuration agreed in Request-TW-Session
command, with the agreed length of the burst in packets and size
of each packet in the burst, and the agreed Burst Time-out.</t>
<t>Response with an abbreviated Session-Reflector test packet as
described below. For discussion, we will call this the 1-to-1
response.</t>
<t>OR - Response with the new Burst Measurement Response packet
described below. For discussion, we will call this the accumulated
response.</t>
</list>We seek feedback from the IPPM working group on which of
these two alternatives is preferable.</t>
<section title="Session-Reflector Burst Measurement Response Packet Format and Contents">
<t>The Burst Measurement feature specifies a standard
Session-Reflector packet to communicate the results, as shown below.
When the Burst measurement mode is selected, the Session-Sender
SHALL use the following Burst Measurement Response packet Format in
Unauthenticated mode (shown with Reflect Octets feature also in
use):</t>
<t><figure>
<preamble/>
<artwork align="center"><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Burst Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp B
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | Packet Padding (from Session-Sender) |
+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B]]></artwork>
<postamble>Session-Reflector Measurement Packet (1-to-1
response)</postamble>
</figure></t>
<t>Section 4.2.1 of <xref target="RFC5357"/> describes the fields in
the 1-to-1 response packet above; they are the same as used in
TWAMP. The main difference is that Packet Padding SHALL be truncated
on a 16 octet-word boundary, returning the minimum information to
the Session-Sender.</t>
<t>All Timestamps SHALL be formatted according to the precedent set
in section 4.1.2 of <xref target="RFC4656"/>, which is to use <xref
target="RFC1305"/> (and updated version), as follows:</t>
<t>"The first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; the next 32 bits
represent the fractional part of a second that has elapsed since
then."</t>
<t>The Session-Reflector MUST truncate the Sender's Packet Padding,
unless the Reflect Octets feature is also active in which case the
Session_Reflector MAY re-use the Sender’s Packet Padding
(since the requirements for padding generation are the same for
each) to reach a word boundary.</t>
<t>The Sender Timestamp field SHALL have the sender's timestamp from
each packet received in the burst.</t>
<t>In 1-to-1 response mode, the Session-Reflector SHALL send a
Session-Reflector Measurement Packet in response to every
Session-Sender packet received, and as quickly as possible.</t>
<t>========================================================</t>
<t>In the accumulated response alternative, the Session-Reflector
creates and holds all packet headers described above in a buffer,
and sends them all at once in a single Session-Reflector test
packet. The length of the burst and the path MTU MUST be coordinated
to avoid fragmentation.</t>
<t>The first Session-Sender packet to arrive with a previously
unseen Burst Sequence Number SHALL be designated as the "First"
packet in that burst, and its timestamp is used in processing
below.</t>
<t>As subsequent packets arrive, Session-Reflector SHALL:</t>
<t><list style="symbols">
<t>Maintain a count of packets with the same Burst Sequence
Number (one burst).</t>
<t>Time stamp each packet as it arrives and store the time stamp
in a response packet structure with all fields complete, as in
the 1-to-1 alternative.</t>
</list>When</t>
<t><list style="symbols">
<t>The count of packets with the same Burst Sequence Number
equals the agreed Burst Length, OR</t>
<t>The agreed Timeout expires (computed by a the time to the
"First" Packet Timestamp), OR</t>
<t>The Burst Sequence Number increases from previous packets
(indicating a new Burst is in progress),</t>
</list>then the current burst is determined to be complete.</t>
<t>When the Burst is complete, the Session-Reflector SHALL terminate
the current burst processing as described above and send the Burst
Measurement Response Packet to the Session-Sender as immediately as
possible.</t>
<t>In Accumulated Response, the Burst Measurement Response Packet is
a single packet with the concatenation of all previously-generated
response packet formats in the information field.</t>
</section>
</section>
</section>
<section title="Special Case of One-packet Bursts">
<t>When the Number of Packets field in the Request-TW-Session command
equals 1, then the Burst Generation and Measurement modes are reduced to
test sessions with controlled, asymmetrical packet sizes. A minimal size
packet travels in one direction, and the measured direction uses a
packet with all Packet Padding specified in the Request-TW-Session
command.</t>
</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="Registry Contents">
<t>TWAMP Modes Registry is recommended to be augmented as
follows:<figure>
<preamble/>
<artwork><![CDATA[Value Description Semantics Definition
--------------------------------------------------------
xxx Burst Generation this memo, section 3.1
Capability new bit position (X)
yyy Burst Measurement this memo, section 3.1
new bit position (Y)
]]></artwork>
<postamble/>
</figure></t>
<t>>>>IANA: change xxx, yyy, X, Y, and RFC???? to the
assigned values</t>
<t>The suggested values are</t>
<t>X=7, xxx=128</t>
<t>Y=8, yyy=256 <<<<</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors thank Chistofer Flinta for review and comment.</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>
| PAFTECH AB 2003-2026 | 2026-04-24 05:57:54 |