draft-ietf-ippm-twamp-reflect-octets-05.txt   draft-ietf-ippm-twamp-reflect-octets-06.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 April 19, 2010 Intended status: Standards Track May 30, 2010
Expires: October 21, 2010 Expires: December 1, 2010
TWAMP Reflect Octets and Symmetrical Size Features TWAMP Reflect Octets and Symmetrical Size Features
draft-ietf-ippm-twamp-reflect-octets-05 draft-ietf-ippm-twamp-reflect-octets-06
Abstract Abstract
The IETF has completed its work on the core specification of TWAMP - The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol. This memo describes two the Two-Way Active Measurement Protocol. This memo describes two
closely-related features for TWAMP: an optional capability where the closely-related features for TWAMP: an optional capability where the
responder host returns some of the command octets or padding octets responder host returns some of the command octets or padding octets
to the controller, and an optional sender packet format that ensures to the controller, and an optional sender packet format that ensures
equal test packet sizes are used in both directions. equal test packet sizes are used in both directions.
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 October 21, 2010. This Internet-Draft will expire on December 1, 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 . . . . . . . . . . . . . . . . 9 3.4. Additional considerations . . . . . . . . . . . . . . . . 10
4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 10 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 10
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 10
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 . 12
4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 13 4.1.4. Symmetrical Size: Session-Sender Packet Format . . . . 13
4.1.5. Symmetrical Size AND Reflect Octets: 4.1.5. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 13 Session-Sender Packet Format . . . . . . . . . . . . . 14
4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 14 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Reflect Octets: Session-Reflector Packet Format 4.2.1. Reflect Octets: Session-Reflector Packet Format
and Contents . . . . . . . . . . . . . . . . . . . . . 15 and Contents . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 16 4.2.2. Symmetrical Size: Session-Reflector Packet Format . . 17
4.2.3. Symmetrical Size AND Reflect Octets: 4.2.3. Symmetrical Size AND Reflect Octets:
Session-Sender Packet Format . . . . . . . . . . . . . 16 Session-Sender Packet Format . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Registry Specification . . . . . . . . . . . . . . . . . . 17 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 18
6.2. Registry Management . . . . . . . . . . . . . . . . . . . 17 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 18
6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 17 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 18
6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 17 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The IETF has completed its work on the core specification of TWAMP - The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol [RFC5357]. TWAMP 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. There are a growing
number TWAMP implementations at present, and wide-spread usage is number TWAMP implementations at present, and wide-spread usage is
expected. There are even devices that are designed to test expected. There are even devices that are designed to test
implementations for protocol compliance. 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. With this capability, the Control-Client or Session-Sender entities in both the TWAMP-Control and TWAMP-Test
or Session-Sender can embed octets of information it deems useful and protocols. With this capability, the Control-Client or Session-
have the assurance that the corresponding reply/test packet will Sender can embed octets of information it deems useful and have the
contain that information when it is reflected and returned (by the assurance that the corresponding reply/test packet will contain that
Server or Session-Reflector. information when it is reflected and returned (by the Server or
Session-Reflector.
The memo also adds an OPTIONAL capability to assure that reflected The memo also adds an OPTIONAL capability to assure that reflected
test packets are the same size in both directions of transmission. test packets are the same size in both directions of transmission.
This is accomplished by specifying a new TWAMP-Test Session-Sender This is accomplished by specifying a new TWAMP-Test Session-Sender
packet format. packet format.
This memo is an update to the TWAMP core protocol specified in This memo is an update to the TWAMP core protocol specified in
[RFC5357]. Measurement systems are not required to implement the [RFC5357]. Measurement systems are not required to implement the
features described in this memo to claim compliance with [RFC5357]. features described in this memo to claim compliance with [RFC5357].
skipping to change at page 9, line 34 skipping to change at page 9, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Reflected octets" field SHALL contain the octets from the The "Reflected octets" field SHALL contain the octets from the
Request-TW-Session "Octets to be reflected" Field, and be 2 octets Request-TW-Session "Octets to be reflected" Field, and be 2 octets
long, as shown. long, as shown.
The "Server octets" field SHALL contain information that the Server The "Server octets" field SHALL contain information that the Server
intends to be returned in the TWAMP-Test packet padding to-be- intends to be returned in the TWAMP-Test packet padding to-be-
reflected Field, OR SHALL be zero, and be 2 octets long, as shown. reflected Field, OR SHALL be zero, and be 2 octets long, as shown.
Although the Server determines the SID, this field is very long (16 Although the Server determines the SID, this field is very long (16
octets) and does not normally appear in TWAMP-Test packets. octets) and does not normally appear in TWAMP-Test packets. The
following items MUST be part of compliant implementations using the
Reflect Octets feature:
o When a Server does not require octets to be returned in TWAMP-Test
packets, it MUST send all zeros in the Server octets field
o When a Server intends octets to be returned in TWAMP-Test packets,
it MUST send a non-zero value in the Server octets field, and the
TWAMP-Test Sender MUST include those octets at the beginning of
the "Packet Padding (to be reflected)" field
o Section 4.1.2 defines how Server octets MUST be included in the
TWAMP-Test packet padding when this service is desired by the
Server (indicated in the second of two figures in the section)
When supporting the RECOMMENDED truncation process in TWAMP section When supporting the RECOMMENDED truncation process in TWAMP section
4.2.1 [RFC5357], IF calculations on the Padding lengths reveal that 4.2.1 [RFC5357], IF calculations on the Padding lengths reveal that
there are insufficient octets supplied to produce equal-length there are insufficient octets supplied to produce equal-length
Session-Sender and Session-Reflector test packets, then the Accept Session-Sender and Session-Reflector test packets, then the Accept
Field MUST be set to 3 = some aspect of the request is not supported. Field MUST be set to 3 = some aspect of the request is not supported.
3.4. Additional considerations 3.4. Additional considerations
The value of the Modes Field sent by the Server in the Server The value of the Modes Field sent by the Server in the Server
skipping to change at page 11, line 37 skipping to change at page 11, line 38
that the Session-Sender expects will be returned by the Session- that the Session-Sender expects will be returned by the Session-
Reflector. Reflector.
The length of the "Additional Packet Padding" Field is the difference The length of the "Additional Packet Padding" Field is the difference
between two fields in the Request-TW-Session command, as follows: between two fields in the Request-TW-Session command, as follows:
"Additional Packet Padding", in octets = "Additional Packet Padding", in octets =
"Padding Length" - "Length of padding to reflect" "Padding Length" - "Length of padding to reflect"
One possible use of the first 4 octets of the "Packet Padding (to be When a Server intends octets to be returned in TWAMP-Test packets, it
reflected)" Field is shown below: MUST send a non-zero value in the Server octets field, and the TWAMP-
Test Session-Sender MUST include those octets in the first 2 octets
of the "Packet Padding (to be reflected)" Field as shown below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server octets | | Server octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client octets | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Packet Padding (to be reflected) | | Packet Padding (to be reflected) |
. (length in octets specified elsewhere) . . (length in octets specified elsewhere) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, the "Client octets" and the "Server octets" fields
contain the same information that the Client and Server exchanged in The "Server octets" field contains the same information that the
the Request-TW-Session and Accept-Session messages corresponding to Server returned to the Control-Client in the Accept-Session message
this specific test session. These octets would be reflected the same corresponding to this specific test session (see section 3.3). At
as the rest of the "Packet Padding (to be reflected)" Field. the Session-Reflector, these octets MUST be reflected the same as the
rest of the "Packet Padding (to be reflected)" field.
Note that it is permissible for the Session-Sender to insert the same
octets used in the "Octets to be reflected" field of the Request-TW-
Session command elsewhere in the "Packet Padding (to be reflected)"
field.
4.1.3. Reflect Octets: Interaction with Padding Truncation 4.1.3. Reflect Octets: Interaction with Padding Truncation
When the Reflect Octets mode is selected, and the RECOMMENDED When the Reflect Octets mode is selected, and the RECOMMENDED
truncation process in TWAMP section 4.2.1 [RFC5357] is supported, the truncation process in TWAMP section 4.2.1 [RFC5357] is supported, the
Session-Sender MUST anticipate a minimum padding required to achieve Session-Sender MUST anticipate a minimum padding required to achieve
equal size test packets in both directions. The amount of padding equal size test packets in both directions. The amount of padding
needed to achieve symmetrical packet size depends on BOTH the needed to achieve symmetrical packet size depends on BOTH the
security mode (Unauthenticated/Authenticated/Encrypted) and whether security mode (Unauthenticated/Authenticated/Encrypted) and whether
the Reflect Octets mode is selected simultaneously. the Reflect Octets mode is selected simultaneously.
skipping to change at page 15, line 47 skipping to change at page 16, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| | | |
. Additional Packet Padding . . Additional Packet Padding .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Packet Padding (from Session-Sender)" field MUST be the same The "Packet Padding (from Session-Sender)" field MUST be the same
octets as the "Packet Padding (to be reflected)" field in the octets as the "Packet Padding (to be reflected)" field in the
Session-Sender's test packet, and therefore MUST conform to the Session-Sender's test packet, and therefore MUST conform to the
length specified in the Request-TW-Session message. length specified in the Request-TW-Session message.
When the Server has returned a non-zero value in the "Server octets"
field of the Accept Session message (as described in section 3.3),
then the Session-Reflector SHALL reflect these octets the same as the
rest of the "Packet Padding (to be reflected)" Field.
When simultaneously using the RECOMMENDED truncation process in TWAMP When simultaneously using the RECOMMENDED truncation process in TWAMP
section 4.2.1 [RFC5357] AND Reflect octets mode, the Session- section 4.2.1 [RFC5357] AND Reflect octets mode, the Session-
Reflector MUST reflect the designated octets from the Session- Reflector MUST reflect the designated octets from the Session-
Sender's test packet in the "Packet Padding (from Session-Sender)" Sender's test packet in the "Packet Padding (from Session-Sender)"
Field, and MAY re-use additional Packet Padding from the Session- Field, and MAY re-use additional Packet Padding from the Session-
Sender. The Session-Reflector MUST truncate the padding such that Sender. The Session-Reflector MUST truncate the padding such that
the highest number octets are discarded, and the test packet length the highest number octets are discarded, and the test packet length
equals the Session-Sender's packet length. When using the equals the Session-Sender's packet length. When using the
RECOMMENDED truncation process, the Session-Reflector MUST truncate RECOMMENDED truncation process, the Session-Reflector MUST truncate
exactly 27 octets of padding in Unauthenticated mode, and exactly 56 exactly 27 octets of padding in Unauthenticated mode, and exactly 56
 End of changes. 14 change blocks. 
36 lines changed or deleted 64 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/