draft-ietf-ippm-twamp-06.txt   draft-ietf-ippm-twamp-07.txt 
Network Working Group K. Hedayat
K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: June 2008 R. Krzanowski Expires: Nov 2008 R. Krzanowski
Verizon Intended Status:Standards Track Verizon
K. Yum
Juniper Networks
A. Morton A. Morton
AT&T Labs AT&T Labs
K. Yum
Juniper Networks
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
December 2007 May 13, 2008
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-06 draft-ietf-ippm-twamp-07
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 42
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 IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The IP Performance Metrics (IPPM) working group's One-way Active The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides
Measurement Protocol [RFC4656] (OWAMP) provides a common protocol a common protocol for measuring one-way metrics between network
for measuring one-way metrics between network devices. OWAMP can devices. OWAMP can be used bi-directionally to measure one-way
be used bi-directionally to measure one-way metrics in both metrics in both directions between two network elements. However,
directions between two network elements. However, it does not it does not accommodate round-trip or two-way measurements. This
accommodate round-trip or two-way measurements. This memo memo specifies a Two-way Active Measurement Protocol (TWAMP), based
specifies a Two-way Active Measurement Protocol (TWAMP), based on on the OWAMP, that adds two-way or round-trip measurement
the OWAMP, that adds two-way or round-trip measurement
capabilities. The TWAMP measurement architecture is usually capabilities. The TWAMP measurement architecture is usually
comprised of two hosts with specific roles, and this allows for comprised of two hosts with specific roles, and this allows for
some protocol simplifications, making it an attractive alternative some protocol simplifications, making it an attractive alternative
in some circumstances. 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
1.3 Pronunciation Guide.......................................5
2. Protocol Overview.............................................5 2. Protocol Overview.............................................5
3. TWAMP Control.................................................5 3. TWAMP Control.................................................6
3.1 Connection Setup..........................................6 3.1 Connection Setup..........................................6
3.2 Integrity Protection......................................6 3.2 Integrity Protection......................................7
3.3 Value of the Accept Fields................................6 3.3 Value of the Accept Fields................................7
3.4 TWAMP Control Commands....................................6 3.4 TWAMP Control Commands....................................7
3.5 Creating Test Sessions....................................6 3.5 Creating Test Sessions....................................8
3.6 Send Schedules............................................9 3.6 Send Schedules...........................................10
3.7 Starting Test Sessions....................................9 3.7 Starting Test Sessions...................................10
3.8 Stop-Sessions.............................................9 3.8 Stop-Sessions............................................10
3.9 Fetch-Session.............................................9 3.9 Fetch-Session............................................11
4. TWAMP Test....................................................9 4. TWAMP Test...................................................11
4.1 Sender Behavior..........................................10 4.1 Sender Behavior..........................................12
4.2 Reflector Behavior.......................................10 4.2 Reflector Behavior.......................................12
5. Implementers Guide...........................................16 5. Implementers Guide...........................................19
5.1 Complete TWAMP...........................................17 6. Security Considerations......................................19
5.2 TWAMP Light..............................................17 7. Acknowledgements.............................................20
6. Security Considerations......................................18 8. IANA Considerations..........................................20
7. Acknowledgements.............................................18 8.1 Registry Specification...................................20
8. IANA Considerations..........................................19 8.2 Registry Management......................................21
8.1 Registry Specification...................................19 8.3 Experimental Numbers.....................................21
8.2 Registry Management......................................19 8.4 Initial Registry Contents................................21
8.3 Experimental Numbers.....................................20 9. Internationalization Considerations..........................21
8.4 Initial Registry Contents................................20 10. APPENDIX I - TWAMP Light (Informative)......................22
9. Internationalization Considerations..........................20 11. References..................................................23
10. References..................................................21 11.1 Normative References....................................23
10.1 Normative References....................................21 11.2 Informative References..................................23
10.2 Informative References..................................21
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has completed The Internet Engineering Task Force (IETF) has completed a Proposed
a draft standard for the round-trip delay [RFC2681] metric. IPPM standard for the round-trip delay [RFC2681] metric. IETF has also
has also completed a protocol for the control and collection of completed a protocol for the control and collection of one-way
one-way measurements, the One-way Active Measurement Protocol measurements, the One-way Active Measurement Protocol (OWAMP)
(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip [RFC4656]. However, OWAMP does not accommodate round-trip or two-
or two-way measurements. 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 synchronization between local and remote clocks is unnecessary for
measurement support at the remote end may be limited to a simple round-trip delay, and measurement support at the remote end may be
echo function. This memo specifies the Two-way Active Measurement limited to a simple echo function. This memo specifies the Two-way
Protocol, or TWAMP. TWAMP uses the methodology and architecture of Active Measurement Protocol, or TWAMP. TWAMP uses the methodology
OWAMP [RFC4656] to define an open protocol for measurement of and architecture of OWAMP [RFC4656] to define an open protocol for
two-way or round-trip metrics (henceforth in this document the term measurement of two-way or round-trip metrics (henceforth in this
two-way also signifies round-trip). The TWAMP measurement document the term two-way also signifies round-trip). The TWAMP
architecture is usually comprised of only two hosts with specific measurement architecture is usually comprised of only two hosts
roles, and this allows for some protocol simplifications, making it with specific roles, and this allows for some protocol
an attractive alternative to OWAMP in some circumstances. simplifications, making it 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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
| Control-Client |<--TWAMP Control-->| Server | | Control-Client |<--TWAMP Control-->| Server |
| | | | | | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector | | Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
Additionally, following the guidelines of OWAMP [RFC4656], TWAMP Additionally, following the guidelines of OWAMP [RFC4656], TWAMP
has been defined to allow for small test packets that would fit has been defined to allow for small test packets that would fit
inside the payload of a single ATM cell (only in unauthenticated inside the payload of a single ATM cell (only in unauthenticated
mode). mode).
1.3 Pronunciation Guide
The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
2. Protocol Overview 2. Protocol Overview
The Two-way Active Measurement Protocol is an open protocol for The Two-way Active Measurement Protocol is an open protocol for
measurement of two-way metrics. It is based on OWAMP [RFC4656] and measurement of two-way metrics. It is based on OWAMP [RFC4656] and
adheres to its overall architecture and design. The protocol adheres to its overall architecture and design. The TWAMP-control
defined in this document extends and changes OWAMP [RFC4656] as and TWAMP-Test protocols accomplish their testing tasks as outlined
follows: below:
- Define a new logical entity, Session-Reflector, in place of the - The Control-Client initiates a TCP connection on TWAMP's well-
Session-Receiver. known port, and the Server (its role now established) responds
with its greeting message indicating the security/integrity
mode(s) it is willing to support.
- Define the Session-Reflector behavior in place of the - The Control-Client responds with the chosen mode of
Session-Receiver behavior of OWAMP [RFC4656]. communication and information supporting integrity protection
and encryption, if the mode requires them. The Server responds
to accept the mode and start time. This completes the control
connection setup.
- Define a new test packet format for packets transmitted from the - The Control-Client requests (and describes) a test session with
Session-Reflector to Session-Sender. a unique TWAMP-Control message. The Server repsponds with its
acceptance and supporting information. More than one test
session may be requested with additional messages.
- Fetch client does not exist in the TWAMP architecture. - The Control-Client initiates all requested testing with a start
sessions message, and the Server acknowleges.
- The Session-Sender and the Session-Reflector exchange test
packets according to the TWAMP-Test protocol for each active
session.
- When appropriate, the Control-Client sends a message to stop all
test sessions.
There are two recognized extension mechanisms in the TWAMP
Protocol. The Modes field is used to establish the communication
options during TWAMP-Control Connection Setup. The TWAMP-Control
Command Number is another intended extension mechanism, allowing
additional commands to be defined in the future. TWAMP-Control
protocol addresses different levels of support between Control-
Client and Server.
All multi-octet quantities defined in this document are represented All multi-octet quantities defined in this document are represented
as unsigned integers in network byte order unless specified as unsigned integers in network byte order unless specified
otherwise. otherwise.
3. TWAMP Control 3. TWAMP Control
TWAMP-Control is a derivative of the OWAMP-Control for two-way TWAMP-Control is a derivative of the OWAMP-Control for two-way
measurements. All TWAMP Control messages are similar in format and measurements. All TWAMP Control messages are similar in format and
follow similar guidelines to those defined in section 3 of OWAMP follow similar guidelines to those defined in section 3 of OWAMP
[RFC4656] with the exceptions outlined in the following sections. [RFC4656] with the exceptions outlined in the following sections.
One such exception is the Fetch Session command, which is not used
All OWAMP [RFC4656] Control messages except for the Fetch-Session in 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 Modes field is a
identical to OWAMP. The only exception is the well-known port recognized extension mechanism in TWAMP, and the current mode
number for TWAMP-control. A client opens a TCP connection to the values are identical to those used in OWAMP. The only exception is
server on well-known port N (Refer to the IANA Considerations the well-known port number for TWAMP-control. A client opens a TCP
section below for the TWAMP-control port number assignment). The connection to the server on well-known port N (Refer to the IANA
host that initiates the TCP connection takes the roles of Considerations section below for the TWAMP-control port number
Control-Client and (in the two-host implementation) the assignment). The host that initiates the TCP connection takes the
roles of Control-Client and (in the two-host implementation) the
Session-Sender. The host that acknowledges the TCP connection Session-Sender. The host that acknowledges the TCP connection
accepts the roles of Server and (in the two-host implementation) accepts the roles of Server and (in the two-host implementation)
the Session Reflector. the Session Reflector.
The possibility exists for Control-Client failure after TWAMP-
Control connection establishment, or the path between the Control-
Client and Server may fail while a connection is in-progress. The
Server MAY discontinue any established control connection when no
packet associated with that connection, AND no packet associated
with any test sessions started by that control connection have been
received for SERVWAIT seconds. The default value of SERVWAIT SHALL
be 900 seconds, and this waiting time MAY be configurable. This
time-out allows a Server to free-up resources in case of failure.
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]. As in OWAMP, each HMAC sent covers
everything sent in a given direction between the previous HMAC (but
not including it) and up to the beginning of the new HMAC. This
way, once encryption is set up, each bit of the TWAMP-Control
connection is authenticated by an HMAC exactly once.
Note that the Server-Start message (sent by a Server during the
initial control connection exchanges) does not terminate with an
HMAC field. Therefore, the HMAC in the first Accept-Session message
also covers the Server-Start message and includes the Start-Time
field in the HMAC calculation.
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].
3.4 TWAMP Control Commands 3.4 TWAMP Control Commands
TWAMP control commands are as defined in section 3.4 of OWAMP TWAMP control commands conform to the rules defined in section 3.4
[RFC4656] except that the Fetch-Session command does not apply to of OWAMP [RFC4656]
TWAMP.
The following commands are available for the Control-client:
Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server
can send specific messages in response to the commands it receives
(as described in the sections that follow).
Note that the OWAMP Request-Session command is replaced by the
TWAMP Request-TW-Session command, and the Fetch-Session command
does not appear in TWAMP.
3.5 Creating Test Sessions 3.5 Creating Test Sessions
Test sessions creation follows the same procedure as defined in Test sessions creation follows the same procedure as defined in
section 3.5 of OWAMP [RFC4656]. section 3.5 of OWAMP [RFC4656].
In order to distinguish the session as a two-way versus a one-way
measurement session the first octet of the Request-Session command
MUST be set to 5. Value of 5 indicates that this is a
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-Control 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 SHOULD The Command Number value of 5 indicates a Request-TW-Session
Command, and the Server MUST interpret this command as a request
for a two-way test session using the TWAMP-Test protocol.
If a TWAMP Server receives an unexpected command number, it MUST
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 Accept-Session message. Command
numbers that are Forbidden (and possibly numbers that are Reserved)
are unexpected.
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 field and Conf-Receiver field MUST be set to 0 Both Conf-Sender field and Conf-Receiver field MUST be set to 0
since the Session-Reflector will both receive and send packets, and since the Session-Reflector will both receive and send packets, and
the roles 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 an improperly formatted command, and MUST respond with the
Accept field set to 3 (meaning "Some aspect of request is not
supported") in the Accept-Session message.
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
be sent and the port to which TWAMP-Test packets will be sent by be sent and the port to which TWAMP-Test packets will be sent by
the Session-Reflector (Session-Sender will use the same UDP port to the Session-Reflector (Session-Sender will use the same UDP port to
skipping to change at page 8, line 4 skipping to change at page 9, line 18
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 Control-Client to Server TWAMP-Control Message exchange MUST be
be used in the test packets. used in the test packets.
The Session Identifier (SID) is as defined in OWAMP [RFC4656]. The Session Identifier (SID) is as defined in OWAMP [RFC4656].
Since the SID is always generated by the receiving side, the Since the SID is always generated by the receiving side, the Server
Session-Reflector determines the SID, and the SID in the determines the SID, and the SID in the Request-TW-Session message
Request-Session message MUST be set to 0. 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 DSCP 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-TW-
Message is completed by MBZ (Must Be Zero) and HMAC (Hash Message Session Message is completed by MBZ (Must Be Zero) and HMAC (Hash
Authentication Code) fields. This completes one logical message, Message Authentication Code) fields. This completes one logical
referred to as the Request-Session Command. message, referred to as the Request-TW-Session Command.
The Session-Reflector MUST respond to each Request-Session Command The Session-Reflector MUST respond to each Request-TW-Session
with an Accept-Message as defined in OWAMP [RFC4656]. When the Command with an Accept-Message as defined in OWAMP [RFC4656]. When
Accept Field = 0, the Port field confirms (repeats) the port to the 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
use), the Server at the Session-Reflector MAY suggest an alternate use), the Server at the Session-Reflector MAY suggest an alternate
and available port for this session in the Port Field. The and available port for this session in the Port Field. The
Session-Sender either accepts the alternate port, or composes a new Session-Sender either accepts the alternate port, or composes a new
Session-Request message with suitable parameters. Otherwise, the Session-Request message with suitable parameters. Otherwise, the
skipping to change at page 9, line 21 skipping to change at page 10, line 32
Session-Sender as quickly as possible. Session-Sender as quickly as possible.
3.7 Starting Test Sessions 3.7 Starting Test Sessions
The procedure and guidelines for Starting test sessions is the same The procedure and guidelines for Starting test sessions is the same
as defined in section 3.7 of OWAMP [RFC4656]. as defined in section 3.7 of OWAMP [RFC4656].
3.8 Stop-Sessions 3.8 Stop-Sessions
The procedure and guidelines for Stopping test sessions is the same The procedure and guidelines for Stopping test sessions is the same
as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Sessions
command can only be issued by the Session-Sender. The Next SeqNo command can only be issued by the Control-Client. The message MUST
and Number of Skip Ranges MUST be set to 0 and the message MUST NOT NOT contain any session description records or skip ranges. The
contain any session description records or skip ranges. The
message is terminated with a single block HMAC, to complete the message is terminated with a single block HMAC, to complete the
Stop-Sessions Command. Stop-Sessions Command. Since the TWAMP Stop-Sessions command does
not convey SIDs, it applies to all sessions previously requested
and started with a Start-Sessions command.
Thus, the TWAMP Stop-Sessions command is constructed as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.9 Fetch-Session 3.9 Fetch-Session
The purpose of TWAMP is measurement of two-way metrics. Two-way The purpose of TWAMP is measurement of two-way metrics. Two-way
measurements do not rely on packet level data collected by the measurement methods do not require packet level data to be
Session-Reflector such as sequence number, timestamp, and TTL. As collected by the Session-Reflector (such as sequence number,
such the protocol does not require the retrieval of packet level timestamp, and TTL) because this data is communicated in the
data from the Server and the Fetch-Session command is not defined "reflected" test packets. As such the protocol does not require
in TWAMP. the retrieval of packet level data from the Server and the OWAMP
Fetch-Session command is not used in TWAMP.
4. TWAMP Test 4. TWAMP Test
The TWAMP test protocol is similar to the OWAMP [RFC4656] test The TWAMP test protocol is similar to the OWAMP [RFC4656] test
protocol with the exception that the Session-Reflector transmits protocol with the exception that the Session-Reflector transmits
test packets to the Session-Sender in response to each test packet test packets to the Session-Sender in response to each test packet
it receives. TWAMP defines two different test packet formats, one it receives. TWAMP defines two different test packet formats, one
for packets transmitted by the Session-Sender and one for packets for packets transmitted by the Session-Sender and one for packets
transmitted by the Session-Reflector. As with OWAMP [RFC4656] test transmitted by the Session-Reflector. As with OWAMP [RFC4656] test
protocol there are three modes: unauthenticated, authenticated, and protocol there are three modes: unauthenticated, authenticated, and
skipping to change at page 11, line 4 skipping to change at page 12, line 40
procedure and guidelines as defined in section 4.1.2 of OWAMP procedure and guidelines as defined in section 4.1.2 of OWAMP
[RFC4656] (with the exception of the reference to the Send [RFC4656] (with the exception of the reference to the Send
Schedule). Schedule).
4.2 Reflector Behavior 4.2 Reflector Behavior
TWAMP requires the Session-Reflector to transmit a packet to the TWAMP requires the Session-Reflector to transmit a packet to the
Session-Sender in response to each packet it receives. Session-Sender in response to each packet it receives.
As packets are received the Session-Reflector will, As packets are received the Session-Reflector will,
- Timestamp the received packet. Each packet that is actually - Timestamp the received packet. Each packet that is actually
received MUST have the best possible approximation of its real received MUST have the best possible approximation of its real
time of arrival entered as its timestamp (in the packet). time of arrival entered as its timestamp (in the packet).
- In authenticated or encrypted mode, decrypt the first block (16 - In authenticated or encrypted mode, decrypt the appropriate
octets) of the packet body. sections of the packet body (first block (16 octets) for
authenticated, 96 octets for encrypted), and then check
integrity of sections covered by the HMAC.
- Copy the packet sequence number into the corresponding reflected - Copy the packet sequence number into the corresponding reflected
packet to the Session-Sender. packet to the Session-Sender.
- Sender TTL value is extracted from the TTL/Hop Limit value of - Sender TTL value is extracted from the TTL/Hop Limit value of
received packets. Session-Reflector Implementations SHOULD received packets. Session-Reflector Implementations SHOULD
fetch the TTL/Hop Limit value from the IP header of the packet, fetch the TTL/Hop Limit value from the IP header of the packet,
replacing the value of 255 set by the Session-Sender. If an replacing the value of 255 set by the Session-Sender. If an
implementation does not fetch the actual TTL value (the only implementation does not fetch the actual TTL value (the only
good reason not to do so is an inability to access the TTL good reason not to do so is an inability to access the TTL
field of arriving packets), it MUST set the Sender TTL value as field of arriving packets), it MUST set the Sender TTL value as
255. 255.
- In authenticated and encrypted modes, the HMAC MUST be
calculated first, then the appropriate portion of the packet
body is encrypted.
- Transmit a test packet to the Session-Sender in response to - Transmit a test packet to the Session-Sender in response to
every received packet. The response MUST be generated as every received packet. The response MUST be generated as
immediately as possible. The format and content of the test immediately as possible. The format and content of the test
packet is defined in section 5.2.1. Prior to the transmission packet is defined in section 4.2.1. Prior to the transmission
of the test packet, the Session-Reflector MUST enter the best of the test packet, the Session-Reflector MUST enter the best
possible approximation of its actual sending time of as its possible approximation of its actual sending time of as its
Timestamp (in the packet). This permits the determination of Timestamp (in the packet). This permits the determination of
the elapsed time between the reception of the packet and its the elapsed time between the reception of the packet and its
transmission. transmission.
- Packets not received within the Timeout are ignored by the - Packets not received within the Timeout (following the Stop-
Session command) MUST be ignored by the
Reflector. The Session-Reflector MUST NOT generate a test Reflector. The Session-Reflector MUST NOT generate a test
packet to the Session-Sender for packets that are ignored. packet to the Session-Sender for packets that are ignored.
The possibility exists for Session-Sender failure during a session,
or the path between the Session-Sender and Session-Reflector may
fail while a test session is in-progress. The Session-Reflector MAY
discontinue any session which has been Started when no packet
associated with that session has been received for REFWAIT seconds.
The default value of REFWAIT SHALL be 900 seconds, and this waiting
time MAY be configurable. This time-out allows a Session-Reflector
to free-up resources in case of failure.
4.2.1 TWAMP-Test Packet Format and Content 4.2.1 TWAMP-Test Packet Format and Content
The Session-Reflector MUST transmit a packet to the Session-Sender The Session-Reflector MUST transmit a packet to the Session-Sender
in response to each packet received. The Session-Reflector SHOULD in response to each packet received. The Session-Reflector SHOULD
transmit the packets as immediately as possible. The transmit the packets as immediately as possible. The
Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)
in the UDP packet to 255. in the UDP packet to 255.
The test packet will have the necessary information for calculating The test packet will have the necessary information for calculating
two-way metrics by the Session-Sender. The format of the test two-way metrics by the Session-Sender. The format of the test
skipping to change at page 12, line 26 skipping to change at page 14, line 41
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number | | Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ | | Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | | | Sender TTL | |
+++++++++++++++++ | +-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
skipping to change at page 13, line 19 skipping to change at page 15, line 19
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) | | MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number | | Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | | | Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) | | MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | | | Sender TTL | |
+++++++++++++++++ | +-+-+-+-+-+-+-+-+ +
| | | |
| | | |
| MBZ (15 octets) | | MBZ (15 octets) |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that all Timestamps have the same format as OWAMP [RFC4656] as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number is the sequence number of the test packet according Sequence Number is the sequence number of the test packet according
to its transmit order.It starts with zero and is incremented by one to its transmit order. It starts with zero and is incremented by
for each subsequent packet. The Sequence Number generated by the one for each subsequent packet. The Sequence Number generated by
Session-Reflector is independent from the sequence number of the the Session-Reflector is independent from the sequence number of
arriving packets. 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].
Sender Timestamp and Sender Error Estimate are exact copies of the Sender Timestamp and Sender Error Estimate are exact copies of the
timestamp and error estimate from the Session-Sender test packet timestamp and error estimate from the Session-Sender test packet
that corresponds to this test packet. that corresponds to this test packet.
skipping to change at page 15, line 17 skipping to change at page 17, line 27
however, different. The difference is that in encrypted mode both however, different. The difference is that in encrypted mode both
the sequence numbers and timestamps are encrypted to provide the sequence numbers and timestamps are encrypted to provide
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). Authenticated mode
permits the timestamp to be fetched after a portion of the packet
is encrypted. Thus, the main differences between authenticated mode
and encrypted mode are the portions of the test packets that are
covered by HMAC and encrypted.
In authenticated mode, the first block (16 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 follows Obtaining the key, encryption method, and packet padding follows
the same procedure as OWAMP as described below. the same procedure as OWAMP as described below.
Similarly to each TWAMP-Control session, each TWAMP-Test session Similarly to each TWAMP-Control session, each TWAMP-Test session
has two keys: an AES Session-key and an HMAC Session-key. However, 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 there is a difference in how the keys are obtained: in the case of
TWAMP-Control, the keys are generated by the client and TWAMP-Control, the keys are generated by the client and
skipping to change at page 16, line 20 skipping to change at page 18, line 32
In encrypted mode, the first six blocks (96octets) are encrypted In encrypted mode, the first six blocks (96octets) are encrypted
using AES CBC mode. The AES Session-key to use is obtained in the 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 same way as the key for authenticated mode. Each TWAMP-Test packet
is encrypted as a separate stream, with just one chaining is encrypted as a separate stream, with just one chaining
operation; chaining does not span multiple packets so that lost, operation; chaining does not span multiple packets so that lost,
duplicated, or reordered packets do not cause problems. The duplicated, or reordered packets do not cause problems. The
initialization vector for the CBC encryption is a value with all initialization vector for the CBC encryption is a value with all
bits equal to zero. bits equal to zero.
Implementation note: Naturally, the key schedule for each Implementation note: Naturally, the key schedule for each
TWAMP-Test session MAY be set up only once per session, not once TWAMP-Test session MUST be set up at most once per session, not
per packet. once per packet.
HMAC in TWAMP-Test only covers the part of the packet that is also HMAC in TWAMP-Test only covers the part of the packet that is also
encrypted. So, in authenticated mode, HMAC covers the first block encrypted. So, in authenticated mode, HMAC covers the first block
(16 octets); in encrypted mode, HMAC covers two first blocks (32 (16 octets); in encrypted mode, HMAC covers the first six blocks
octets). In TWAMP-Test HMAC is not encrypted (note that this is (96 octets). In TWAMP-Test HMAC is not encrypted (note that this
different from TWAMP-Control, where encryption in stream mode is is different from TWAMP-Control, where encryption in stream mode is
used, so everything including the HMAC blocks ends up being used, so everything including the HMAC blocks ends up being
encrypted). encrypted).
In unauthenticated mode, no encryption or authentication is In unauthenticated mode, no encryption or authentication is
applied. applied.
Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers generated independently of any other pseudo-random numbers
mentioned in this document). However, implementations MUST provide mentioned in this document). However, implementations MUST provide
a configuration parameter, an option, or a different means of a configuration parameter, an option, or a different means of
making Packet Padding consist of all zeros. 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. The
architectures are presented in this section for implementations example architecture presented here is not a requirement. Similar
where two hosts play the subsystem roles of TWAMP. Although only to OWAMP [RFC4656], TWAMP is designed with enough flexibility to
two architectures are presented here the protocol does not require allow different architectures that suit multiple system
their use. Similar to OWAMP [RFC4656] TWAMP is designed with requirements.
complete flexibility to allow different architectures that suite
multiple system requirements.
5.1 Complete TWAMP
In this example the roles of Control-Client and Session-Sender are In this example the roles of Control-Client and Session-Sender are
implemented in one host referred to as the controller and the roles implemented in one host referred to as the controller and the roles
of Server and Session-Reflector are implemented in another host of Server and Session-Reflector are implemented in another host
referred to as the responder. referred to as the responder.
controller responder controller responder
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| Control-Client |<--TWAMP-Control-->| Server | | Control-Client |<--TWAMP-Control-->| Server |
| | | | | | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector | | Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
This example provides an architecture that supports the full TWAMP This example provides an architecture that supports the full TWAMP
standard. The controller establishes the test session with the standard. The controller establishes the test session with the
responder through the TWAMP-Control protocol. After the session is responder through the TWAMP-Control protocol. After the session is
established the controller transmits test packets to the responder. established the controller transmits test packets to the responder.
The responder follows the Session-Reflctor behavior of TWAMP as
described in section 4.2.
5.2 TWAMP Light
In this example the roles of Control-Client, Server, and
Session-Sender are implemented in one host referred to as the
controller and the role of Session-Reflector is implemented in
another host referred to as the responder.
controller responder
+-----------------+ +-------------------+
| Server |<----------------->| |
| Control-Client | | Session-Reflector |
| Session-Sender |<--TWAMP-Test----->| |
+-----------------+ +-------------------+
This example provides a simple architecture for responders where
their role will be to simply act as light test points in the
network. The controller establishes the test session with the
Server through non-standard means. After the session is
established the controller transmits test packets to the responder.
The responder follows the Session-Reflector behavior of TWAMP as The responder follows the Session-Reflector behavior of TWAMP as
described in section 4.2 with the following exceptions. described in section 4.2.
In the case of TWAMP Light, the Session-Reflector does not
necessarily have knowledge of the session state. IF the
Session-Reflector does not have knowledge of the session state,
THEN the Session-Reflector MUST copy the Sequence Number of the
received packet to the Sequence Number field of the reflected
packet. The controller receives the reflected test packets and
collects two-way metrics. This architecture allows for collection
of two-way metrics.
This example eliminates the need for the TWAMP-Control protocol and Appendix I provides an example for purely informational purposes.
assumes that the Session-Reflector is configured and communicates It suggests an incremental path to adopting TWAMP, by implementing
its configuration with the Server through non-standard means. The the TWAMP-Test protocol first.
Session-Reflector simply reflects the incoming packets back to the
controller while copying the necessary information and generating
sequence number and timestamp values per section 4.2.1.
6. Security Considerations 6. Security Considerations
Fundamentally TWAMP and OWAMP use the same protocol for Fundamentally TWAMP and OWAMP use the same protocol for
establishment of Control and Test procedures. The main difference establishment of Control and Test procedures. The main difference
between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
vs. the Session-Receiver behavior in OWAMP. This difference in vs. the Session-Receiver behavior in OWAMP. This difference in
behavior does not introduce any known security vulnerabilities that behavior does not introduce any known security vulnerabilities that
are not already addressed by the security features of OWAMP. The are not already addressed by the security features of OWAMP. The
entire security considerations of OWAMP [RFC4656] applies to TWAMP. entire security considerations of OWAMP [RFC4656] applies to TWAMP.
The only area where TWAMP may introduce new security considerations
is the TWAMP Light version described above. The non-standard means
to control the responder and establish test sessions SHOULD offer
the features listed below.
The non-standard responder control protocol SHOULD have an
authenticated mode of operation. The responder SHOULD be
configurable to accept only authenticated control sessions.
The non-standard responder control protocol SHOULD have a means to
activate the authenticated and encrypted modes of the TWAMP-Test
protocol.
7. Acknowledgements 7. Acknowledgements
We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
Stanislav Shalunov, Matt Zekauskas, Walt Steverson and Jeff Boote Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and
for their comments, suggestions, reviews, helpful discussion and Murtaza Chiba for their comments, suggestions, reviews, helpful
proof-reading. 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. OWAMP-Control part of the OWAMP [RFC4656] protocol.
... ...
owamp-control 861/tcp OWAMP-Control owamp-control 861/tcp OWAMP-Control
owamp-control 861/udp OWAMP-Control owamp-control 861/udp OWAMP-Control
# [RFC4656] # [RFC4656]
# 862-872 Unassigned # 862-872 Unassigned
skipping to change at page 19, line 35 skipping to change at page 20, line 40
Since TWAMP adds an additional Control command to the OWAMP-Control Since TWAMP adds an additional Control command to the OWAMP-Control
specification, and describes behavior when this control command is specification, and describes behavior when this control command is
used, this memo requests creation an IANA registry for the TWAMP used, this memo requests creation an IANA registry for the TWAMP
Command Number field. The field is not explicitly named in Command Number field. The field is not explicitly named in
[RFC4656] but is called out for each command. This field is a [RFC4656] but is called out for each command. This field is a
recognized extension mechanism for TWAMP. recognized extension mechanism for TWAMP.
8.1 Registry Specification 8.1 Registry Specification
IANA will create an TWAMP-Control Command registry. TWAMP-Control IANA will create an TWAMP-Control Command Number registry. TWAMP-
commands are specified by the first octet in OWAMP-Control messages Control commands are specified by the first octet in OWAMP-Control
as shown in section 3.4 of [RFC4656], and modified by this messages as shown in section 3.5 of [RFC4656], and modified by this
document. Thus this registry may contain sixteen possible values. document. Thus this registry may contain sixteen possible values.
8.2 Registry Management 8.2 Registry Management
Because the registry may only contain sixteen values, and because Because the registry may only contain sixteen values, and because
OWAMP and TWAMP are IETF protocols, this registry must only be OWAMP and TWAMP are IETF protocols, this registry must only be
updated by "IETF Consensus" as specified in [RFC2434] -- an RFC updated by "IETF Consensus" as specified in [RFC2434] -- an RFC
documenting the use that is approved by the IESG. We expect that documenting the use that is approved by the IESG. We expect that
new values will be assigned as monotonically increasing integers in new values will be assigned as monotonically increasing integers in
the range [0-15], unless there is a good reason to do otherwise. the range [0-15], unless there is a good reason to do otherwise.
8.3 Experimental Numbers 8.3 Experimental Numbers
[RFC3692] recommends allocating an appropriate number of values for [RFC3692] recommends allocating an appropriate number of values for
experimentation and testing. It is not clear to the authors experimentation and testing. It is not clear to the authors
exactly how many might be useful in this space, nor if it would be exactly how many numbers might be useful in this space, nor if it
useful that they were easily distinguishable or at the "high end" would be useful that they were easily distinguishable or at the
of the number range. Two might be useful, say one for session "high end" of the number range. Two might be useful, say one for
control, and one for session fetch. On the other hand, a single session control, and one for session fetch. On the other hand, a
number would allow for unlimited extension, because the format of single number would allow for unlimited extension, because the
the rest of the message could be tailored, with allocation of other format of the rest of the message could be tailored, with
numbers done once usefulness has been proven. Thus, this document allocation of other numbers done once usefulness has been proven.
will allocate one number, the next sequential number 6, as Thus, this document will allocate one number, the next sequential
designated for experimentation and testing. number 6, as designated for experimentation and testing.
8.4 Initial Registry Contents 8.4 Initial Registry Contents
TWAMP-Control Command Registry TWAMP-Control Command Number Registry
Value Description Semantics Definition Value Description Semantics Definition
0 Reserved 0 Reserved
1 Forbidden 1 Forbidden
2 Start-Sessions RFC4656, Section 3.7 2 Start-Sessions RFC4656, Section 3.7
3 Stop-Sessions RFC4656, Section 3.8 3 Stop-Sessions RFC4656, Section 3.8
4 Fetch-Session RFC4656, Section 3.9 4 Reserved
5 Request-TW-Session this document, Section 3.5 5 Request-TW-Session this document, Section 3.5
6 Experimentation undefined, see Section 8.3. 6 Experimentation undefined, see Section 8.3.
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.
10. References 10. APPENDIX I - TWAMP Light (Informative)
10.1 Normative References In this example the roles of Control-Client, Server, and
Session-Sender are implemented in one host referred to as the
controller and the role of Session-Reflector is implemented in
another host referred to as the responder.
controller responder
+-----------------+ +-------------------+
| Server |<----------------->| |
| Control-Client | | Session-Reflector |
| Session-Sender |<--TWAMP-Test----->| |
+-----------------+ +-------------------+
This example provides a simple architecture for responders where
their role will be to simply act as light test points in the
network. The controller establishes the test session with the
Server through non-standard means. After the session is
established the controller transmits test packets to the responder.
The responder follows the Session-Reflector behavior of TWAMP as
described in section 4.2 with the following exceptions.
In the case of TWAMP Light, the Session-Reflector does not
necessarily have knowledge of the session state. IF the
Session-Reflector does not have knowledge of the session state,
THEN the Session-Reflector MUST copy the Sequence Number of the
received packet to the Sequence Number field of the reflected
packet. The controller receives the reflected test packets and
collects two-way metrics. This architecture allows for collection
of two-way metrics.
This example eliminates the need for the TWAMP-Control protocol and
assumes that the Session-Reflector is configured and communicates
its configuration with the Server through non-standard means. The
Session-Reflector simply reflects the incoming packets back to the
controller while copying the necessary information and generating
sequence number and timestamp values per section 4.2.1.
TWAMP Light introduces some additional security considerations. The
non-standard means to control the responder and establish test
sessions SHOULD offer the features listed below.
The non-standard responder control protocol SHOULD have an
authenticated mode of operation. The responder SHOULD be
configurable to accept only authenticated control sessions.
The non-standard responder control protocol SHOULD have a means to
activate the authenticated and encrypted modes of the TWAMP-Test
protocol.
11. References
11.1 Normative References
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
Zekauskas, M., "A One-way Active Measurement Protocol Zekauskas, M., "A One-way Active Measurement Protocol
(OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. (OWAMP)", RFC 4656, October 2004.
[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A
Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,
September 1999. September 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Definition of the Differentiated Services Field (DS Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
an IANA Considerations Section in RFCs, RFC 2474, an IANA Considerations Section in RFCs, RFC 2434,
October 1998. October 1998.
10.2 Informative References 11.2 Informative References
[RFC3692] Narten, T., Assigning Experimental and Testing Numbers [RFC3692] Narten, T., Assigning Experimental and Testing Numbers
Considered Useful, RFC 3692, January 2004. Considered Useful, RFC 3692, January 2004.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824
skipping to change at page 21, line 41 skipping to change at page 24, line 12
[RFC3692] Narten, T., Assigning Experimental and Testing Numbers [RFC3692] Narten, T., Assigning Experimental and Testing Numbers
Considered Useful, RFC 3692, January 2004. Considered Useful, RFC 3692, January 2004.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824
USA USA
EMail: khedayat@brixnet.com EMail: khedayat@brixnet.com
URI: http://www.brixnet.com/ URI: http://www.brixnet.com/
Roman M. Krzanowski, Ph.D. Roman M. Krzanowski, Ph.D.
Verizon Verizon
500 Westchester Ave. 500 Westchester Ave.
White Plains, NY White Plains, NY
USA USA
EMail: roman.krzanowski@verizon.com EMail: roman.krzanowski@verizon.com
URI: http://www.verizon.com/ URI: http://www.verizon.com/
Al Morton Al Morton
AT&T Labs AT&T Labs
Room D3 - 3C06 Room D3 - 3C06
200 Laurel Ave. South 200 Laurel Ave. South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone +1 732 420 1571 Phone +1 732 420 1571
EMail: acmorton@att.com EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/ URI: http://home.comcast.net/~acmacm/
Kiho Yum Kiho Yum
Juniper Networks Juniper Networks
1194 Mathilda Ave. 1194 Mathilda Ave.
Sunnyvale, CA Sunnyvale, CA
USA USA
EMail: kyum@juniper.net EMail: kyum@juniper.net
URI: http://www.juniper.com/ URI: http://www.juniper.com/
Jozef Z. Babiarz Jozef Z. Babiarz
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 IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 End of changes. 76 change blocks. 
224 lines changed or deleted 327 lines changed or added

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