Internet DRAFT - draft-morton-ippm-twamp-tcp
draft-morton-ippm-twamp-tcp
Network Working Group A. Morton
Internet-Draft AT&T Labs
Updates: 5357 (if approved) July 15, 2013
Intended status: Standards Track
Expires: January 16, 2014
TWAMP Control of a TCP Connection
draft-morton-ippm-twamp-tcp-00
Abstract
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.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Morton Expires January 16, 2014 [Page 1]
Internet-Draft TWAMP TCP Connection July 2013
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 4
3.1. Connection Setup with New Features . . . . . . . . . . . . 4
3.2. TCP Connection: Request-TW-Session Packet Format . . . . . 5
3.3. TCP Connection: Accept Session Packet Format . . . . . . . 6
3.4. Stopping Test Sessions . . . . . . . . . . . . . . . . . . 8
3.5. Additional considerations . . . . . . . . . . . . . . . . 8
4. TWAMP Test for TCP Connection Feature . . . . . . . . . . . . 8
4.1. Initiater Behavior . . . . . . . . . . . . . . . . . . . . 8
4.2. Listener Behavior . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Registry Specification . . . . . . . . . . . . . . . . . . 9
6.2. Modes Registry Contents . . . . . . . . . . . . . . . . . 9
6.3. Command Number Registry Contents . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Morton Expires January 16, 2014 [Page 2]
Internet-Draft TWAMP TCP Connection July 2013
1. Introduction
TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an
extension of the One-way Active Measurement Protocol, OWAMP
[RFC4656]. The TWAMP specification gathered wide review as it was
deployed, resulting in recommendations for new features.
An open question in the IPPM problem statement draft
[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.
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.
This memo is an update to the TWAMP core protocol specified in
[RFC5357]. Measurement systems are not required to implement the
features described in this memo to claim compliance with [RFC5357].
TWAMP was selected to host the TCP Connection feature because OWAMP
[RFC4656] was not extended to use the Mixed Security mode, and this
is a distinct advantage in testing.
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 [RFC4656].
2. Purpose and Scope
The purpose of this memo is to define an OPTIONAL feature for TWAMP
[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.
This memo is intended to satisfy key requirements contained in the
IPPM problem statement [I-D.ietf-ippm-rate-problem]. Referring to
the reference path defined in [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).
Morton Expires January 16, 2014 [Page 3]
Internet-Draft TWAMP TCP Connection July 2013
This memo extends the modes of operation through assignment of two
new values in the Modes Field (see section 3.1 of[RFC4656] for the
format of the Server Greeting message), while retaining backward
compatibility with the core TWAMP [RFC5357] implementations. The two
new values correspond to the two roles (connection initiator or
connection listener) defined in this memo.
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.
3. TWAMP Control Extensions
TWAMP-Control protocol [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.
3.1. Connection Setup with New Features
TWAMP connection establishment follows the procedure defined in
section 3.1 of [RFC4656] and section 3.1 of [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.
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.
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.
The following Mode settings are compatible with either TCP Connection
Mode:
o Unauthenticated mode (value 1)
o Unauthenticated TEST protocol, Encrypted CONTROL (value 8)
Morton Expires January 16, 2014 [Page 4]
Internet-Draft TWAMP TCP Connection July 2013
The latter is referred to as the Mixed Security Mode.
The function of Integrity Protections and Values of the Accept Field
(sections 3.2 and 3.3 of [RFC5357]) remain as described.
3.2. TCP Connection: Request-TW-Session Packet Format
The bits designated for the TCP Connection feature in the Request-TW-
Session command are as shown in the packet format below.
This is a new command, designated by the TWAMP-Control Command Number
XX (where XX will be assigned by IANA).
Morton Expires January 16, 2014 [Page 5]
Internet-Draft TWAMP TCP Connection July 2013
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
field formatting is TBD
3.3. TCP Connection: Accept Session Packet Format
The Accept Session command for the TCP Connection feature is as shown
in the packet format below.
Morton Expires January 16, 2014 [Page 6]
Internet-Draft TWAMP TCP Connection July 2013
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
o 0 = OK (Accept the session)
o 1 = Failure, reason unspecified
o 2 = Internal Error
o 3 = Some aspect of the request is not supported
o 4 = Cannot perform request due to permanent resource limitations
o 5 = Cannot perform request due to temporary resource limitations
o 6 = Requested Port Not Available
o 7 = Requested Address Not Available
All other values are reserved for future use. Reception of a non-
designated value MUST be interpreted as 1 = Failure.
Morton Expires January 16, 2014 [Page 7]
Internet-Draft TWAMP TCP Connection July 2013
3.4. Stopping Test Sessions
The Control-Client SHALL stop in-progress test sessions using
standardized methods, section 3.8 of [RFC5357].
3.5. Additional considerations
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.
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 [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.
4. TWAMP Test for TCP Connection Feature
This section will include additional considerations for the TCP
Connection Initiator and Listener, once a session has been requested
and accepted.
4.1. Initiater Behavior
This section describes extensions to the behavior of the TWAMP TCP
Initiator.
4.2. Listener Behavior
The TWAMP TCP Listener
5. Security Considerations
These extended modes of operation do not appear to permit any new
attacks on hosts communicating with core TWAMP [RFC5357].
The security considerations that apply to any active measurement of
live networks are relevant here as well. See [RFC4656] and
[RFC5357].
6. IANA Considerations
This memo adds two modes to the IANA registry for the TWAMP Modes
Morton Expires January 16, 2014 [Page 8]
Internet-Draft TWAMP TCP Connection July 2013
Field, and describes behavior when the new modes are used. This
field is a recognized extension mechanism for TWAMP.
6.1. Registry Specification
IANA has created a TWAMP-Modes registry (as requested in [RFC5618]).
TWAMP-Modes are specified in TWAMP Server Greeting messages and
Set-up Response messages, as described in section 3.1 of [RFC5357],
consistent with section 3.1 of [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).
6.2. Modes Registry Contents
TWAMP Modes Registry is recommended to be augmented as follows:
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)
>>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values
The suggested values are
X=?, xxx=???
Y=?, yyy=??? <<<<
6.3. Command Number Registry Contents
TWAMP-Control Command Number Registry is recommended to be augmented
as follows:
Morton Expires January 16, 2014 [Page 9]
Internet-Draft TWAMP TCP Connection July 2013
Value Description Semantics Definition
--------------------------------------------------------
XX TCP Connection this memo, section 3.2
>>>IANA: change XX to the assigned values
The suggested values are
XX=11, <<<<
7. Acknowledgements
The author will complete this section as appropriate.
8. References
8.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
August 2009.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol
(TWAMP)", RFC 5938, August 2010.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, October 2010.
Morton Expires January 16, 2014 [Page 10]
Internet-Draft TWAMP TCP Connection July 2013
8.2. Informative References
[I-D.ietf-ippm-rate-problem]
Morton, A., "Rate Measurement Test Protocol Problem
Statement", draft-ietf-ippm-rate-problem-03 (work in
progress), April 2013.
[I-D.morton-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-morton-ippm-lmap-path-01 (work in progress),
February 2013.
Author's Address
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown,, NJ 07748
USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Morton Expires January 16, 2014 [Page 11]
