draft-ietf-ippm-twamp-05.txt   draft-ietf-ippm-twamp-06.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: May 2008 R. Krzanowski Expires: June 2008 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 2007 December 2007
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-05 draft-ietf-ippm-twamp-06
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 2, line 7 skipping to change at page 2, line 7
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 IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP) The IP Performance Metrics (IPPM) working group's One-way Active
provides a common protocol for measuring one-way metrics between Measurement Protocol [RFC4656] (OWAMP) provides a common protocol
network devices. OWAMP can be used bi-directionally to measure for measuring one-way metrics between network devices. OWAMP can
one-way metrics in both directions between two network elements. be used bi-directionally to measure one-way metrics in both
However, it does not accommodate round-trip or two-way directions between two network elements. However, it does not
measurements. This memo specifies a Two-way Active Measurement accommodate round-trip or two-way measurements. This memo
Protocol (TWAMP), based on the OWAMP, that adds two-way or specifies a Two-way Active Measurement Protocol (TWAMP), based on
round-trip measurement capabilities. The TWAMP measurement the OWAMP, that adds two-way or round-trip measurement
architecture is usually comprised of two hosts with specific roles, capabilities. The TWAMP measurement architecture is usually
and this allows for some protocol simplifications, making it an comprised of two hosts with specific roles, and this allows for
attractive alternative in some circumstances. some protocol simplifications, making it an attractive alternative
in some circumstances.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1 Relationship of Test and Control Protocols................3 1.1 Relationship of Test and Control Protocols................3
1.2 Logical Model.............................................3 1.2 Logical Model.............................................3
2. Protocol Overview.............................................5 2. Protocol Overview.............................................5
3. TWAMP Control.................................................5 3. TWAMP Control.................................................5
3.1 Connection Setup..........................................5 3.1 Connection Setup..........................................6
3.2 Integrity Protection......................................6 3.2 Integrity Protection......................................6
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............................................9
3.7 Starting Test Sessions....................................8 3.7 Starting Test Sessions....................................9
3.8 Stop-Sessions.............................................9 3.8 Stop-Sessions.............................................9
3.9 Fetch-Session.............................................9 3.9 Fetch-Session.............................................9
4. TWAMP Test....................................................9 4. TWAMP Test....................................................9
4.1 Sender Behavior...........................................9 4.1 Sender Behavior..........................................10
4.2 Reflector Behavior.......................................10 4.2 Reflector Behavior.......................................10
5. Implementers Guide...........................................16 5. Implementers Guide...........................................16
5.1 Complete TWAMP...........................................17 5.1 Complete TWAMP...........................................17
5.2 TWAMP Light..............................................17 5.2 TWAMP Light..............................................17
6. Security Considerations......................................18 6. Security Considerations......................................18
7. Acknowledgements.............................................18 7. Acknowledgements.............................................18
8. IANA Considerations..........................................19 8. IANA Considerations..........................................19
8.1 Registry Specification...................................19
8.2 Registry Management......................................19
8.3 Experimental Numbers.....................................20
8.4 Initial Registry Contents................................20
9. Internationalization Considerations..........................20 9. Internationalization Considerations..........................20
10. References..................................................21 10. References..................................................21
10.1 Normative References....................................21 10.1 Normative References....................................21
10.2 Informative References..................................21
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
time accuracy is less demanding for round-trip delay, and time accuracy is less demanding for round-trip delay, and
measurement support at the remote end may be limited to a simple measurement support at the remote end may be limited to a simple
echo function. This memo specifies the Two-way Active Measurement echo function. This memo specifies the Two-way Active Measurement
Protocol, or TWAMP. TWAMP uses the methodology and architecture of Protocol, or TWAMP. TWAMP uses the methodology and architecture of
OWAMP [RFC4656] to define an open protocol for measurement of OWAMP [RFC4656] to define an open protocol for measurement of
two-way or round-trip metrics (henceforth in this document the term two-way or round-trip metrics (henceforth in this document the term
two-way also signifies round-trip). The TWAMP measurement two-way also signifies round-trip). The TWAMP measurement
architecture is usually comprised of only two hosts with specific architecture is usually comprised of only two hosts with specific
roles, and this allows for some protocol simplifications, making it roles, and this allows for some protocol simplifications, making it
an attractive alternative in some circumstances. an attractive alternative to OWAMP in some circumstances.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119]. RFC 2119 [RFC2119].
1.1 Relationship of Test and Control Protocols 1.1 Relationship of Test and Control Protocols
Similar to OWAMP [RFC4656], TWAMP consists of two inter-related Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
protocols: TWAMP-Control and TWAMP-Test. The relationship of these protocols: TWAMP-Control and TWAMP-Test. The relationship of these
protocols is as defined in section 1.1 of OWAMP [RFC4656]. protocols is as defined in section 1.1 of OWAMP [RFC4656].
TWAMP-Control is used to initiate, start, and stop test sessions,
whereas TWAMP-Test is used to exchange test packets between two
TWAMP entities.
1.2 Logical Model 1.2 Logical Model
The role and definition of the logical entities are as defined in The role and definition of the logical entities are as defined in
section 1.2 of OWAMP [RFC4656] with the following exceptions: section 1.2 of OWAMP [RFC4656] with the following exceptions:
- The Session-Receiver is called the Session-Reflector in the - The Session-Receiver is called the Session-Reflector in the
TWAMP architecture. The Session-Reflector has the capability TWAMP architecture. The Session-Reflector has the capability
to create and send a measurement packet when it receives a to create and send a measurement packet when it receives a
measurement packet. Unlike the Session-Receiver, the measurement packet. Unlike the Session-Receiver, the
Session-Reflector does not collect any packet information. Session-Reflector does not collect any packet information.
- The Server is an end system that manages one or more TWAMP - The Server is an end system that manages one or more TWAMP
skipping to change at page 6, line 8 skipping to change at page 6, line 16
command apply to TWAMP. command apply to TWAMP.
3.1 Connection Setup 3.1 Connection Setup
Connection establishment of TWAMP follows the same procedure Connection establishment of TWAMP follows the same procedure
defined in section 3.1 of OWAMP [RFC4656]. The mode values are defined in section 3.1 of OWAMP [RFC4656]. The mode values are
identical to OWAMP. The only exception is the well-known port identical to OWAMP. The only exception is the well-known port
number for TWAMP-control. A client opens a TCP connection to the number for TWAMP-control. A client opens a TCP connection to the
server on well-known port N (Refer to the IANA Considerations server on well-known port N (Refer to the IANA Considerations
section below for the TWAMP-control port number assignment). The section below for the TWAMP-control port number assignment). The
host that initiates the TCP connection takes the roles of Control- host that initiates the TCP connection takes the roles of
Client and (in the two-host implementation) the Session-Sender. Control-Client and (in the two-host implementation) the
The host that acknowledges the TCP connection accepts the roles of Session-Sender. The host that acknowledges the TCP connection
Server and (in the two-host implementation) the Session Reflector. accepts the roles of Server and (in the two-host implementation)
the Session Reflector.
3.2 Integrity Protection 3.2 Integrity Protection
Integrity protection of TWAMP follows the same procedure defined in Integrity protection of TWAMP follows the same procedure defined in
section 3.2 of OWAMP [RFC4656]. section 3.2 of OWAMP [RFC4656].
3.3 Value of the Accept Fields 3.3 Value of the Accept Fields
Accept values used in TWAMP are the same as the values defined in Accept values used in TWAMP are the same as the values defined in
section 3.3 of OWAMP [RFC4656]. section 3.3 of OWAMP [RFC4656].
skipping to change at page 7, line 5 skipping to change at page 7, line 15
In order to distinguish the session as a two-way versus a one-way In order to distinguish the session as a two-way versus a one-way
measurement session the first octet of the Request-Session command measurement session the first octet of the Request-Session command
MUST be set to 5. Value of 5 indicates that this is a MUST be set to 5. Value of 5 indicates that this is a
Request-Session for a two-way metrics measurement session. Request-Session for a two-way metrics measurement session.
In TWAMP, the first octet is referred to as the Command Number, and In TWAMP, the first octet is referred to as the Command Number, and
the Command Number is a recognized extension mechanism. Readers are the Command Number is a recognized extension mechanism. Readers are
encouraged to consult the TWAMP Command Number Registry to encouraged to consult the TWAMP Command Number Registry to
determine if there have been additional values assigned. determine if there have been additional values assigned.
If a TWAMP server receives an unexpected command number, it MUST If a TWAMP server receives an unexpected command number, it SHOULD
respond with the Accept field set to 3 (meaning "Some aspect of respond with the Accept field set to 3 (meaning "Some aspect of
request is not supported") in the Server-Start message. request is not supported") in the Server-Start message.
In OWAMP, the Conf-Sender field is set to 1 when the In OWAMP, the Conf-Sender field is set to 1 when the
Request-Session message describes a task where the Server will Request-Session message describes a task where the Server will
configure a one-way test packet sender. Likewise, the configure a one-way test packet sender. Likewise, the
Conf-Receiver field is set to 1 when the message describes the Conf-Receiver field is set to 1 when the message describes the
configuration for a Session-Receiver. In TWAMP, both endpoints configuration for a Session-Receiver. In TWAMP, both endpoints
perform in these roles, with the Session-Sender first sending and perform in these roles, with the Session-Sender first sending and
then receiving test packets. The Session-Reflector first receives then receiving test packets. The Session-Reflector first receives
the test packets, and returns each test packet to the the test packets, and returns each test packet to the
Session-Sender as fast as possible. Session-Sender as fast as possible.
Both Conf-Sender and Conf-Receiver MUST be set to 0 since the Both Conf-Sender field and Conf-Receiver field MUST be set to 0
Session-Reflector will both receive and send packets, and the roles since the Session-Reflector will both receive and send packets, and
are established according to which host initiates the TCP the roles are established according to which host initiates the TCP
connection for control. The server MUST interpret any non-zero connection for control. The server MUST interpret any non-zero
value as zero. value as zero.
The Session-Reflector in TWAMP does not process incoming test The Session-Reflector in TWAMP does not process incoming test
packets for performance metrics and consequently does not need to packets for performance metrics and consequently does not need to
know the number of incoming packets and their timing schedule. know the number of incoming packets and their timing schedule.
Consequently the Number of Scheduled Slots and Number of Packets Consequently the Number of Scheduled Slots and Number of Packets
MUST be set to 0. MUST be set to 0.
The Sender Port is the UDP port from which TWAMP-Test packets will The Sender Port is the UDP port from which TWAMP-Test packets will
skipping to change at page 7, line 44 skipping to change at page 8, line 4
send and receive packets). Receiver Port is the desired UDP port send and receive packets). Receiver Port is the desired UDP port
to which TWAMP test packets will be sent by the Session-Sender (the to which TWAMP test packets will be sent by the Session-Sender (the
port where the Session-Reflector is asked to receive test packets). port where the Session-Reflector is asked to receive test packets).
Receiver Port is also the UDP port from which TWAMP test packets Receiver Port is also the UDP port from which TWAMP test packets
will be sent by the Session-Reflector (Session-Reflector will use will be sent by the Session-Reflector (Session-Reflector will use
the same UDP port to send and receive packets). the same UDP port to send and receive packets).
The Sender Address and Receiver Address fields contain, The Sender Address and Receiver Address fields contain,
respectively, the sender and receiver addresses of the endpoints of respectively, the sender and receiver addresses of the endpoints of
the Internet path over which a TWAMP test session is requested. the Internet path over which a TWAMP test session is requested.
They MAY be set to 0, in which case the IP addresses used for the They MAY be set to 0, in which case the IP addresses used for the
Session-Sender to Session-Reflector Control Message exchange MUST Session-Sender to Session-Reflector Control Message exchange MUST
be used in the test packets. be used in the test packets.
The SID is as defined in OWAMP [RFC4656]. Since the SID is always The Session Identifier (SID) is as defined in OWAMP [RFC4656].
generated by the receiving side, the Session-Reflector determines Since the SID is always generated by the receiving side, the
the SID, and the SID in the Request-Session message MUST be set to Session-Reflector determines the SID, and the SID in the
0. Request-Session message MUST be set to 0.
The Start Time is as as defined in OWAMP [RFC4656]. The Start Time is as as defined in OWAMP [RFC4656].
The Timeout is interpreted differently from the definition in OWAMP The Timeout is interpreted differently from the definition in OWAMP
[RFC4656]. In TWAMP, Timeout is the interval that the [RFC4656]. In TWAMP, Timeout is the interval that the
Session-Reflector MUST wait after receiving a Stop-Sessions Session-Reflector MUST wait after receiving a Stop-Sessions
message. In case there are test packets still in transit, the message. In case there are test packets still in transit, the
Session Reflector MUST reflect them if they arrive within the Session Reflector MUST reflect them if they arrive within the
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 completed by MBZ and HMAC fields. This completes one Message is completed by MBZ (Must Be Zero) and HMAC (Hash Message
logical message, referred to as the Request-Session Command. Authentication Code) fields. This completes one 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]. When the with an Accept-Message as defined in OWAMP [RFC4656]. When the
Accept Field = 0, the Port field confirms (repeats) the port to Accept Field = 0, the Port field confirms (repeats) the port to
which TWAMP test packets are sent by the Session-Sender toward the which TWAMP test packets are sent by the Session-Sender toward the
Session-Reflector. In other words, the Port field indicates the Session-Reflector. In other words, the Port field indicates the
port number where the Session-Reflector expects to receive packets port number where the Session-Reflector expects to receive packets
from the Session-Sender. from the Session-Sender.
When the requested Receiver Port is not available (e.g., port in When the requested Receiver Port is not available (e.g., port in
 End of changes. 18 change blocks. 
34 lines changed or deleted 46 lines changed or added

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