draft-ietf-ippm-twamp-09.txt   rfc5357.txt 
Network Working Group K. Hedayat Network Working Group K. Hedayat
Internet Draft Brix Networks Request for Comments: 5357 Brix Networks
Expires: Jan 2009 R. Krzanowski Category: Standards Track R. Krzanowski
Intended Status:Standards Track Verizon Verizon
A. Morton A. Morton
AT&T Labs AT&T Labs
K. Yum K. Yum
Juniper Networks Juniper Networks
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
July 30, 2008 October 2008
A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-09
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at A Two-Way Active Measurement Protocol (TWAMP)
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2008). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides The One-way Active Measurement Protocol (OWAMP), specified in RFC
a common protocol for measuring one-way metrics between network 4656, provides a common protocol for measuring one-way metrics
devices. OWAMP can be used bi-directionally to measure one-way between network devices. OWAMP can be used bi-directionally to
metrics in both directions between two network elements. However, measure one-way metrics in both directions between two network
it does not accommodate round-trip or two-way measurements. This elements. However, it does not accommodate round-trip or two-way
memo specifies a Two-way Active Measurement Protocol (TWAMP), based measurements. This memo specifies a Two-Way Active Measurement
on the OWAMP, that adds two-way or round-trip measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip
capabilities. The TWAMP measurement architecture is usually measurement capabilities. The TWAMP measurement architecture is
comprised of two hosts with specific roles, and this allows for usually comprised of two hosts with specific roles, and this allows
some protocol simplifications, making it an attractive alternative for some protocol simplifications, making it an attractive
in some circumstances. alternative in some circumstances.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction ....................................................2
1.1 Relationship of Test and Control Protocols................3 1.1. Relationship of Test and Control Protocols .................3
1.2 Logical Model.............................................4 1.2. Logical Model ..............................................3
1.3 Pronunciation Guide.......................................5 1.3. Pronunciation Guide ........................................4
2. Protocol Overview.............................................5 2. Protocol Overview ...............................................5
3. TWAMP Control.................................................6 3. TWAMP-Control ...................................................6
3.1 Connection Setup..........................................6 3.1. Connection Setup ...........................................6
3.2 Integrity Protection......................................7 3.2. Integrity Protection .......................................7
3.3 Value of the Accept Fields................................8 3.3. Values of the Accept Field .................................7
3.4 TWAMP Control Commands....................................8 3.4. TWAMP-Control Commands .....................................7
3.5 Creating Test Sessions....................................8 3.5. Creating Test Sessions .....................................8
3.6 Send Schedules...........................................10 3.6. Send Schedules ............................................10
3.7 Starting Test Sessions...................................11 3.7. Starting Test Sessions ....................................10
3.8 Stop-Sessions............................................11 3.8. Stop-Sessions .............................................10
3.9 Fetch-Session............................................12 3.9. Fetch-Session .............................................12
4. TWAMP Test...................................................12 4. TWAMP-Test .....................................................12
4.1 Sender Behavior..........................................13 4.1. Sender Behavior ...........................................12
4.2 Reflector Behavior.......................................13 4.1.1. Packet Timings .....................................12
5. Implementers Guide...........................................21 4.1.2. Packet Format and Content ..........................12
6. Security Considerations......................................21 4.2. Reflector Behavior ........................................13
7. Acknowledgements.............................................22 4.2.1. TWAMP-Test Packet Format and Content ...............14
8. IANA Considerations..........................................22 5. Implementers' Guide ............................................20
8.1 Registry Specification...................................23 6. Security Considerations ........................................20
8.2 Registry Management......................................23 7. Acknowledgements ...............................................21
8.3 Experimental Numbers.....................................23 8. IANA Considerations ............................................21
8.4 Initial Registry Contents................................23 8.1. Registry Specification ....................................22
9. Internationalization Considerations..........................24 8.2. Registry Management .......................................22
10. APPENDIX I - TWAMP Light (Informative)......................24 8.3. Experimental Numbers ......................................22
11. References..................................................25 8.4. Initial Registry Contents .................................22
11.1 Normative References....................................25 9. Internationalization Considerations ............................22
11.2 Informative References..................................26 Appendix I - TWAMP Light (Informative) ............................23
Normative References ..............................................24
Informative References ............................................24
1. Introduction 1. Introduction
The Internet Engineering Task Force (IETF) has completed a Proposed The Internet Engineering Task Force (IETF) has completed a Proposed
standard for the round-trip delay [RFC2681] metric. IETF has also Standard for the round-trip delay [RFC2681] metric. The IETF has
completed a protocol for the control and collection of one-way also completed a protocol for the control and collection of one-way
measurements, the One-way Active Measurement Protocol (OWAMP) measurements, the One-way Active Measurement Protocol (OWAMP)
[RFC4656]. However, OWAMP does not accommodate round-trip or two- [RFC4656]. However, OWAMP does not accommodate round-trip or two-way
way measurements. measurements.
Two-way measurements are common in IP networks, primarily because Two-way measurements are common in IP networks, primarily because
synchronization between local and remote clocks is unnecessary for synchronization between local and remote clocks is unnecessary for
round-trip delay, and measurement support at the remote end may be round-trip delay, and measurement support at the remote end may be
limited to a simple echo function. However, the most common limited to a simple echo function. However, the most common facility
facility for round-trip measurements is the ICMP Echo Request/Reply for round-trip measurements is the ICMP Echo Request/Reply (used by
(used by the ping tool), and issues with this method are documented the ping tool), and issues with this method are documented in Section
in section 2.6 of [RFC2681]. This memo specifies the Two-way Active 2.6 of [RFC2681]. This memo specifies the Two-Way Active Measurement
Measurement Protocol, or TWAMP. TWAMP uses the methodology and Protocol, or TWAMP. TWAMP uses the methodology and architecture of
architecture of OWAMP [RFC4656] to define an open protocol for OWAMP [RFC4656] to define an open protocol for measurement of two-way
measurement of two-way or round-trip metrics (henceforth in this or round-trip metrics (henceforth in this document the term two-way
document the term two-way also signifies round-trip), in addition also signifies round-trip), in addition to the one-way metrics of
to the one-way metrics of OWAMP. TWAMP employs time stamps applied OWAMP. TWAMP employs time stamps applied at the echo destination
at the echo destination (reflector) to enable greater accuracy (reflector) to enable greater accuracy (processing delays can be
(processing delays can be accounted for). The TWAMP measurement accounted for). The TWAMP measurement architecture is usually
architecture is usually comprised of only two hosts with specific comprised of only two hosts with specific roles, and this allows for
roles, and this allows for some protocol simplifications, making it some protocol simplifications, making it an attractive alternative to
an attractive alternative to OWAMP in some circumstances. OWAMP in some circumstances.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in 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-
TWAMP-Control is used to initiate, start, and stop test sessions, Control is used to initiate, start, and stop test sessions, whereas
whereas TWAMP-Test is used to exchange test packets between two TWAMP-Test is used to exchange test packets between two TWAMP
TWAMP entities. 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
TWAMP architecture. The Session-Reflector has the capability architecture. The Session-Reflector has the capability to create
to create and send a measurement packet when it receives a and send a measurement packet when it receives a measurement
measurement packet. Unlike the Session-Receiver, the packet. Unlike the Session-Receiver, the Session-Reflector does
Session-Reflector does not collect any packet information. 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
sessions, and is capable of configuring per-session state in sessions, and is capable of configuring per-session state in the
the end-points. However, a Server associated with a endpoints. However, a Server associated with a Session-Reflector
Session-Reflector would not have the capability to return the would not have the capability to return the results of a test
results of a test session, and this is a difference from OWAMP. session, and this is a difference from OWAMP.
- The Fetch-Client entity does not exist in the TWAMP - The Fetch-Client entity does not exist in the TWAMP architecture,
architecture, as the Session-Reflector does not collect any as the Session-Reflector does not collect any packet information
packet information to be fetched. Consequently there is no to be fetched. Consequently, there is no need for the Fetch-
need for the Fetch-Client. Client.
An example of possible relationship scenarios between these roles An example of possible relationship scenarios between these roles is
are presented below. In this example different logical roles are presented below. In this example, different logical roles are played
played on different hosts. Unlabeled links in the figure are on different hosts. Unlabeled links in the figure are unspecified by
unspecified by this document and may be proprietary protocols. this document and may be proprietary protocols.
+----------------+ +-------------------+ +----------------+ +-------------------+
| Session-Sender |<-TWAMP-Test-->| Session-Reflector | | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
+----------------+ +-------------------+ +----------------+ +-------------------+
^ ^ ^ ^
| | | |
| | | |
| | | |
| +----------------+<----------------+ | +----------------+<----------------+
| | Server | | | Server |
skipping to change at page 5, line 4 skipping to change at page 4, line 33
| | Server | | | Server |
| +----------------+ | +----------------+
| ^ | ^
| | | |
| TWAMP-Control | TWAMP-Control
| | | |
v v v v
+----------------+ +----------------+
| Control-Client | | Control-Client |
+----------------+ +----------------+
As in OWAMP [RFC4656], different logical roles can be played by the As in OWAMP [RFC4656], different logical roles can be played by the
same host. For example, in the figure above, there could be same host. For example, in the figure above, there could actually be
actually two hosts: one playing the roles of Control-Client and two hosts: one playing the roles of Control-Client and Session-
Session-Sender, and the other playing the roles of Server and Sender, and the other playing the roles of Server and Session-
Session-Reflector. This example is shown below. Reflector. This example is shown below.
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| Control-Client |<--TWAMP Control-->| Server | | Control-Client |<--TWAMP-Control-->| Server |
| | | | | | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector | | Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be 1.3. Pronunciation Guide
set to zero by senders and MUST be ignored by receivers.
1.3 Pronunciation Guide
The acronym OWAMP is usually pronounced in two syllables, Oh-wamp. The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
The acronym TWAMP is also pronounced in two syllables, Tee-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 TWAMP-control adheres to OWAMP's overall architecture and design. The TWAMP-
and TWAMP-Test protocols accomplish their testing tasks as outlined Control and TWAMP-Test protocols accomplish their testing tasks as
below: outlined below:
- The Control-Client initiates a TCP connection on TWAMP's well- - The Control-Client initiates a TCP connection on TWAMP's well-
known port, and the Server (its role now established) responds known port, and the Server (its role now established) responds
with its greeting message indicating the security/integrity with its Greeting message, indicating the security/integrity
mode(s) it is willing to support. mode(s) it is willing to support.
- The Control-Client responds with the chosen mode of - The Control-Client responds with the chosen mode of communication
communication and information supporting integrity protection and information supporting integrity protection and encryption, if
and encryption, if the mode requires them. The Server responds the mode requires them. The Server responds to accept the mode
to accept the mode and start time. This completes the control and give its start time. This completes the control-connection
connection setup. setup.
- The Control-Client requests (and describes) a test session with - The Control-Client requests (and describes) a test session with a
a unique TWAMP-Control message. The Server responds with its unique TWAMP-Control message. The Server responds with its
acceptance and supporting information. More than one test acceptance and supporting information. More than one test session
session may be requested with additional messages. may be requested with additional messages.
- The Control-Client initiates all requested testing with a start - The Control-Client initiates all requested testing with a Start-
sessions message, and the Server acknowledges. Sessions message, and the Server acknowledges.
- The Session-Sender and the Session-Reflector exchange test - The Session-Sender and the Session-Reflector exchange test packets
packets according to the TWAMP-Test protocol for each active according to the TWAMP-Test protocol for each active session.
session.
- When appropriate, the Control-Client sends a message to stop all - When appropriate, the Control-Client sends a message to stop all
test sessions. test sessions.
There are two recognized extension mechanisms in the TWAMP There are two recognized extension mechanisms in the TWAMP Protocol.
Protocol. The Modes field is used to establish the communication
options during TWAMP-Control Connection Setup. The TWAMP-Control 1) The Modes field is used to establish the communication options
Command Number is another intended extension mechanism, allowing during TWAMP-Control Connection Setup.
additional commands to be defined in the future. TWAMP-Control
protocol addresses different levels of support between Control- 2) The TWAMP-Control Command Number is another intended extension
Client and Server. mechanism, allowing additional commands to be defined in the
future.
The TWAMP-Control protocol resolves different capability levels
between the 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 Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set
to zero by senders and MUST be ignored by receivers.
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 One such exception is the Fetch-Session command, which is not used in
in TWAMP. 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
defined in section 3.1 of OWAMP [RFC4656]. The Modes field is a in Section 3.1 of OWAMP [RFC4656]. The Modes field is a recognized
recognized extension mechanism in TWAMP, and the current mode extension mechanism in TWAMP, and the current mode values are
values are identical to those used in OWAMP. The only exception is identical to those used in OWAMP. The only exception is the well-
the well-known port number for TWAMP-control. A client opens a TCP known port number for TWAMP-Control. A Client opens a TCP connection
connection to the server on well-known port N (Refer to the IANA to the Server on well-known port 862. The host that initiates the
Considerations section below for the TWAMP-control port number TCP connection takes the roles of Control-Client and (in the two-host
assignment). The host that initiates the TCP connection takes the implementation) the Session-Sender. The host that acknowledges the
roles of Control-Client and (in the two-host implementation) the TCP connection accepts the roles of Server and (in the two-host
Session-Sender. The host that acknowledges the TCP connection implementation) the Session-Reflector.
accepts the roles of Server and (in the two-host implementation)
the Session Reflector.
The Control-Client MAY set a desired code-point in the Diffserv The Control-Client MAY set a desired code point in the Diffserv Code
Code Point (DSCP) field in the IP header for ALL packets of a Point (DSCP) field in the IP header for ALL packets of a specific
specific control connection. The Server SHOULD use the DSCP of the control connection. The Server SHOULD use the DSCP of the Control-
Control-Client's TCP SYN in ALL subsequent packets on that Client's TCP SYN in ALL subsequent packets on that connection
connection (avoiding any ambiguity in case of re-marking). (avoiding any ambiguity in case of re-marking).
The possibility exists for Control-Client failure after TWAMP- The possibility exists for Control-Client failure after TWAMP-
Control connection establishment, or the path between the Control- Control connection establishment, or the path between the Control-
Client and Server may fail while a connection is in-progress. The Client and Server may fail while a connection is in progress. The
Server MAY discontinue any established control connection when no Server MAY discontinue any established control connection when no
packet associated with that connection has been received within packet associated with that connection has been received within
SERVWAIT seconds. The Server SHALL suspend monitoring control SERVWAIT seconds. The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the SHALL resume after receiving a Stop-Sessions command (IF the SERVWAIT
SERVWAIT option is supported). Note that the REFWAIT time-out option is supported). Note that the REFWAIT timeout (described
(described below) covers failures during test sessions. The default below) covers failures during test sessions, and if REFWAIT expires
value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY on ALL test sessions initiated by a TWAMP-Control connection, then
be configurable. This time-out allows a Server to free-up resources the SERVWAIT monitoring SHALL resume (as though a Stop-Sessions
in case of failure. command had been received). An implementation that supports the
SERVWAIT timeout SHOULD also implement the REFWAIT timeout. The
default value of SERVWAIT SHALL be 900 seconds, and this waiting time
MAY be configurable. This timeout allows the Server to free up
resources in case of failure.
Both the server and the client use the same mappings from KeyIDs to Both the Server and the Client use the same mappings from KeyIDs to
shared secrets. The server, being prepared to conduct sessions shared secrets. The Server, being prepared to conduct sessions with
with more than one client, uses KeyIDs to choose the appropriate more than one Client, uses KeyIDs to choose the appropriate secret
secret key; a client would typically have different secret keys for key; a Client would typically have different secret keys for
different servers. The shared secret is a passphrase. To maximize different Servers. The shared secret is a passphrase. To maximize
passphrase interoperability, the passphrase character set MUST be passphrase interoperability, the passphrase character set MUST be
encoded using Appendix B of [RFC 5198] (the ASCII Network Virtual encoded using Appendix B of [RFC 5198] (the ASCII Network Virtual
Terminal Definition) It MUST not contain newlines (any combination Terminal Definition). It MUST not contain newlines (any combination
of Carriage-Return (CR) and/or Line-Feed (LF) characters), and of Carriage-Return (CR) and/or Line-Feed (LF) characters), and
control characters SHOULD be avoided. control characters SHOULD be avoided.
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]. As in OWAMP, each HMAC sent covers Section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC (Hashed
everything sent in a given direction between the previous HMAC (but Message Authentication Code) sent covers everything sent in a given
not including it) and up to the beginning of the new HMAC. This direction between the previous HMAC (but not including it) and the
way, once encryption is set up, each bit of the TWAMP-Control start of the new HMAC. This way, once encryption is set up, each bit
connection is authenticated by an HMAC exactly once. of the TWAMP-Control connection is authenticated by an HMAC exactly
once.
Note that the Server-Start message (sent by a Server during the Note that the Server-Start message (sent by a Server during the
initial control connection exchanges) does not terminate with an initial control-connection exchanges) does not terminate with an HMAC
HMAC field. Therefore, the HMAC in the first Accept-Session message field. Therefore, the HMAC in the first Accept-Session message also
also covers the Server-Start message and includes the Start-Time covers the Server-Start message and includes the Start-Time field in
field in the HMAC calculation. the HMAC calculation.
Also, in authenticated and encrypted modes, the HMAC in TWAMP- Also, in authenticated and encrypted modes, the HMAC in TWAMP-Control
Control packets is encrypted. packets is encrypted.
3.3 Value of the Accept Fields 3.3. Values of the Accept Field
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 conform to the rules defined in section 3.4 TWAMP-Control commands conform to the rules defined in Section 3.4 of
of OWAMP [RFC4656] OWAMP [RFC4656].
The following commands are available for the Control-client: The following commands are available for the Control-Client:
Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server
can send specific messages in response to the commands it receives can send specific messages in response to the commands it receives
(as described in the sections that follow). (as described in the sections that follow).
Note that the OWAMP Request-Session command is replaced by the Note that the OWAMP Request-Session command is replaced by the TWAMP
TWAMP Request-TW-Session command, and the Fetch-Session command Request-TW-Session command, and the Fetch-Session command does not
does not appear in TWAMP. appear in TWAMP.
3.5 Creating Test Sessions 3.5. Creating Test Sessions
Test session creation follows the same procedure as defined in Test session creation follows the same procedure as defined in
section 3.5 of OWAMP [RFC4656]. The Request-TW-Session command is Section 3.5 of OWAMP [RFC4656]. The Request-TW-Session command is
based on the OWAMP Request-Session command, and uses the message based on the OWAMP Request-Session command, and uses the message
format as described in OWAMP secition 3.5, but without the schedule format as described in Section 3.5 of OWAMP, but without the Schedule
slot description field(s) and uses one HMAC. The description of the Slot Descriptions field(s) and uses only one HMAC. The description
Request-TW-Session format follows. of the Request-TW-Session format follows.
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-Control 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.
The Command Number value of 5 indicates a Request-TW-Session The Command Number value of 5 indicates a Request-TW-Session command,
Command, and the Server MUST interpret this command as a request and the Server MUST interpret this command as a request for a two-way
for a two-way test session using the TWAMP-Test protocol. test session using the TWAMP-Test protocol.
If a TWAMP Server receives an unexpected command number, it MUST 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 Accept-Session message. Command request is not supported") in the Accept-Session message. Command
numbers that are Forbidden (and possibly numbers that are Reserved) Numbers that are Forbidden (and possibly numbers that are Reserved)
are unexpected. 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
Request-Session message describes a task where the Server will message describes a task where the Server will configure a one-way
configure a one-way test packet sender. Likewise, the test packet sender. Likewise, the Conf-Receiver field is set to 1
Conf-Receiver field is set to 1 when the message describes the when the message describes the configuration for a Session-Receiver.
configuration for a Session-Receiver. In TWAMP, both endpoints In TWAMP, both endpoints send and receive test packets, with the
perform in these roles, with the Session-Sender first sending and Session-Sender first sending and then receiving test packets,
then receiving test packets. The Session-Reflector first receives complimented by the Session-Reflector first receiving and then
the test packets, and returns each test packet to the sending.
Session-Sender as fast as possible.
Both Conf-Sender field and Conf-Receiver field MUST be set to 0 Both the 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
value as an improperly formatted command, and MUST respond with the as an improperly formatted command, and MUST respond with the Accept
Accept field set to 3 (meaning "Some aspect of request is not field set to 3 (meaning "Some aspect of request is not supported") in
supported") in the Accept-Session message. 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
packets for performance metrics and consequently does not need to for performance metrics and consequently does not need to know the
know the number of incoming packets and their timing schedule. number of incoming packets and their timing schedule. Consequently
Consequently the Number of Scheduled Slots and Number of Packets 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
be sent and the port to which TWAMP-Test packets will be sent by sent and the port to which TWAMP-Test packets will be sent by the
the Session-Reflector (Session-Sender will use the same UDP port to Session-Reflector (the Session-Sender will use the same UDP port to
send and receive packets). Receiver Port is the desired UDP port send and receive packets). The 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 The 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 (the 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,
respectively, the sender and receiver addresses of the endpoints of the sender and receiver addresses of the endpoints of the Internet
the Internet path over which a TWAMP test session is requested. path over which a TWAMP-Test session is requested. They MAY be set
They MAY be set to 0, in which case the IP addresses used for the to 0, in which case the IP addresses used for the Control-Client to
Control-Client to Server TWAMP-Control Message exchange MUST be Server TWAMP-Control message exchange MUST be used in the test
used in the test packets. packets.
The Session Identifier (SID) is as defined in OWAMP [RFC4656]. The Session Identifier (SID) is as defined in OWAMP [RFC4656]. Since
Since the SID is always generated by the receiving side, the Server the SID is always generated by the receiving side, the Server
determines the SID, and the SID in the Request-TW-Session message determines the SID, and the SID in the Request-TW-Session message
MUST be set to 0. MUST be set to 0.
The Start Time is as defined in OWAMP [RFC4656]. The Start Time is 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-
Session-Reflector MUST wait after receiving a Stop-Sessions Reflector MUST wait after receiving a Stop-Sessions message. In case
message. In case there are test packets still in transit, the there are test packets still in transit, the Session-Reflector MUST
Session Reflector MUST reflect them if they arrive within the reflect them if they arrive within the Timeout interval following the
timeout interval following the reception of the Stop-Sessions reception of the Stop-Sessions message. The Session-Reflector MUST
message. The Session-Reflector MUST NOT reflect packets that are 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 DSCP MUST Point (DSCP) as defined in [RFC2474]. The same value of DSCP MUST be
be used in test packets reflected by the Session-Reflector. used in test packets reflected by the Session-Reflector.
Since there are no Schedule Slot Descriptions, the Request-TW- Since there are no Schedule Slot Descriptions, the Request-TW-Session
Session Message is completed by MBZ (Must Be Zero) and HMAC (Hash message is completed by MBZ (Must Be Zero) and HMAC fields. This
Message Authentication Code) fields. This completes one logical completes one logical message, referred to as the Request-TW-Session
message, referred to as the Request-TW-Session Command. command.
The Session-Reflector MUST respond to each Request-TW-Session The Session-Reflector MUST respond to each Request-TW-Session command
Command with an Accept-Message as defined in OWAMP [RFC4656]. When with an Accept-Session message as defined in OWAMP [RFC4656]. When
the 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
port number where the Session-Reflector expects to receive packets number where the Session-Reflector expects to receive packets from
from the Session-Sender. 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-
Session-Sender either accepts the alternate port, or composes a new Sender either accepts the alternate port, or composes a new Session-
Session-Request message with suitable parameters. Otherwise, the Request message with suitable parameters. Otherwise, the Server at
Server at the Session-Reflector uses the Accept Field to convey the Control-Client uses the Accept field to convey other forms of
other forms of session rejection or failure and MUST NOT suggest an session rejection or failure and MUST NOT suggest an alternate port;
alternate port. In this case the Port Field MUST be set to zero. in this case, the Port field MUST be set to zero.
3.6 Send Schedules 3.6. Send Schedules
The Send Schedule for test packets defined in section 3.6 of OWAMP The send schedule for test packets defined in Section 3.6 of OWAMP
[RFC4656] is not used in TWAMP. The Control-Client and [RFC4656] is not used in TWAMP. The Control-Client and Session-
Session-Sender MAY autonomously decide the Send Schedule. The Sender MAY autonomously decide the send schedule. The Session-
Session-Reflector SHOULD return each test packet to the Reflector SHOULD return each test packet to the Session-Sender as
Session-Sender as quickly as possible. 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 similar to
as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Sessions that defined in Section 3.8 of OWAMP [RFC4656]. The Stop-Sessions
command can only be issued by the Control-Client. The message MUST command can only be issued by the Control-Client. The message MUST
NOT contain any session description records or skip ranges. The NOT 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-
Stop-Sessions Command. Since the TWAMP Stop-Sessions command does Sessions command. Since the TWAMP Stop-Sessions command does not
not convey SIDs, it applies to all sessions previously requested convey SIDs, it applies to all sessions previously requested and
and started with a Start-Sessions command. started with a Start-Sessions command.
Thus, the TWAMP Stop-Sessions command is constructed as follows: Thus, the TWAMP Stop-Sessions command is constructed as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ | | 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions | | Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Above, the Command Number in the first octet (3) indicates that Above, the Command Number in the first octet (3) indicates that this
this is the Stop-Sessions command. is the Stop-Sessions command.
Non-zero Accept values indicate a failure of some sort. Zero Non-zero Accept values indicate a failure of some sort. Zero values
values indicate normal (but possibly premature) completion. The indicate normal (but possibly premature) completion. The full list
full list of available Accept values is described in Section 3.3 of of available Accept values is described in Section 3.3 of [RFC4656],
[RFC4656], "Values of the Accept Field". "Values of the Accept Field".
If Accept had a non-zero value, results of all TWAMP-Test sessions If Accept has a non-zero value, results of all TWAMP-Test sessions
spawned by this TWAMP-Control session SHOULD be considered invalid. spawned by this TWAMP-Control session SHOULD be considered invalid.
If the Accept message was not transmitted at all (for whatever If the Accept-Session message was not transmitted at all (for
reason, including failure of the TCP connection used for TWAMP- whatever reason, including failure of the TCP connection used for
Control), the results of all TWAMP-Test sessions spawned by this TWAMP-Control), the results of all TWAMP-Test sessions spawned by
TWAMP-control session MAY be considered invalid. this TWAMP-Control session MAY be considered invalid.
Number of Sessions indicates the number of sessions that the Number of Sessions indicates the number of sessions that the
Control-Client intends to stop. Control-Client intends to stop.
Number of Sessions MUST contain the number of send sessions started Number of Sessions MUST contain the number of send sessions started
by the Control-Client that have not been previously terminated by a by the Control-Client that have not been previously terminated by a
Stop-Sessions command (i.e., the Control-Client MUST account for Stop-Sessions command (i.e., the Control-Client MUST account for each
each accepted Request-Session). If the Stop-Sessions message does accepted Request-Session). If the Stop-Sessions message does not
not account for exactly the number of sessions in-progress, then it account for exactly the number of sessions in progress, then it is to
is to be considered invalid and the TWAMP-Control connection SHOULD be considered invalid, the TWAMP-Control connection SHOULD be closed,
be closed and any results obtained considered invalid. and any results obtained considered invalid.
Upon receipt of a TWAMP-Control Stop-Sessions command, the Session- Upon receipt of a TWAMP-Control Stop-Sessions command, the Session-
Reflector MUST discard any TWAMP-Test packets that arrive at the Reflector MUST discard any TWAMP-Test packets that arrive at the
current time plus the Timeout (in the Request-TW-Session command). current time plus the Timeout (in the Request-TW-Session command).
3.9 Fetch-Session 3.9. Fetch-Session
One purpose of TWAMP is measurement of two-way metrics. Two-way One purpose of TWAMP is measurement of two-way metrics. Two-way
measurement methods do not require packet level data to be measurement methods do not require packet-level data to be collected
collected by the Session-Reflector (such as sequence number, by the Session-Reflector (such as sequence number, timestamp, and
timestamp, and TTL) because this data is communicated in the Time to Live (TTL)) because this data is communicated in the
"reflected" test packets. As such the protocol does not require "reflected" test packets. As such, the protocol does not require the
the retrieval of packet level data from the Server and the OWAMP retrieval of packet-level data from the Server and the OWAMP Fetch-
Fetch-Session command is not used in TWAMP. 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-test protocol
protocol with the exception that the Session-Reflector transmits [RFC4656] 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
it receives. TWAMP defines two different test packet formats, one receives. TWAMP defines two different test packet formats, one for
for packets transmitted by the Session-Sender and one for packets 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-test protocol
protocol there are three modes: unauthenticated, authenticated, and [RFC4656], there are three modes: unauthenticated, authenticated, and
encrypted. encrypted.
4.1 Sender Behavior 4.1. Sender Behavior
The sender behavior is determined by the configuration of the The sender behavior is determined by the configuration of the
Session-Sender and is not defined in this standard. Further, the Session-Sender and is not defined in this standard. Further, the
Session-Reflector does not need to know the Session-Sender behavior Session-Reflector does not need to know the Session-Sender behavior
to the degree of detail as needed in OWAMP [RFC4656]. to the degree of detail as needed in OWAMP [RFC4656]. Additionally,
Additionally the Session-Sender collects and records the necessary the Session-Sender collects and records the necessary information
information provided from the packets transmitted by the provided from the packets transmitted by the Session-Reflector for
Session-Reflector for measuring two-way metrics. The information measuring two-way metrics. The information recording based on the
recording based on the received packet by the Session-Sender is packet(s) received by the Session-Sender is implementation dependent.
implementation dependent.
4.1.1 Packet Timings 4.1.1. Packet Timings
Since the Send Schedule is not communicated to the Since the send schedule is not communicated to the Session-Reflector,
Session-Reflector, there is no need for a standardized computation there is no need for a standardized computation of packet timing.
of packet timing.
Regardless of any scheduling delays, each packet that is actually Regardless of any scheduling delays, each packet that is actually
sent MUST have the best possible approximation of its real time of sent MUST have the best possible approximation of its real time of
departure as its timestamp (in the packet). departure as its timestamp (in the packet).
4.1.2 Packet Format and Content 4.1.2. Packet Format and Content
The Session-Sender packet format and content follow the same The Session-Sender packet format and content follow the same
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).
Note that the Reflector test packet formats are larger than the Note that the Reflector test packet formats are larger than the
Sender's formats. The Session-Sender MAY append sufficient Packet Sender's formats. The Session-Sender MAY append sufficient Packet
Padding to allow the same IP packet payload lengths to be used in Padding to allow the same IP packet payload lengths to be used in
each direction of transmission (this is usually desirable). To each direction of transmission (this is usually desirable). To
compensate for the Reflector's larger test packet format, the compensate for the Reflector's larger test packet format, the Sender
Sender appends at least 27 octets of padding in unauthenticated appends at least 27 octets of padding in unauthenticated mode, and at
mode, and at least 56 octets in authenticated and encrypted modes. least 56 octets in authenticated and encrypted modes.
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 do the following:
- 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 Received Timestamp (in the packet).
- In authenticated or encrypted mode, decrypt the appropriate - In authenticated or encrypted mode, decrypt the appropriate
sections of the packet body (first block (16 octets) for sections of the packet body (first block (16 octets) for
authenticated, 96 octets for encrypted), and then check authenticated, 96 octets for encrypted), and then check integrity
integrity of sections covered by the HMAC. 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 - Extract the Sender TTL value from the TTL/Hop Limit value of
received packets. Session-Reflector Implementations SHOULD received packets. Session-Reflector implementations SHOULD fetch
fetch the TTL/Hop Limit value from the IP header of the packet, 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
good reason not to do so is an inability to access the TTL reason not to do so is an inability to access the TTL field of
field of arriving packets), it MUST set the Sender TTL value as arriving packets), it MUST set the Sender TTL value as 255.
255.
- In authenticated and encrypted modes, the HMAC MUST be - In authenticated and encrypted modes, the HMAC MUST be calculated
calculated first, then the appropriate portion of the packet first, then the appropriate portion of the packet body is
body is encrypted. encrypted.
- Transmit a test packet to the Session-Sender in response to - Transmit a test packet to the Session-Sender in response to every
every received packet. The response MUST be generated as received packet. The response MUST be generated as immediately as
immediately as possible. The format and content of the test possible. The format and content of the test packet is defined in
packet is defined in section 4.2.1. Prior to the transmission Section 4.2.1. Prior to the transmission of the test packet, the
of the test packet, the Session-Reflector MUST enter the best Session-Reflector MUST enter the best possible approximation of
possible approximation of its actual sending time of as its its actual sending time as its Timestamp (in the packet). This
Timestamp (in the packet). This permits the determination of permits the determination of the elapsed time between the
the elapsed time between the reception of the packet and its reception of the packet and its transmission.
transmission.
- Packets not received within the Timeout (following the Stop- - Packets not received within the Timeout (following the Stop-
Session command) MUST be ignored by the Reflector. The Sessions command) MUST be ignored by the Reflector. The Session-
Session-Reflector MUST NOT generate a test packet to the Reflector MUST NOT generate a test packet to the Session-Sender
Session-Sender for packets that are ignored. for packets that are ignored.
The possibility exists for Session-Sender failure during a session, The possibility exists for Session-Sender failure during a session,
or the path between the Session-Sender and Session-Reflector may or the path between the Session-Sender and Session-Reflector may fail
fail while a test session is in-progress. The Session-Reflector MAY while a test session is in progress. The Session-Reflector MAY
discontinue any session which has been Started when no packet discontinue any session that has been started when no packet
associated with that session has been received for REFWAIT seconds. associated with that session has been received for REFWAIT seconds.
The default value of REFWAIT SHALL be 900 seconds, and this waiting The default value of REFWAIT SHALL be 900 seconds, and this waiting
time MAY be configurable. This time-out allows a Session-Reflector time MAY be configurable. This timeout allows a Session-Reflector to
to free-up resources in case of failure. 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
in response to each packet received. The Session-Reflector SHOULD 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-
Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) Reflector SHOULD set the TTL in IPv4 (or Hop Limit in IPv6) in the
in the UDP packet to 255. 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 packet
packet depends on the mode being used. The two formats are depends on the mode being used. The two formats are presented below.
presented below.
For unauthenticated mode: For unauthenticated mode:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at page 18, line 11 skipping to change at page 17, line 11
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that all Timestamps have the same format as OWAMP [RFC4656] as Note that all timestamps have the same format as OWAMP [RFC4656] as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds | | Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional 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 to its transmit order. It starts with zero and is incremented by one
one for each subsequent packet. The Sequence Number generated by for each subsequent packet. The Sequence Number generated by the
the Session-Reflector is independent from the sequence number of Session-Reflector is independent from the sequence number of the
the arriving packets. 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
fields follow the definition and formats defined by OWAMP section follow the definition and formats defined by OWAMP, Section 4.1.2 in
4.1.2, in [RFC4656]. [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
that corresponds to this test packet. corresponds to this test packet.
Sender TTL is 255 when transmitted by the Session Sender. Sender Sender TTL is 255 when transmitted by the Session-Sender. Sender TTL
TTL is set to the Time To Live (or Hop Count) value of the received is set to the Time To Live (or Hop Count) value of the received
packet from the IP packet header when transmitted by the Session packet from the IP packet header when transmitted by the Session-
Reflector. Reflector.
Receive Timestamp is the time the test packet was received by the Receive Timestamp is the time the test packet was received by the
reflector. The difference between Timestamp and Receive Timestamp reflector. The difference between Timestamp and Receive Timestamp is
is the amount of time the packet was in transition in the the amount of time the packet was in transition in the Session-
Session-Reflector. The Error Estimate associated with the Reflector. The Error Estimate associated with the Timestamp field
Timestamp field also applies to the Receive Timestamp. also applies to the Receive Timestamp.
Sender Sequence Number is a copy of the Sequence Number of the Sender Sequence Number is a copy of the Sequence Number of the packet
packet transmitted by the Session-Sender that caused the transmitted by the Session-Sender that caused the Session-Reflector
Session-Reflector to generate and send this test packet. to generate and send this test packet.
The HMAC field in TWAMP-Test packets covers the same fields as the The HMAC field in TWAMP-Test packets covers the same fields as the
AES encryption. Thus, in authenticated mode, HMAC covers the first Advanced Encryption Standard (AES) encryption. Thus, in
block (16 octets). In encrypted mode, HMAC covers the first six authenticated mode, HMAC covers the first block (16 octets); in
blocks (96 octets). In TWAMP-Test, the HMAC field MUST NOT be encrypted mode, HMAC covers the first six blocks (96 octets). In
encrypted. TWAMP-Test, the HMAC field MUST NOT be encrypted.
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
mentioned in this document). However, implementations MUST provide in this document). However, implementations MUST provide a
a configuration parameter, an option, or a different means of configuration parameter, an option, or a different means of making
making Packet Padding consist of all zeros. Packet Padding MUST NOT Packet Padding consist of all zeros. Packet Padding MUST NOT be
be covered by the HMAC and MUST NOT be encrypted. covered by the HMAC and MUST NOT be encrypted.
The minimum data segment length of TWAMP-Test packets in The minimum data segment length of TWAMP-Test packets in
unauthenticated mode is 41 octets, and 104 octets in both unauthenticated mode is 41 octets, and 104 octets in both
authenticated mode and encrypted modes. authenticated mode and encrypted modes.
Note that the Session-Reflector Test Packet Formats are larger than Note that the Session-Reflector Test packet formats are larger than
the Sender's formats. The Session-Reflector SHOULD reduce the the Sender's formats. The Session-Reflector SHOULD reduce the length
length of the Sender's Packet Padding to achieve equal IP packet of the Sender's Packet Padding to achieve equal IP packet payload
payload lengths in each direction of transmission, when sufficient lengths in each direction of transmission, when sufficient padding is
padding is present. The Session-Reflector MAY re-use the Sender's present. The Session-Reflector MAY re-use the Sender's Packet
Packet Padding (since the requirements for padding generation are Padding (since the requirements for padding generation are the same
the same for each), and in this case the Session-Reflector SHOULD for each), and in this case the Session-Reflector SHOULD truncate the
truncate the padding such that the highest number octets are padding such that the highest-number octets are discarded.
discarded.
In unauthenticated mode, encryption or authentication MUST NOT be In unauthenticated mode, encryption or authentication MUST NOT be
applied. applied.
The TWAMP-Test packet layout is identical in authenticated and The TWAMP-Test packet layout is identical in authenticated and
encrypted modes. The encryption operation for a Session-Sender encrypted modes. The encryption operation for a Session-Sender
packet follows the same rules of Session-Sender packets as defined packet follows the same rules of Session-Sender packets as defined in
in OWAMP section 4.1.2 of [RFC4656]. OWAMP section 4.1.2 of [RFC4656].
The main difference between authenticated mode and encrypted mode The main difference between authenticated mode and encrypted mode is
is the portions of the test packets that are covered by HMAC and the portion of the test packets that are covered by HMAC and
encrypted. Authenticated mode permits the timestamp to be fetched encrypted. Authenticated mode permits the timestamp to be fetched
after a portion of the packet is encrypted, but in encrypted mode after a portion of the packet is encrypted, but in encrypted mode all
all the sequence numbers and timestamps are fetched before the sequence numbers and timestamps are fetched before encryption to
encryption to provide maximum data integrity protection. provide maximum data-integrity protection.
In authenticated mode, only the sequence number in the first block In authenticated mode, only the sequence number in the first block is
is encrypted and the subsequent timestamps and sequence numbers are encrypted, and the subsequent timestamps and sequence numbers are
sent in clear text. Sending the timestamp in clear text allows one sent in clear text. Sending the timestamp in clear text allows one
to reduce the time between when a timestamp is obtained by a to reduce the time between when a timestamp is obtained by a
Session-Reflector and when that packet is sent out. This Session-Reflector and when that packet is sent out. This potentially
potentially improves the timestamp accuracy, because the sequence improves the timestamp accuracy, because the sequence number can be
number can be encrypted before the timestamp is fetched. encrypted before the timestamp is fetched.
In encrypted mode, the reflector MUST fetch the timestamps, In encrypted mode, the reflector MUST fetch the timestamps, generate
generate the HMAC and encrypt the packet, then send it. the HMAC, and encrypt the packet, then send it.
Obtaining the keys and encryption methods follow the same procedure Obtaining the keys and encryption methods follows the same procedure
as OWAMP as described below. Each TWAMP-Test session has two keys as OWAMP as described below. Each TWAMP-Test session has two keys,
an AES Session-key and an HMAC Session-key, and the keys are an AES Session-key and an HMAC Session-key, and the keys are derived
derived from the TWAMP-Control keys and the SID. from the TWAMP-Control keys and the SID.
The TWAMP-Test AES Session-key is obtained as follows: the The TWAMP-Test AES Session-key is obtained as follows: the TWAMP-
TWAMP-Control AES Session-key (the same AES Session-key as used for Control AES Session-key (the same AES Session-key as used for the
the corresponding TWAMP-Control session) is encrypted with the 16- corresponding TWAMP-Control session) is encrypted with the 16-octet
octet session identifier (SID) as the key, using a single-block session identifier (SID) as the key, using a single-block AES-ECB
AES-ECB encryption. The result is the TWAMP-Test AES Session-key to encryption. The result is the TWAMP-Test AES Session-key to be used
use in encrypting (and decrypting) the packets of the particular in encrypting (and decrypting) the packets of the particular TWAMP-
TWAMP-Test session. Note that the TWAMP-Test AES Session-key, Test session. Note that the TWAMP-Test AES Session-key, TWAMP-
TWAMP-Control AES Session-key, and the SID are all comprised of 16 Control AES Session-key, and the SID are all comprised of 16 octets.
octets.
The TWAMP-Test HMAC Session-key is obtained as follows: the The TWAMP-Test HMAC Session-key is obtained as follows: the TWAMP-
TWAMP-Control HMAC Session-key (the same HMAC Session-key as used Control HMAC Session-key (the same HMAC Session-key as used for the
for the corresponding TWAMP-Control session) is encrypted using corresponding TWAMP-Control session) is encrypted using AES-CBC
AES-CBC with the 16-octet session identifier (SID) as the key. This (Cipher Block Chaining) with the 16-octet session identifier (SID) as
is a two-block CBC encryption always performed with IV=0. Note that the key. This is a two-block CBC encryption that is always performed
the TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key with IV=0. Note that the TWAMP-Test HMAC Session-key and TWAMP-
are comprised of 32 octets, while the SID is 16 octets. Control HMAC Session-key are comprised of 32 octets, while the SID is
16 octets.
In authenticated mode, the first block (16 octets) of each TWAMP- In authenticated mode, the first block (16 octets) of each TWAMP-Test
Test packet is encrypted using AES Electronic Codebook (ECB) mode. packet is encrypted using the AES Electronic Codebook (ECB) mode.
This mode does not involve any chaining, and lost, duplicated, or This mode does not involve any chaining, and lost, duplicated, or
reordered packets do not cause problems with deciphering any packet reordered packets do not cause problems with deciphering any packet
in a TWAMP-Test session. in a TWAMP-Test session.
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;
operation; chaining does not span multiple packets so that lost, chaining does not span multiple packets so that lost, duplicated, or
duplicated, or reordered packets do not cause problems. The reordered packets do not cause problems. The initialization vector
initialization vector for the CBC encryption is a value with all 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
TWAMP-Test session MUST be set up at most once per session, not session MUST be set up at most once per session, not once per packet.
once per packet.
5. Implementers Guide 5. Implementers' Guide
This section serves as guidance to implementers of TWAMP. The This section serves as guidance to implementers of TWAMP. The
example architecture presented here is not a requirement. Similar example architecture presented here is not a requirement. Similar to
to OWAMP [RFC4656], TWAMP is designed with enough flexibility to OWAMP [RFC4656], TWAMP is designed with enough flexibility to allow
allow different architectures that suit multiple system different architectures that suit multiple system requirements.
requirements.
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-Reflector behavior of TWAMP as The responder follows the Session-Reflector behavior of TWAMP as
described in section 4.2. described in Section 4.2.
Appendix I provides an example for purely informational purposes. Appendix I provides an example for purely informational purposes. It
It suggests an incremental path to adopting TWAMP, by implementing suggests an incremental path to adopting TWAMP, by implementing the
the TWAMP-Test protocol first. TWAMP-Test protocol first.
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 Server Greeting message (defined in OWAMP, section 3.1 The Server-Greeting message (defined in OWAMP, Section 3.1 of
[RFC4656]) includes a "Count" field to specify the iteration [RFC4656]) includes a Count field to specify the iteration counter
counter used in PKCS #5 to generate keys from shared secrets. OWAMP used in PKCS #5 to generate keys from shared secrets. OWAMP
recommends a lower limit of 1024 iterations, but no upper limit. recommends a lower limit of 1024 iterations, but no upper limit. The
The Count field provides an opportunity for a DOS attack because it Count field provides an opportunity for a denial-of-service (DOS)
is 32 bits long. If an attacking system set the maximum value in attack because it is 32 bits long. If an attacking system set the
Count (2**32), it could stall a system attempting to generate keys maximum value in Count (2**32), then the system under attack would
for a significant period of time. Therefore, TWAMP-compliant stall for a significant period of time while it attempts to generate
systems SHOULD have a configuration control to limit the maximum keys. Therefore, TWAMP-compliant systems SHOULD have a configuration
Count value. The default maximum Count value SHOULD be 32768. As control to limit the maximum Count value. The default maximum Count
suggested in OWAMP, this value MAY be increased when greater value SHOULD be 32768. As suggested in OWAMP, this value MAY be
computing power becomes common. If a Control-Client receives a increased when greater computing power becomes common. If a
Server Greeting Message with Count greater that its maximum Control-Client receives a Server-Greeting message with Count greater
configured value, it SHOULD close the control connection. that its maximum configured value, it SHOULD close the control
connection.
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, Jeff Boote, and Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote,
Murtaza Chiba for their comments, suggestions, reviews, helpful Murtaza Chiba, and Kevin Earnst for their comments, suggestions,
discussion and proof-reading. Lars Eggert, Sam Hartman, and Tim reviews, helpful discussion, and proof-reading. Lars Eggert, Sam
Polk contributed very useful AD-level reviews, and the authors Hartman, and Tim Polk contributed very useful AD-level reviews, and
thank them for their contributions to the memo. the authors thank them for their contributions to the memo.
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-
OWAMP-Control part of the OWAMP [RFC4656] protocol. 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
IANA is requested to allocate a well-known TCP/UDP port number for IANA has also allocated a well-known TCP/UDP port number for the
the TWAMP-Control protocol. It would be ideal if the port number TWAMP-Control protocol.
assignment was adjacent to the OWAMP assignment. The recommended
Keyword for this entry is "twamp-control" and the Description is
"Two-way Active Measurement Protocol (TWAMP) Control".
During final editing, port N in section 3.1 should be replaced with ...
the assigned port number. twamp-control 862/tcp Two-way Active Measurement Protocol
(TWAMP) Control
twamp-control 862/udp Two-way Active Measurement Protocol
(TWAMP) Control
# [RFC5357]
# 863-872 Unassigned
Since TWAMP adds an additional Control command to the OWAMP-Control Since TWAMP adds an additional Control command beyond the OWAMP-
specification, and describes behavior when this control command is Control specification and describes behavior when this control
used, this memo requests creation an IANA registry for the TWAMP command is used, IANA has created a registry for the TWAMP Command
Command Number field. The field is not explicitly named in Number field. The field is not explicitly named in [RFC4656] but is
[RFC4656] but is called out for each command. This field is a called out for each command. This field is a recognized extension
recognized extension mechanism for TWAMP. mechanism for TWAMP.
8.1 Registry Specification 8.1. Registry Specification
IANA will create an TWAMP-Control Command Number registry. TWAMP- IANA has created a TWAMP-Control Command Number registry. TWAMP-
Control commands are specified by the first octet in OWAMP-Control Control commands are specified by the first octet in OWAMP-Control
messages as shown in section 3.5 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 [RFC5226] -- 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
new values will be assigned as monotonically increasing integers in values will be assigned as monotonically increasing integers in the
the range [0-15], unless there is a good reason to do otherwise. 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
exactly how many numbers might be useful in this space, nor if it how many numbers might be useful in this space, or if it would be
would be useful that they were easily distinguishable or at the useful that they were easily distinguishable or at the "high end" of
"high end" of the number range. Two might be useful, say one for the number range. Two might be useful, say one for session control,
session control, and one for session fetch. On the other hand, a and one for session fetch. On the other hand, a single number would
single number would allow for unlimited extension, because the allow for unlimited extension, because the format of the rest of the
format of the rest of the message could be tailored, with message could be tailored, with allocation of other numbers done once
allocation of other numbers done once usefulness has been proven. usefulness has been proven. Thus, this document allocates one number
Thus, this document will allocate one number, the next sequential (6) as 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 Number 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 Reserved 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 [RFC3629, RFC5198]. encoded in UTF-8 [RFC3629, RFC5198].
10. APPENDIX I - TWAMP Light (Informative) Appendix I - TWAMP Light (Informative)
In this example the roles of Control-Client, Server, and In this example, the roles of Control-Client, Server, and Session-
Session-Sender are implemented in one host referred to as the Sender are implemented in one host referred to as the controller, and
controller and the role of Session-Reflector is implemented in the role of Session-Reflector is implemented in another host referred
another host referred to as the responder. to as the responder.
controller responder controller responder
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| Server |<----------------->| | | Server |<----------------->| |
| Control-Client | | Session-Reflector | | Control-Client | | Session-Reflector |
| Session-Sender |<--TWAMP-Test----->| | | Session-Sender |<--TWAMP-Test----->| |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
This example provides a simple architecture for responders where This example provides a simple architecture for responders where
their role will be to simply act as light test points in the their role will be to simply act as light test points in the network.
network. The controller establishes the test session with the The controller establishes the test session with the Server through
Server through non-standard means. After the session is non-standard means. After the session is established, the controller
established the controller transmits test packets to the responder. transmits test packets to the responder. The responder follows the
The responder follows the Session-Reflector behavior of TWAMP as Session-Reflector behavior of TWAMP as described in section 4.2 with
described in section 4.2 with the following exceptions. the following exceptions.
In the case of TWAMP Light, the Session-Reflector does not In the case of TWAMP Light, the Session-Reflector does not
necessarily have knowledge of the session state. IF the necessarily have knowledge of the session state. IF the Session-
Session-Reflector does not have knowledge of the session state, Reflector does not have knowledge of the session state, THEN the
THEN the Session-Reflector MUST copy the Sequence Number of the Session-Reflector MUST copy the Sequence Number of the received
received packet to the Sequence Number field of the reflected packet to the Sequence Number field of the reflected packet. The
packet. The controller receives the reflected test packets and controller receives the reflected test packets and collects two-way
collects two-way metrics. This architecture allows for collection metrics. This architecture allows for collection of two-way metrics.
of two-way metrics.
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
its configuration with the Server through non-standard means. The 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 4.2.1. sequence number and timestamp values per Section 4.2.1. TWAMP Light
TWAMP Light introduces some additional security considerations. The introduces some additional security considerations. The non-standard
non-standard means to control the responder and establish test means to control the responder and establish test sessions SHOULD
sessions SHOULD offer the features listed below. offer the features listed below.
The non-standard responder control protocol SHOULD have an The non-standard responder control protocol SHOULD have an
authenticated mode of operation. The responder SHOULD be authenticated mode of operation. The responder SHOULD be
configurable to accept only authenticated control sessions. configurable to accept only authenticated control sessions.
The non-standard responder control protocol SHOULD have a means to The non-standard responder control protocol SHOULD have a means to
activate the authenticated and encrypted modes of the TWAMP-Test activate the authenticated and encrypted modes of the TWAMP-Test
protocol. protocol.
When the TWAMP Light test sessions operate in authenticated or When the TWAMP Light test sessions operate in authenticated or
encrypted mode, the Session-Reflector MUST have some mechanism for encrypted mode, the Session-Reflector MUST have some mechanism for
generating keys (because the TWAMP-Control protocol normally plays generating keys (because the TWAMP-Control protocol normally plays a
a role in this process, but is not present here). The specification role in this process, but is not present here). The specification of
of the key generation mechanism is beyond the scope of this memo. the key generation mechanism is beyond the scope of this memo.
11. References
11.1 Normative References Normative References
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, M., "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol (OWAMP)",
(OWAMP)", RFC 4656, October 2004. RFC 4656, September 2006.
[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Round-Trip Delay Metric for IPPM". RFC 2681, Delay Metric for IPPM", RFC 2681, 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)
Field) in the IPv4 and IPv6 Headers", RFC 2474, in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
December 1998.
[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
an IANA Considerations Section in RFCs, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
October 1998. 2008.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
10646", STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[RFC5198] Klensin, J., Padlipsky, M., "Unicode Format for [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Network Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
11.2 Informative References 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", BCP 82, 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/
skipping to change at page 27, line 31 skipping to change at page 26, line 13
URI: http://www.nortel.com/ URI: http://www.nortel.com/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 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
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 175 change blocks. 
610 lines changed or deleted 582 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/