draft-ietf-ippm-twamp-reflect-octets-06.txt   draft-ietf-ippm-twamp-reflect-octets-07.txt 
Network Working Group A. Morton Network Working Group A. Morton
Internet-Draft L. Ciavattone Internet-Draft L. Ciavattone
Updates: 5357 (if approved) AT&T Labs Updates: 5357 (if approved) AT&T Labs
Intended status: Standards Track May 30, 2010 Intended status: Standards Track June 28, 2010
Expires: December 1, 2010 Expires: December 30, 2010
TWAMP Reflect Octets and Symmetrical Size Features TWAMP Reflect Octets and Symmetrical Size Features
draft-ietf-ippm-twamp-reflect-octets-06 draft-ietf-ippm-twamp-reflect-octets-07
Abstract Abstract
The IETF has completed its work on the core specification of TWAMP - This memo describes two closely-related features for the core
the Two-Way Active Measurement Protocol. This memo describes two specification of TWAMP - the Two-Way Active Measurement Protocol: an
closely-related features for TWAMP: an optional capability where the optional capability where the responding host returns some of the
responder host returns some of the command octets or padding octets command octets or padding octets to the sender, and an optional
to the controller, and an optional sender packet format that ensures sender packet format that ensures equal test packet sizes are used in
equal test packet sizes are used in both directions. both directions.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2010. This Internet-Draft will expire on December 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4
3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 5
3.1. Connection Setup with New Features . . . . . . . . . . . . 5 3.1. Connection Setup with New Features . . . . . . . . . . . . 5
3.2. Reflect Octets: Request-TW-Session Packet Format . . . . . 6 3.2. Reflect Octets: Request-TW-Session Packet Format . . . . . 6
3.3. Reflect Octets: Accept Session Packet Format . . . . . . . 8 3.3. Reflect Octets: Accept Session Packet Format . . . . . . . 8
3.4. Additional considerations . . . . . . . . . . . . . . . . 10 3.4. Additional considerations . . . . . . . . . . . . . . . . 9
4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 10 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 9
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Reflect Octets: Packet Formats and Contents . . . . . 10 4.1.2. Reflect Octets: Packet Formats and Contents . . . . . 10
4.1.3. Reflect Octets: Interaction with Padding Truncation . 12 4.1.3. Reflect Octets: Interaction with Padding Truncation . 11
4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 13 4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 12
4.1.5. Symmetrical Size AND Reflect Octets: 4.1.5. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 14 Session-Sender Packet Format . . . . . . . . . . . . . 13
4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 15 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Reflect Octets: Session-Reflector Packet Format 4.2.1. Reflect Octets: Session-Reflector Packet Format
and Contents . . . . . . . . . . . . . . . . . . . . . 16 and Contents . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 17 4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 16
4.2.3. Symmetrical Size AND Reflect Octets: 4.2.3. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 17 Session-Sender Packet Format . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. Registry Specification . . . . . . . . . . . . . . . . . . 18 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 17
6.2. Registry Management . . . . . . . . . . . . . . . . . . . 18 6.2. Registry Contents . . . . . . . . . . . . . . . . . . . . 17
6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The IETF has completed its work on the core specification of TWAMP - TWAMP - the Two-Way Active Measurement Protocol [RFC5357] is an
the Two-Way Active Measurement Protocol [RFC5357]. TWAMP is an
extension of the One-way Active Measurement Protocol, OWAMP extension of the One-way Active Measurement Protocol, OWAMP
[RFC4656]. The TWAMP specification gathered wide review as it [RFC4656]. The TWAMP specification gathered wide review as it
approached completion, and the by-products were several approached completion, and the by-products were several
recommendations for new features in TWAMP. There are a growing recommendations for new features in TWAMP.
number TWAMP implementations at present, and wide-spread usage is
expected. There are even devices that are designed to test
implementations for protocol compliance.
This memo describes two closely-related features for TWAMP. This memo describes two closely-related features for TWAMP.
One is the OPTIONAL capability for the responder host to return a One is the OPTIONAL capability for the responder host to return a
limited number of unassigned (padding) octets to the Control-Client limited number of unassigned (padding) octets to the Control-Client
or Session-Sender entities in both the TWAMP-Control and TWAMP-Test or Session-Sender entities in both the TWAMP-Control and TWAMP-Test
protocols. With this capability, the Control-Client or Session- protocols. With this capability, the Control-Client or Session-
Sender can embed octets of information it deems useful and have the Sender can embed octets of information it deems useful and have the
assurance that the corresponding reply/test packet will contain that assurance that the corresponding reply/test packet will contain that
information when it is reflected and returned (by the Server or information when it is reflected and returned (by the Server or
skipping to change at page 4, line 45 skipping to change at page 4, line 41
features described in this memo to claim compliance with [RFC5357]. features described in this memo to claim compliance with [RFC5357].
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set 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 to zero by senders and MUST be ignored by receivers. Also, the HMAC
(Hashed Message Authentication Code) MUST be calculated as defined in (Hashed Message Authentication Code) MUST be calculated as defined in
Section 3.2 of [RFC4656]. Section 3.2 of [RFC4656].
2. Purpose and Scope 2. Purpose and Scope
The purpose of this memo is to define two OPTIONAL closely-related The purpose of this memo is to define two OPTIONAL closely-related
features for TWAMP [RFC5357]. The features enhance the TWAMP features for TWAMP [RFC5357]. The features enhance the TWAMP host's
responder's capabilities to perform simple operations on control and capabilities to perform a simple operation on control and test
test packets: the reflection of octets or padding and symmetrical packets: the reflection of octets or padding, and the capability to
sizes of fields in the TWAMP-Test packets. Motivations include ensure symmetrical size TWAMP-Test packets. Motivations include
permitting the controller host to tag packets with an index for permitting the controller host to tag packets with an index for
simplified identification, and/or assert that the same size test simplified identification, and/or assert that the same size test
packets will be used in each direction. packets will be used in each direction.
The scope of the memo is limited to specifications of the following The scope of the memo is limited to specifications of the following
features: features:
o Reflect Octets: the capability of the Server/Session-Reflector to o Reflect Octets: the capability of the Server/Session-Reflector to
reflect specific octets back to the Client/Session-Sender. reflect specific octets back to the Client/Session-Sender, and a
similar service provided by the Client and Session-Sender.
o Symmetrical Size: the capability to ensure that TWAMP-Test o Symmetrical Size: the capability to ensure that TWAMP-Test
protocol uses the same packet size in both directions through protocol uses the same packet size in both directions through
support of a new TWAMP-Test Session-Sender test packet format in support of a new TWAMP-Test Session-Sender test packet format in
both the Session-Sender and the Session-Reflector. Only the both the Session-Sender and the Session-Reflector. Only the
Session-Sender test packet format is new. Session-Sender test packet format is new.
This memo extends the modes of operation through assignment of two 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 new values in the Modes Field (see section 3.1 of[RFC4656] for the
format of the Server Greeting message), while retaining backward format of the Server Greeting message), while retaining backward
skipping to change at page 5, line 47 skipping to change at page 5, line 45
recognized extension mechanism. The following sections describe two recognized extension mechanism. The following sections describe two
such extensions. such extensions.
3.1. Connection Setup with New Features 3.1. Connection Setup with New Features
TWAMP connection establishment follows the procedure defined in TWAMP connection establishment follows the procedure defined in
section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new section 3.1 of [RFC4656] and section 3.1 of [RFC5357]. The new
features require two new bit positions (and values) to identify the features require two new bit positions (and values) to identify the
ability of the Server/Session-Reflector to reflect specific octets ability of the Server/Session-Reflector to reflect specific octets
back to the Control-Client/Session-Sender, and to support the new back to the Control-Client/Session-Sender, and to support the new
Session-Sender packet format in TWAMP-Test Protocol. With this added Session-Sender packet format in TWAMP-Test Protocol. See the IANA
feature, the complete set of TWAMP Modes Field bit positions and section for details on the assigned values and bit positions.
values would be as follows:
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, RFC5681, Section 3.1
Encrypted CONTROL
16 Individual Session RFC????, Section 3.1
Control
--------------------------------------------------------
xxx Reflect Octets new bit position (X)
Capability
yyy Symmetrical Size new bit position (Y)
Sender Test Packet Format
In the original OWAMP Modes 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 [RFC4656]). In
[RFC5618], bit position 3 allows unauthenticated TWAMP Test protocol
to be used with encryption on the TWAMP-Control protocol in a mixed
mode of operation.
The Server sets one or both of the new bit positions (X and Y) in the
Modes Field of the Server Greeting message to indicate its
capabilities and willingness to operate in either of these modes (or
both) if desired.
>>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values 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 (or both) if desired.
If the Control-Client intends to operate all test sessions invoked If the Control-Client intends to operate all test sessions invoked
with this control connection using one or both of the new modes, it with this control connection using one or both of the new modes, it
MUST set the Mode Field bit corresponding to each function in the MUST set the Mode Field bit corresponding to each function in the
Setup Response message. With this and other extensions, the Control- Setup Response message. With this and other extensions, the Control-
Client MAY set multiple Mode Field bits in the Setup Response Client MAY set multiple Mode Field bits in the Setup Response
message. message.
3.2. Reflect Octets: Request-TW-Session Packet Format 3.2. Reflect Octets: Request-TW-Session Packet Format
skipping to change at page 13, line 13 skipping to change at page 12, line 13
directions are shown in the table below: directions are shown in the table below:
+-------------------+----------------------+---------------------+ +-------------------+----------------------+---------------------+
| Octets in: | Unauthenticated Mode | Auth/Encrypted Mode | | Octets in: | Unauthenticated Mode | Auth/Encrypted Mode |
+-------------------+----------------------+---------------------+ +-------------------+----------------------+---------------------+
| Reflector Header | 41 | 104 | | Reflector Header | 41 | 104 |
| Sender Header | 14 | 48 | | Sender Header | 14 | 48 |
| Truncated Padding | 27 | 56 | | Truncated Padding | 27 | 56 |
+-------------------+----------------------+---------------------+ +-------------------+----------------------+---------------------+
TWAMP-Test Padding Trucation TWAMP-Test Padding Truncation
When using the Reflect Octets mode simultaneously with the When using the Reflect Octets mode simultaneously with the
RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357], the RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357], the
Session-Sender MUST append at least 27 octets of padding plus the Session-Sender MUST append at least 27 octets of padding plus the
"Length of the padding to reflect" octets when operating in "Length of the padding to reflect" octets when operating in
Unauthenticated mode. The Session-Sender MUST append at least 56 Unauthenticated mode. The Session-Sender MUST append at least 56
octets of padding plus the "Length of the padding to reflect" octets octets of padding plus the "Length of the padding to reflect" octets
when operating in Authenticated and Encrypted modes. when operating in Authenticated and Encrypted modes.
4.1.4. Symmetrical Size: Session-Sender Packet Format 4.1.4. Symmetrical Size: Session-Sender Packet Format
skipping to change at page 18, line 25 skipping to change at page 17, line 25
Set-up Response messages, as described in section 3.1 of [RFC5357], Set-up Response messages, as described in section 3.1 of [RFC5357],
consistent with section 3.1 of [RFC4656], and extended by this memo. 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 Modes are indicated by setting bits in the 32-bit Modes field that
correspond to values in the Modes registry. For the TWAMP-Modes correspond to values in the Modes registry. For the TWAMP-Modes
registry, we expect that new features will be assigned increasing registry, we expect that new features will be assigned increasing
registry values that correspond to single bit positions, unless there registry values that correspond to single bit positions, unless there
is a good reason to do otherwise (more complex encoding than single 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 bit positions may be used in the future, to access the 2^32 value
space). space).
6.2. Registry Management 6.2. Registry Contents
This registry must be updated only by "IETF Consensus" as specified
in [RFC5226](an RFC documenting registry use that is approved by the
IESG).
6.3. Experimental Numbers
No experimental values are currently assigned for the Modes Registry.
6.4. Registry Contents
TWAMP Modes Registry is recommended to be augmented as follows: TWAMP Modes Registry is recommended to be augmented as follows:
Value Description Semantics Definition Value Description Semantics Definition
0 Reserved 0 Reserved
1 Unauthenticated RFC4656, Section 3.1 1 Unauthenticated RFC4656, Section 3.1
2 Authenticated RFC4656, Section 3.1 2 Authenticated RFC4656, Section 3.1
skipping to change at page 19, line 24 skipping to change at page 17, line 48
8 Unauth. TEST protocol, RFC5618, Section 3.1 (3) 8 Unauth. TEST protocol, RFC5618, Section 3.1 (3)
Auth. CONTROL Auth. CONTROL
16 Individual Session RFC????, Section 3.1 16 Individual Session RFC????, Section 3.1
Control bit position (4) Control bit position (4)
-------------------------------------------------------- --------------------------------------------------------
xxx Reflect Octets this memo, section 3.1 xxx Reflect Octets this memo, section 3.1
Capability new bit position (X) Capability new bit position (X)
yyy Symmetrical Size this memo, section 3.1 yyy Symmetrical Size this memo, section 3.1
Sender Test Packet Format new bit position (Y) Sender Test Packet Format new bit position (Y)
The suggested values are >>>IANA: change xxx, yyy, X, Y, and RFC???? to the assigned values
The suggested values are
X=5, xxx=32 X=5, xxx=32
Y=6, yyy=64 Y=6, yyy=64 <<<<
7. Acknowledgements 7. Acknowledgements
The authors thank Steve Baillargeon, Walt Steverson, and Stina Ross The authors thank Steve Baillargeon, Walt Steverson, and Stina Ross
for helpful review and comments. for helpful review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 20 change blocks. 
89 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/