One document matched: draft-morton-ippm-twamp-tcp-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-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&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>>>>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=??? <<<<</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>>>>IANA: change XX to the assigned values</t>
<t>The suggested values are</t>
<t>XX=11, <<<<</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>
| PAFTECH AB 2003-2026 | 2026-04-24 05:59:59 |