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 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
• 2. Purpose and Scope
• 3. TWAMP Control Extensions
• 3.1. Connection Setup with New Features
• 3.2. TCP Connection: Request-TW-Session Packet Format
• 3.3. TCP Connection: Accept Session Packet Format
• 3.4. Stopping Test Sessions
• 3.5. Additional considerations
• 4. TWAMP Test for TCP Connection Feature
• 4.1. Initiater Behavior
• 4.2. Listener Behavior
• 5. Security Considerations
• 6. IANA Considerations
• 6.1. Registry Specification
• 6.2. Modes Registry Contents
• 6.3. Command Number Registry Contents
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

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).

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:

• Unauthenticated mode (value 1)
• Unauthenticated TEST protocol, Encrypted CONTROL (value 8)

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).

 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.

 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)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 0 = OK (Accept the session)
• 1 = Failure, reason unspecified
• 2 = Internal Error
• 3 = Some aspect of the request is not supported
• 4 = Cannot perform request due to permanent resource limitations
• 5 = Cannot perform request due to temporary resource limitations
• 6 = Requested Port Not Available
• 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.

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 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:

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

8.2. Informative References

Author's Address