draft-ietf-ippm-twamp-02.txt   draft-ietf-ippm-twamp-03.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: April 2007 R. Krzanowski Expires: September 2007 R. Krzanowski
Verizon Verizon
K. Yum K. Yum
Juniper Networks Juniper Networks
A. Morton A. Morton
AT&T Labs AT&T Labs
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
November 2006
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-02 draft-ietf-ippm-twamp-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 41
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP) The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP)
provides a common protocol for measuring one-way metrics between provides a common protocol for measuring one-way metrics between
network devices. OWAMP can be used bi-directionally to measure network devices. OWAMP can be used bi-directionally to measure
one-way metrics in both directions between two network elements. one-way metrics in both directions between two network elements.
However, it does not accommodate round-trip or two-way However, it does not accommodate round-trip or two-way
measurements. This memo specifies a Two-way Active Measurement measurements. This memo specifies a Two-way Active Measurement
Protocol (TWAMP), based on the OWAMP, that adds two-way or Protocol (TWAMP), based on the OWAMP, that adds two-way or
skipping to change at page 2, line 38 skipping to change at page 2, line 38
3.3 Value of the Accept Fields................................6 3.3 Value of the Accept Fields................................6
3.4 TWAMP Control Commands....................................6 3.4 TWAMP Control Commands....................................6
3.5 Creating Test Sessions....................................6 3.5 Creating Test Sessions....................................6
3.6 Send Schedules............................................8 3.6 Send Schedules............................................8
3.7 Starting Test Sessions....................................8 3.7 Starting Test Sessions....................................8
3.8 Stop-Sessions.............................................8 3.8 Stop-Sessions.............................................8
3.9 Fetch-Session.............................................8 3.9 Fetch-Session.............................................8
4. TWAMP Test....................................................8 4. TWAMP Test....................................................8
4.1 Sender Behavior...........................................9 4.1 Sender Behavior...........................................9
4.2 Reflector Behavior........................................9 4.2 Reflector Behavior........................................9
5. Implementers Guide...........................................14 5. Implementers Guide...........................................15
5.1 Complete TWAMP...........................................14 5.1 Complete TWAMP...........................................15
5.2 TWAMP Light..............................................14 5.2 TWAMP Light..............................................16
6. Security Considerations......................................15 6. Security Considerations......................................17
7. Acknowledgements.............................................15 7. Acknowledgements.............................................17
8. IANA Considerations..........................................15 8. IANA Considerations..........................................17
9. Internationalization Considerations..........................16 9. Internationalization Considerations..........................17
10. References..................................................16 10. References..................................................18
10.1 Normative References....................................16 10.1 Normative References....................................18
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has completed The IETF IP Performance Metrics (IPPM) working group has completed
a draft standard for the round-trip delay [RFC2681] metric. IPPM a draft standard for the round-trip delay [RFC2681] metric. IPPM
has also completed a protocol for the control and collection of has also completed a protocol for the control and collection of
one-way measurements, the One-way Active Measurement Protocol one-way measurements, the One-way Active Measurement Protocol
(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
or two-way measurements. or two-way measurements.
Two-way measurements are common in IP networks, primarily because Two-way measurements are common in IP networks, primarily because
skipping to change at page 7, line 45 skipping to change at page 7, line 45
timeout interval following the reception of the Stop-Sessions timeout interval following the reception of the Stop-Sessions
message. The Session-Reflector MUST NOT reflect packets that are message. The Session-Reflector MUST NOT reflect packets that are
received beyond the timeout. received beyond the timeout.
Type-P descriptor is as defined in OWAMP [RFC4656]. The only Type-P descriptor is as defined in OWAMP [RFC4656]. The only
capability of this field is to set the Differentiated Services Code capability of this field is to set the Differentiated Services Code
Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST
be used in test packets reflected by the Session-Reflector. be used in test packets reflected by the Session-Reflector.
Since there are no Schedule Slot Descriptions, the Request-Session Since there are no Schedule Slot Descriptions, the Request-Session
Message is followed by HMAC. This completes one logical message, Message is completed by MBZ and HMAC fields. This completes one
referred to as the Request-Session Command. logical message, referred to as the Request-Session Command.
The Session-Reflector MUST respond to each Request-Session Command The Session-Reflector MUST respond to each Request-Session Command
with an Accept-Message as defined in OWAMP [RFC4656]. The Port is with an Accept-Message as defined in OWAMP [RFC4656]. The Port is
the port to which TWAMP test packets are sent by the Session-Sender the port to which TWAMP test packets are sent by the Session-Sender
toward the Session-Reflector. In other words, the Port field toward the Session-Reflector. In other words, the Port field
indicates the port number where the Session-Reflector expects to indicates the port number where the Session-Reflector expects to
receive packets from the Session-Sender. receive packets from the Session-Sender.
3.6 Send Schedules 3.6 Send Schedules
skipping to change at page 12, line 11 skipping to change at page 12, line 11
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated and encrypted modes: For authenticated and encrypted modes:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IZP (12 octets) | | MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IZP (6 octets) | | MBZ (6 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IZP (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Sender Sequence Number | | Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IZP (12 octets) | | MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | | | Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IZP (6 octets) | | MBZ (6 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number is the sequence number of the test packet according Sequence Number is the sequence number of the test packet according
to its arrival at the Session-Reflector. It starts with zero and to its arrival at the Session-Reflector. It starts with zero and
is incremented by one for each subsequent packet. The Sequence is incremented by one for each subsequent packet. The Sequence
Number generated by the Session-Reflector is independent from the Number generated by the Session-Reflector is independent from the
sequence number of the arriving packets. sequence number of the arriving packets.
Timestamp and Error Estimate are the Session-Reflector's transmit Timestamp and Error Estimate are the Session-Reflector's transmit
timestamp and error estimate for the reflected test packet, timestamp and error estimate for the reflected test packet,
respectively. The format of all timestamp and error estimate respectively. The format of all timestamp and error estimate
fields follow the definition and formats defined by OWAMP[RFC4656]. fields follow the definition and formats defined by OWAMP[RFC4656].
skipping to change at page 13, line 50 skipping to change at page 14, line 7
maximum data integrity protection while in authenticated mode the maximum data integrity protection while in authenticated mode the
sequence numbers are encrypted and the timestamps are sent in clear sequence numbers are encrypted and the timestamps are sent in clear
text. Sending the timestamp in clear text in authenticated mode text. Sending the timestamp in clear text in authenticated mode
allows one to reduce the time between when a timestamp is obtained allows one to reduce the time between when a timestamp is obtained
by a reflector and when the packet is reflected out. In encrypted by a reflector and when the packet is reflected out. In encrypted
mode, both the sender and reflector have to fetch the timestamp, mode, both the sender and reflector have to fetch the timestamp,
encrypt it, and send it; in authenticated mode, the middle step is encrypt it, and send it; in authenticated mode, the middle step is
removed, potentially improving accuracy (the sequence number can be removed, potentially improving accuracy (the sequence number can be
encrypted before the timestamp is fetched). encrypted before the timestamp is fetched).
In authenticated mode, the first block (32 octets) of each packet In authenticated mode, the first block (16 octets) of each packet
is encrypted using AES Electronic Cookbook (ECB) mode. is encrypted using AES Electronic Cookbook (ECB) mode.
Obtaining the key, encryption method, and packet padding is as Obtaining the key, encryption method, and packet padding follows
defined in section 4.1.2 of OWAMP [RFC4656]. In unauthenticated the same procedure as OWAMP as described below.
mode, no encryption is applied. Similarly to each TWAMP-Control session, each TWAMP-Test session
has two keys: an AES Session-key and an HMAC Session-key. However,
there is a difference in how the keys are obtained: in the case of
TWAMP-Control, the keys are generated by the client and
communicated (as part of the Token) during connection setup as part
of Set-Up-Response message; in the case of TWAMP-Test, described
here, the keys are derived from the TWAMP-Control keys and the SID.
The TWAMP-Test AES Session-key is obtained as follows: the
TWAMP-Control AES Session-key (the same AES Session-key as is used
for the corresponding TWAMP-Control session, where it is used in a
different chaining mode) is encrypted, using AES, with the 16-octet
session identifier (SID) as the key; this is a single-block ECB
encryption; its result is the TWAMP-Test AES Session-key to use in
encrypting (and decrypting) the packets of the particular
TWAMP-Test session. Note that all of TWAMP-Test AES Session-key,
TWAMP-Control AES Session-key, and the SID are comprised of 16
octets.
The TWAMP-Test HMAC Session-key is obtained as follows: the
TWAMP-Control HMAC Session-key (the same HMAC Session-key as is
used for the corresponding TWAMP-Control session) is encrypted,
using AES, with the 16-octet session identifier (SID) as the key;
this is a two-block CBC encryption, always performed with IV=0; its
result is the TWAMP-Test HMAC Session-key to use in authenticating
the packets of the particular TWAMP-Test session. Note that all of
TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
comprised of 32 octets, while the SID is 16 octets.
ECB mode used for encrypting the first block of TWAMP-Test packets
in authenticated mode does not involve any actual chaining; this
way, lost, duplicated, or reordered packets do not cause problems
with deciphering any packet in an TWAMP-Test session.
In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The AES Session-key to use is obtained in the
same way as the key for authenticated mode. Each TWAMP-Test packet
is encrypted as a separate stream, with just one chaining
operation; chaining does not span multiple packets so that lost,
duplicated, or reordered packets do not cause problems. The
initialization vector for the CBC encryption is a value with all
bits equal to zero.
Implementation note: Naturally, the key schedule for each
TWAMP-Test session MAY be set up only once per session, not once
per packet.
HMAC in TWAMP-Test only covers the part of the packet that is also
encrypted. So, in authenticated mode, HMAC covers the first block
(16 octets); in encrypted mode, HMAC covers two first blocks (32
octets). In TWAMP-Test HMAC is not encrypted (note that this is
different from TWAMP-Control, where encryption in stream mode is
used, so everything including the HMAC blocks ends up being
encrypted).
In unauthenticated mode, no encryption or authentication is
applied.
Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers
mentioned in this document). However, implementations MUST provide
a configuration parameter, an option, or a different means of
making Packet Padding consist of all zeros.
5. Implementers Guide 5. Implementers Guide
This section serves as guidance to implementers of TWAMP. Two This section serves as guidance to implementers of TWAMP. Two
architectures are presented in this section for implementations architectures are presented in this section for implementations
where two hosts play the subsystem roles of TWAMP. Although only where two hosts play the subsystem roles of TWAMP. Although only
two architectures are presented here the protocol does not require two architectures are presented here the protocol does not require
their use. Similar to OWAMP [RFC4656] TWAMP is designed with their use. Similar to OWAMP [RFC4656] TWAMP is designed with
complete flexibility to allow different architectures that suite complete flexibility to allow different architectures that suite
multiple system requirements. multiple system requirements.
skipping to change at page 15, line 35 skipping to change at page 17, line 9
This example eliminates the need for the TWAMP-Control protocol and This example eliminates the need for the TWAMP-Control protocol and
assumes that the Session-Reflector is configured and communicates assumes that the Session-Reflector is configured and communicates
its configuration with the Server through non-standard means. The its configuration with the Server through non-standard means. The
Session-Reflector simply reflects the incoming packets back to the Session-Reflector simply reflects the incoming packets back to the
controller while copying the necessary information and generating controller while copying the necessary information and generating
sequence number and timestamp values per section 5.2.1. sequence number and timestamp values per section 5.2.1.
6. Security Considerations 6. Security Considerations
The security considerations of OWAMP [RFC4656] apply. Fundamentally TWAMP and OWAMP use the same protocol for
establishment of Control and Test procedures. The main difference
between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
vs. the Session-Receiver behavior in OWAMP. This difference in
behavior does not introduce any known security vulnerabilities that
are not already addressed by the security features of OWAMP. The
entire security considerations of OWAMP [RFC4656] applies to TWAMP.
7. Acknowledgements 7. Acknowledgements
We would like to thank Nagarjuna Venn, Sharee McNab, Nick Kinraid, We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
and Stanislav Shalunov for their comments, suggestions, reviews, and Stanislav Shalunov for their comments, suggestions, reviews,
helpful discussion and proof-reading. helpful discussion and proof-reading.
8. IANA Considerations 8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol which also OWAMP-Control part of the OWAMP [RFC4656] protocol which also
applies to the TWAMP-Control part of the TWAMP protocol. applies to the TWAMP-Control part of the TWAMP protocol.
9. Internationalization Considerations 9. Internationalization Considerations
The protocol does not carry any information in a natural language, The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in TWAMP-Control, which is with the possible exception of the KeyID in TWAMP-Control, which is
encoded in UTF-8. encoded in UTF-8.
skipping to change at page 17, line 49 skipping to change at page 19, line 35
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Ottawa, Ont K2H 8E9 Ottawa, Ont K2H 8E9
Canada Canada
Email: babiarz@nortel.com Email: babiarz@nortel.com
URI: http://www.nortel.com/ URI: http://www.nortel.com/
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
 End of changes. 20 change blocks. 
35 lines changed or deleted 106 lines changed or added

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