draft-ietf-ippm-twamp-01.txt   draft-ietf-ippm-twamp-02.txt 
J. Babiarz K. Hedayat
Internet Draft Nortel Networks Internet Draft Brix Networks
Expires: December 2006 K. Hedayat Expires: April 2007 R. Krzanowski
Brix Networks
R. Krzanowski
Verizon Verizon
Kiho Yum K. Yum
Juniper Networks Juniper Networks
A. Morton
AT&T Labs
J. Babiarz
Nortel Networks
November 2006
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-01 draft-ietf-ippm-twamp-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 4 skipping to change at page 2, line 6
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The IPPM One-way Active Measurement Protocol [OWAMP] provides a
common protocol for measuring one-way metrics between network
devices. OWAMP [OWAMP] can be used in both directions
independently to measure one-way metrics in both directions between
two network elements. However, it does not accommodate round-trip
or two-way measurements. This draft proposes a Two-way Active
Measurement Protocol, based on the One-way Active Measurement
Protocol [OWAMP], that will accommodate two-way or round-trip
measurements.
Table of Contents The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP)
provides a common protocol for measuring one-way metrics between
network devices. OWAMP can be used bi-directionally to measure
one-way metrics in both directions between two network elements.
However, it does not accommodate round-trip or two-way
measurements. This memo specifies a Two-way Active Measurement
Protocol (TWAMP), based on the OWAMP, that adds two-way or
round-trip measurement capabilities. The TWAMP measurement
architecture is usually comprised of two hosts with specific roles,
and this allows for some protocol simplifications, making it an
attractive alternative in some circumstances.
1. Introduction..................................................2 Table of Contents
2. Terminology...................................................3
3. Protocol Overview.............................................3
3.1 Relationship of Test and Control Protocols................3
3.2 Logical Model.............................................3
4. TWAMP Control.................................................5
4.1 Connection Setup..........................................6
4.2 TWAMP Control Commands....................................6
4.3 Creating Test Sessions....................................6
4.4 Send Schedules............................................6
4.5 Starting Test Sessions....................................6
4.6 Stop-Sessions.............................................6
4.7 Fetch-Session.............................................6
5. TWAMP Test....................................................7
5.1 Sender Behavior...........................................7
5.2 Reflector Behavior........................................8
6. Implementers Guide...........................................12
6.1 Complete TWAMP...........................................12
6.2 TWAMP Light..............................................12
7. Security Considerations......................................13
8. IANA Considerations..........................................13
9. References.................................................1413
9.1 Normative References.....................................14
1. Introduction..................................................3
1.1 Relationship of Test and Control Protocols................3
1.2 Logical Model.............................................3
2. Protocol Overview.............................................5
3. TWAMP Control.................................................5
3.1 Connection Setup..........................................5
3.2 Integrity Protection......................................6
3.3 Value of the Accept Fields................................6
3.4 TWAMP Control Commands....................................6
3.5 Creating Test Sessions....................................6
3.6 Send Schedules............................................8
3.7 Starting Test Sessions....................................8
3.8 Stop-Sessions.............................................8
3.9 Fetch-Session.............................................8
4. TWAMP Test....................................................8
4.1 Sender Behavior...........................................9
4.2 Reflector Behavior........................................9
5. Implementers Guide...........................................14
5.1 Complete TWAMP...........................................14
5.2 TWAMP Light..............................................14
6. Security Considerations......................................15
7. Acknowledgements.............................................15
8. IANA Considerations..........................................15
9. Internationalization Considerations..........................16
10. References..................................................16
10.1 Normative References....................................16
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has proposed The IETF IP Performance Metrics (IPPM) working group has completed
the draft standard for round-trip delay [RFC2681] metric. IPPM has a draft standard for the round-trip delay [RFC2681] metric. IPPM
also proposed a new protocol for establishment of sessions for has also completed a protocol for the control and collection of
measurement of one-way metrics [OWAMP]. Two-way Active Measurement one-way measurements, the One-way Active Measurement Protocol
Protocol uses the methodology and architecture of OWAMP [OWAMP] to (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
define an open protocol for measurement of two-way or round-trip or two-way measurements.
metrics. Henceforth in this document the term two-way also
signifies round-trip.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2681] and indicate requirement levels for compliant
implementations.
3. Protocol Overview
The Two-way Active Measurement Protocol is an open protocol for
measurement of two-way metrics. It is based on OWAMP [OWAMP] and
adheres to its overall architecture and design. The protocol
defined in this document defines extensions and changes to OWAMP
[OWAMP] as follows:
- Define a new logical entity, Session-Reflector, in place of the
Session-Receiver.
- Define the Session-Reflector behavior in place of the
Session-Receiver behavior of OWAMP [OWAMP].
- Define a new test packet format for packets transmitted from the Two-way measurements are common in IP networks, primarily because
Session-Reflector to Session-Sender. time accuracy is less demanding for round-trip delay, and
measurement support at the remote end may be limited to a simple
echo function. This memo specifies the Two-way Active Measurement
Protocol, or TWAMP. TWAMP uses the methodology and architecture of
OWAMP [RFC4656] to define an open protocol for measurement of
two-way or round-trip metrics (henceforth in this document the term
two-way also signifies round-trip). The TWAMP measurement
architecture is usually comprised of only two hosts with specific
roles, and this allows for some protocol simplifications, making it
an attractive alternative in some circumstances.
- Presence of the Fetch client in the system and the support of The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
the Fetch command by the Server are optional. NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119].
3.1 Relationship of Test and Control Protocols 1.1 Relationship of Test and Control Protocols
Similar to OWAMP [OWAMP], 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 [OWAMP]. protocols is as defined in section 1.1 of OWAMP [RFC4656].
1.2 Logical Model
3.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 [OWAMP] with the following exceptions: section 1.2 of OWAMP [RFC4656] with the following exceptions:
- Session-Receiver is called the Session-Reflector in the TWAMP - The Session-Receiver is called the Session-Reflector in the
architecture. TWAMP architecture. The Session-Reflector has the capability
to create and send a measurement packet when it receives a
measurement packet. Unlike the Session-Receiver, the
Session-Reflector does not collect any packet information.
- The presence of the Fetch-Client is optional since two-way - The Server is an end system that manages one or more TWAMP
measurements do not require data retrieval from the sessions, and is capable of configuring per-session state in
Session-Reflector. Consequently the support for the Fetch the end-points. However, a Server associated with a
command is optional by the Server. However, the Server may Session-Reflector would not have the capability to return the
choose to implement the Fetch-Client and support the results of a test session, and this is a difference from OWAMP.
Fetch-Command to enable both one-way and two-way measurements
in the same session. This is explained in more detail in
section 4.7.
Several examples of possible relationship scenarios between these - The Fetch-Client entity does not exist in the TWAMP
roles are presented below. In the first example different logical architecture, as the Session-Reflector does not collect any
roles are played on different hosts. packet information to be fetched. Consequently there is no
need for the Fetch-Client.
An example of possible relationship scenarios between these roles
are presented below. In this example different logical roles are
played on different hosts. Unlabeled links in the figure are
unspecified by this document and may be proprietary protocols.
+----------------+ +-------------------+ +----------------+ +-------------------+
| Session-Sender |<-TWAMP-Test-->| Session-Reflector | | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
+----------------+ +-------------------+ +----------------+ +-------------------+
^ ^ ^ ^
| | | |
| | | |
| | | |
| +----------------+<----------------+ | +----------------+<----------------+
| | Server |<-------+ | | Server |
| +----------------+ |
| ^ |
| | |
| TWAMP-Control TWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
Second example is similar to the first example without the
Fetch-Client. In this example only two-way metrics are collected.
+----------------+ +-------------------+
| Session-Sender |<--TWAMP-Test-->| Session-Reflector |
+----------------+ +-------------------+
^ ^
| |
| |
| |
| +----------------+ |
| | Server |<-----------------+
| +----------------+ | +----------------+
| ^ | ^
| | | |
| TWAMP-Control | TWAMP-Control
| | | |
v V v v
+----------------+ +----------------+
| Control-Client | | Control-Client |
+----------------+ +----------------+
Similar to OWAMP [OWAMP] different logical roles can be played by As in OWAMP [RFC4656], different logical roles can be played by the
the same host. For example, in the figure above, there could be same host. For example, in the figure above, there could be
actually two hosts: one playing the role of Control-Client, actually two hosts: one playing the roles of Control-Client and
Fetch-Client, Session-Sender, and Server, and the other playing the Session-Sender, and the other playing the roles of Server and
role of Session-Reflector. This is the third example shown below. Session-Reflector. This example is shown below.
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| Server |<------------------| | | Control-Client |<--TWAMP Control-->| Server |
| Control-Client | | Session-Reflector | | | | |
| Session-Sender |<--TWAMP-Test----->| | | Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
Additionally, following the guidelines of OWAMP [RFC4656], TWAMP
has been defined to allow for small test packets that would fit
inside the payload of a single ATM cell (only in unauthenticated
mode).
Additionally, following the guidelines of OWAMP [OWAMP], TWAMP has 2. Protocol Overview
been defined to allow for small test packets that would fit inside
the payload of a single ATM cell (only in unauthenticated mode).
4. TWAMP Control The Two-way Active Measurement Protocol is an open protocol for
measurement of two-way metrics. It is based on OWAMP [RFC4656] and
adheres to its overall architecture and design. The protocol
defined in this document extends and changes OWAMP [RFC4656] as
follows:
All TWAMP Control messages are similar in format to and follow the - Define a new logical entity, Session-Reflector, in place of the
same guidelines defined in section 3 of OWAMP [OWAMP]. Session-Receiver.
4.1 Connection Setup - Define the Session-Reflector behavior in place of the
Session-Receiver behavior of OWAMP [RFC4656].
- Define a new test packet format for packets transmitted from the
Session-Reflector to Session-Sender.
- Fetch client does not exist in the TWAMP architecture.
3. TWAMP Control
All TWAMP Control messages are similar in format and follow similar
guidelines to those defined in section 3 of OWAMP [RFC4656] with
the exceptions outlined in the following sections. All OWAMP
[RFC4656] Control messages except for the Fetch-Session command
apply to TWAMP.
3.1 Connection Setup
Connection establishment of TWAMP follows the same procedure Connection establishment of TWAMP follows the same procedure
defined in section 3.1 of OWAMP [OWAMP]. defined in section 3.1 of OWAMP [RFC4656]. The host that initiates
the TCP connection takes the roles of Control-Client and (in the
two-host implementation) the Session-Sender. The host that
acknowledges the TCP connection accepts the roles of Server and (in
the two-host implementation) the Session Reflector.
4.2 TWAMP Control Commands 3.2 Integrity Protection
TWAMP control commands are as defined in section 3.3 of OWAMP Integrity protection of TWAMP follows the same procedure defined in
[OWAMP] except for the optional requirement of the Fetch-Session section 3.2 of OWAMP [RFC4656].
command.
4.3 Creating Test Sessions 3.3 Value of the Accept Fields
Accept values used in TWAMP are the same as the values defined in
section 3.3 of OWAMP [RFC4656].
3.4 TWAMP Control Commands
TWAMP control commands are as defined in section 3.4 of OWAMP
[RFC4656] except that the Fetch-Session command does not apply to
TWAMP.
3.5 Creating Test Sessions
Test sessions creation follows the same procedure as defined in Test sessions creation follows the same procedure as defined in
section 3.4 of OWAMP [OWAMP]. In order to distinguish the session section 3.5 of OWAMP [RFC4656].
as a two-way versus a one-way measurement session the first octet
of the Request-Session command MUST be set to 5. Value of 5
indicates that this is a Request-Session for a two-way metrics
measurement session.
4.4 Send Schedules In order to distinguish the session as a two-way versus a one-way
measurement session the first octet of the Request-Session command
MUST be set to 5. Value of 5 indicates that this is a
Request-Session for a two-way metrics measurement session.
Send schedule of test packets follow the same procedure and In OWAMP, the Conf-Sender field is set to 1 when the
guidelines as defined in section 3.5 of OWAMP [OWAMP]. Request-Session message describes a task where the Server will
configure a one-way test packet sender. Likewise, the
Conf-Receiver field is set to 1 when the message describes the
configuration for a Session-Receiver. In TWAMP, both endpoints
perform in these roles, with the Session-Sender first sending and
then receiving test packets. The Session-Reflector first receives
the test packets, and returns each test packet to the
Session-Sender as fast as possible.
4.5 Starting Test Sessions Both Conf-Sender and Conf-Receiver MUST be set to 0 since the
Session-Reflector will both receive and send packets, and the roles
are established according to which host initiates the TCP
connection for control. The server MUST interpret any non-zero
value as zero.
Starting test sessions follow the same procedure and guidelines as The Session-Reflector in TWAMP does not process incoming test
defined in section 3.6 of OWAMP [OWAMP]. packets for performance metrics and consequently does not need to
know the number of incoming packets and their timing schedule.
Consequently the Number of Scheduled Slots and Number of Packets
MUST be set to 0.
4.6 Stop-Sessions The Sender Port is the UDP port from which TWAMP-Test packets will
be sent. Receiver Port is the UDP port to which TWAMP test packets
are reflected by the Session-Reflector (the port where the
Session-Sender wants to receive test packets).
Stopping test sessions follow the same procedure and guidelines as The Sender Address and Receiver Address fields contain,
defined in section 3.7 of OWAMP [OWAMP]. respectively, the sender and receiver addresses of the endpoints of
the Internet path over which a TWAMP test session is requested.
They MAY be set to 0, in which case the IP addresses used for the
Session-Sender to Session-Reflector Control Message exchange MUST
be used in the test packets.
The SID is as defined in OWAMP [RFC4656]. Since the SID is always
generated by the receiving side, the Session-Reflector determines
the SID, and the SID in the Request-Session message MUST be set to
0.
The Start Time is as as defined in OWAMP [RFC4656].
The Timeout is interpreted differently from the definition in OWAMP
[RFC4656]. In TWAMP, Timeout is the interval that the
Session-Reflector MUST wait after receiving a Stop-Sessions
message. In case there are test packets still in transit, the
Session Reflector MUST reflect them if they arrive within the
timeout interval following the reception of the Stop-Sessions
message. The Session-Reflector MUST NOT reflect packets that are
received beyond the timeout.
Type-P descriptor is as defined in OWAMP [RFC4656]. The only
capability of this field is to set the Differentiated Services Code
Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST
be used in test packets reflected by the Session-Reflector.
Since there are no Schedule Slot Descriptions, the Request-Session
Message is followed by HMAC. This completes one logical message,
referred to as the Request-Session Command.
The Session-Reflector MUST respond to each Request-Session Command
with an Accept-Message as defined in OWAMP [RFC4656]. The Port is
the port to which TWAMP test packets are sent by the Session-Sender
toward the Session-Reflector. In other words, the Port field
indicates the port number where the Session-Reflector expects to
receive packets from the Session-Sender.
3.6 Send Schedules
The Send Schedule for test packets defined in section 3.6 of OWAMP
[RFC4656] is not used in TWAMP. The Control-Client and
Session-Sender MAY autonomously decide the Send Schedule. The
Session-Reflector SHOULD return each test packet to the
Session-Sender as quickly as possible.
3.7 Starting Test Sessions
The procedure and guidelines for Starting test sessions is the same
as defined in section 3.7 of OWAMP [RFC4656].
3.8 Stop-Sessions
The procedure and guidelines for Stopping test sessions is the same
as defined in section 3.8 of OWAMP [RFC4656]. The Stop-Session
command can only be issued by the Session-Sender. The Next SeqNo
and Number of Skip Ranges MUST be set to 0 and the message MUST NOT
contain any session description records or skip ranges. The
message is terminated with a single block HMAC, to complete the
Stop-Sessions Command.
3.9 Fetch-Session
4.7 Fetch-Session
The purpose of TWAMP is measurement of two-way metrics. Two-way The purpose of TWAMP is measurement of two-way metrics. Two-way
measurements do not rely on packet level data collected by the measurements do not rely on packet level data collected by the
Session-Reflector such as sequence number, timestamp, and TTL. As Session-Reflector such as sequence number, timestamp, and TTL. As
such the protocol does not require the retrieval of packet level such the protocol does not require the retrieval of packet level
data from the Server and the Fetch-Session command is optionally data from the Server and the Fetch-Session command is not defined
supported by the Server. in TWAMP.
However, TWAMP can be used as an extension to OWAMP [OWAMP] where
both one-way and two-way measurements are measured in the same
session. In this case the Server MAY support the Fetch-Session
command as defined in section 3.8 of OWAMP[OWAMP]. The
Session-Reflector will reject the Fetch-Session request if either
it does not support the Fetch-Session command or Session-Reflector
cannot provide the required data. In this case the server MUST
respond with a Fetch-Ack message with Accept value of 3.
5. TWAMP Test 4. TWAMP Test
The TWAMP test protocol is similar to the OWAMP [OWAMP] test The TWAMP test protocol is similar to the OWAMP [RFC4656] test
protocol with the exception that the Session-Reflector transmits protocol with the exception that the Session-Reflector transmits
test packets to the Session-Sender in response to each test packet test packets to the Session-Sender in response to each test packet
it receives. TWAMP defines two different test packet formats, one it receives. TWAMP defines two different test packet formats, one
for packets transmitted by the Session-Sender and one for packets for packets transmitted by the Session-Sender and one for packets
transmitted by the Session-Reflector. As with OWAMP [OWAMP] test transmitted by the Session-Reflector. As with OWAMP [RFC4656] test
protocol there are three modes: unauthenticated, authenticated, and protocol there are three modes: unauthenticated, authenticated, and
encrypted. encrypted.
5.1 Sender Behavior 4.1 Sender Behavior
The sender behavior is as defined in section 4.1 of OWAMP [OWAMP] The sender behavior is determined by the configuration of the
for both packet timing and packet format. Additionally the Session-Sender and is not defined in this standard. Further, the
Session-Sender records the necessary information provided by the Session-Reflector does not need to know the Session-Sender
packets transmitted by the Session-Reflector for measuring two-way behaviour to the degree of detail as needed in OWAMP [RFC4656].
metrics. The information recording based on the received packet by Additionally the Session-Sender collects and records the necessary
the Session-Sender is implementation dependent. information provided from the packets transmitted by the
Session-Reflector for measuring two-way metrics. The information
recording based on the received packet by the Session-Sender is
implementation dependent.
5.1.1 Packet Timings 4.1.1 Packet Timings
Packet timings follow the same procedure and guidelines as defined Since the Send Schedule is not communicated to the
in section 4.1.1 of OWAMP [OWAMP]. Session-Reflector, there is no need for a standardized computation
of packet timing.
5.1.2 Packet Format and Content Regardless of any scheduling delays, each packet that is actually
sent MUST have the best possible approximation of its real time of
departure as its timestamp (in the packet).
Session-Sender packet format and content follow the same procedure 4.1.2 Packet Format and Content
and guidelines as defined in section 4.1.2 of OWAMP [OWAMP].
5.2 Reflector Behavior The Session-Sender packet format and content follow the same
procedure and guidelines as defined in section 4.1.2 of OWAMP
[RFC4656] (with the exception of the reference to the Send
Schedule).
When receiving packets the reflector behavior is same as 4.2 Reflector Behavior
Session-Receiver behavior defined in section 4.2 of OWAMP [OWAMP]
with the exception of optional packet information recording. If TWAMP requires the Session-Reflector to transmit a packet to the
the Session-Reflector chooses not to collect packet information for Session-Sender in response to each packet it receives.
packets received from the Session-Sender, the Server will not
support the Fetch-Session command. Additionally, TWAMP requires
the Session-Reflector to transmit a packet to the Session-Sender in
response to each packet it receives.
As packets are received the Session-Reflector will, As packets are received the Session-Reflector will,
- Timestamp the received packet. - Timestamp the received packet. Each packet that is actually
received MUST have the best possible approximation of its real
time of arrival entered as its timestamp (in the packet).
- In authenticated or encrypted mode, decrypt the first block (16 - In authenticated or encrypted mode, decrypt the first block (16
octets) of the packet body. octets) of the packet body.
- 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.
- Optionally store the packet sequence number, send time, receive
time, and the TTL for IPv4 (or Hop Limit for IPv6) from the
packet IP header for the results to be transferred.
- Packets not received within the Timeout are considered lost.
They are optionally recorded with their true sequence number,
presumed send time, receive time consisting of a string of zero
bits, and TTL (or Hop Limit) of 255. The Session-Reflector
will not generate a test packet to the Session-Sender for
packets that are considered lost.
- Transmit a test packet to the Session-Sender in response to - Transmit a test packet to the Session-Sender in response to
every received packet. The response must be generated as every received packet. The response MUST be generated as
immediately as possible. The format and content of the test immediately as possible. The format and content of the test
packet is defined in section 5.2.1. Prior to the transmission packet is defined in section 5.2.1. Prior to the transmission
of the test packet Session-Reflector MUST determine the elapsed of the test packet, the Session-Reflector MUST enter the best
time since the reception of the packet for incorporating the possible approximation of its actual sending time of as its
value in the reflected test packet. Timestamp (in the packet). This permits the determination of the
elapsed time between the reception of the packet and its
transmission.
5.2.1 Packet Format and Content - Packets not received within the Timeout are ignored by the
Reflector. The Session-Reflector MUST NOT generate a test
packet to the Session-Sender for packets that are ignored.
4.2.1 TWAMP-Test Packet Format and Content
The Session-Reflector MUST transmit a packet to the Session-Sender The Session-Reflector MUST transmit a packet to the Session-Sender
in response to each packet received. The Session-Reflector SHOULD in response to each packet received. The Session-Reflector SHOULD
transmit the packets as immediately as possible. The transmit the packets as immediately as possible. The
Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)
in the UDP packet to 255. in the UDP packet to 255.
The test packet will have the necessary information for calculating The test packet will have the necessary information for calculating
two-way metrics by the Session-Sender. The format of the test two-way metrics by the Session-Sender. The format of the test
packet depends on the mode being used. The format of the packet is packet depends on the mode being used. The various formats of the
presented below. packet are 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 10, line 48 skipping to change at page 12, line 48
| IZP (6 octets) | | IZP (6 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number is the sequence number of the test packet and Sequence Number is the sequence number of the test packet according
starts with zero and is incremented by one for each subsequent to its arrival at the Session-Reflector. It starts with zero and
packet. The generated sequence number by the Session-Reflector, is incremented by one for each subsequent packet. The Sequence
Sequence Number, is independent from the sequence number of the Number generated by the Session-Reflector is independent from the
received packets. sequence number of the arriving packets.
Timestamp and Error Estimate are the transmit timestamp and error Timestamp and Error Estimate are the Session-Reflector's transmit
estimate of the test packet respectively. Sender Timestamp and timestamp and error estimate for the reflected test packet,
Sender Error Estimate are exact copies of the timestamp and error respectively. The format of all timestamp and error estimate
estimate from the Session-Sender test packet that corresponds to fields follow the definition and formats defined by OWAMP[RFC4656].
this test packet. The format of all timestamp and error estimate
fields follow the definition and formats defined by OWAMP[OWAMP]. Sender Timestamp and Sender Error Estimate are exact copies of the
timestamp and error estimate from the Session-Sender test packet
that corresponds to this test packet.
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 the amount of time the packet was in transition in the is the amount of time the packet was in transition in the
Session-Reflector. The Error Estimate of Timestamp also applies to Session-Reflector. The Error Estimate associated with the
Receive Timestamp. Timestamp field also applies to the Receive Timestamp.
Sender Sequence Number is the Sequence Number of the packet Sender Sequence Number is a copy of the Sequence Number of the
transmitted by the Session-Sender that corresponds to this test packet transmitted by the Session-Sender that caused the
packet. Session-Reflector to generate and send this test packet.
Similar to OWAMP [OWAMP] the TWAMP packet layout is the same in Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in
authenticated and encrypted modes. The encryption operation of authenticated and encrypted modes. The encryption operation of
Session-Receiver packet follow the same rules of Session-Sender Session-Sender packet follow the same rules of Session-Sender
packets as defined in OWAMP [OWAMP]. packets as defined in OWAMP [RFC4656].
The minimum data segment length is, therefore, 40 octets in The minimum data segment length is, therefore, 40 octets in
unauthenticated mode, and 80 octets in both authenticated mode and unauthenticated mode, and 80 octets in both authenticated mode and
encrypted modes. encrypted modes (with the implication that the later two modes will
not fit in a single ATM cell).
The Session-Reflector TWAMP-Test packet layout is the same in The Session-Reflector TWAMP-Test packet layout is the same in
authenticated and encrypted modes. The encryption operations are, authenticated and encrypted modes. The encryption operations are,
however, different. The difference is that in encrypted mode both however, different. The difference is that in encrypted mode both
the sequence numbers and timestamps are encrypted to provide the sequence numbers and timestamps are encrypted to provide
maximum data integrity protection while in authenticated mode the maximum data integrity protection while in authenticated mode the
sequence numbers are encrypted and the timestamps are sent in clear sequence numbers are encrypted and the timestamps are sent in clear
text. Sending the timestamp in clear text in authenticated mode text. Sending the timestamp in clear text in authenticated mode
allows one to reduce the time between when a timestamp is obtained allows one to reduce the time between when a timestamp is obtained
by a reflector and when the packet is reflected out. In encrypted by a reflector and when the packet is reflected out. In encrypted
mode, both the sender and reflector have to fetch the timestamp, mode, both the sender and reflector have to fetch the timestamp,
encrypt it, and send it; in authenticated mode, the middle step is encrypt it, and send it; in authenticated mode, the middle step is
removed, potentially improving accuracy (the sequence number can be removed, potentially improving accuracy (the sequence number can be
encrypted before the timestamp is fetched). encrypted before the timestamp is fetched).
In authenticated mode, the first block (32 octets) of each packet In authenticated mode, the first block (32 octets) of each packet
is encrypted using AES Electronic Cookbook (ECB) mode. is encrypted using AES Electronic Cookbook (ECB) mode.
Obtaining the key, encryption method, and packet padding is as Obtaining the key, encryption method, and packet padding is as
defined in section 4.1.2 of OWAMP [OWAMP]. In unauthenticated defined in section 4.1.2 of OWAMP [RFC4656]. In unauthenticated
mode, no encryption is applied. mode, no encryption is applied.
6. Implementers Guide 5. Implementers Guide
This section serves as guidance to implementers of TWAMP. Two This section serves as guidance to implementers of TWAMP. Two
architectures are presented in this section for implementations architectures are presented in this section for implementations
where two hosts play the subsystem roles of TWAMP. Although only where two hosts play the subsystem roles of TWAMP. Although only
two architectures are presented here the protocol does not require two architectures are presented here the protocol does not require
their use. Similar to OWAMP [OWAMP] TWAMP is designed with their use. Similar to OWAMP [RFC4656] TWAMP is designed with
complete flexibility to allow different architectures that suite complete flexibility to allow different architectures that suite
multiple system requirements. multiple system requirements.
6.1 Complete TWAMP 5.1 Complete TWAMP
In this example the roles of Control-Client, Fetch-Client, and In this example the roles of Control-Client and Session-Sender are
Session-Sender are implemented in one host referred to as the implemented in one host referred to as the controller and the roles
controller and the roles of Server and Session-Receiver are of Server and Session-Reflector are implemented in another host
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 |
| Fetch-Client | | | | | | |
| 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-Receiver behavior of both OWAMP The responder follows the Session-Reflctor behavior of TWAMP as
[OWAMP] and TWAMP as described in section 5.2. In this described in section 4.2.
architecture the responder supports the Fetch-Session command.
After the transmission of test packets the controller fetches the
responder's information through its Fetch-Client. This
architecture allows for collection of both one-way and two-way
metrics.
6.2 TWAMP Light 5.2 TWAMP Light
In this example the roles of Control-Client, Server, and In this example the roles of Control-Client, Server, and
Session-Sender are implemented in one host referred to as the Session-Sender are implemented in one host referred to as the
controller and the role of Session-Receiver is implemented in controller and the role of Session-Reflector is implemented in
another host referred to as the responder. another host referred 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. The controller establishes the test session with the network. The controller establishes the test session with the
Server through non-standard means. After the session is Server through non-standard means. 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-Receiver behavior of TWAMP as The responder follows the Session-Reflector behavior of TWAMP as
described in section 5.2.1 with the following exceptions. The described in section 4.2 with the following exceptions. The
Session-Reflector SHOULD copy the sequence number of the received Session-Reflector SHOULD copy the sequence number of the received
packet to the Sequence Number field of the reflected packet. This packet to the Sequence Number field of the reflected packet. This
is necessary since in case of TWAMP Light the Session-Reflector is necessary since in case of TWAMP Light the Session-Reflector
does not have knowledge of the session state. The controller does not have knowledge of the session state. The controller
receives the reflected test packets and collects two-way metrics. receives the reflected test packets and collects two-way metrics.
This architecture allows for collection of two-way metrics. This architecture allows for collection 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 configuration with the Server through non-standard means. its configuration with the Server through non-standard means. The
Furthermore, the Server does not support the Fetch-Session command Session-Reflector simply reflects the incoming packets back to the
and the responder does not collect the received packet information. controller while copying the necessary information and generating
The Session-Reflector simply reflects the incoming packets back to sequence number and timestamp values per section 5.2.1.
the controller while copying the necessary information and
generating sequence number and timestamp values per section 5.2.1.
7. Security Considerations 6. Security Considerations
The security considerations of OWAMP [OWAMP] apply. The security considerations of OWAMP [RFC4656] apply.
8. IANA Considerations 7. Acknowledgements
There are no IANA considerations associated with this We would like to thank Nagarjuna Venn, Sharee McNab, Nick Kinraid,
specification. and Stanislav Shalunov for their comments, suggestions, reviews,
helpful discussion and proof-reading.
9. Acknowledgements 8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol which also
applies to the TWAMP-Control part of the TWAMP protocol.
The authors wish to thank Sharee McNab and Nick Kinraid for their 9. Internationalization Considerations
comments and suggestions.
The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in TWAMP-Control, which is
encoded in UTF-8.
10. References 10. References
10.1 Normative References 10.1 Normative References
[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
Zekauskas, M., "A One-way Active Measurement Protocol Zekauskas, M., "A One-way Active Measurement Protocol
(OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004.
[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A
Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, Round-Trip Delay Metric for IPPM". RFC 2681, STD 1,
September 1999. September 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824
US USA
Phone: +1 978 367 5611
EMail: khedayat@brixnet.com EMail: khedayat@brixnet.com
URI: http://www.brixnet.com/ URI: http://www.brixnet.com/
Roman M. Krzanowski, Ph.D. Roman M. Krzanowski, Ph.D.
Verizon Verizon
500 Westchester Ave. 500 Westchester Ave.
White Plains, NY White Plains, NY
US USA
Phone: +1 914 644 2395
EMail: roman.krzanowski@verizon.com EMail: roman.krzanowski@verizon.com
URI: http://www.verizon.com/ URI: http://www.verizon.com/
Al Morton
AT&T Labs
Room D3 - 3C06
200 Laurel Ave. South
Middletown, NJ 07748
USA
Phone +1 732 420 1571
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Kiho Yum Kiho Yum
Juniper Networks Juniper Networks
1194 Mathilda Ave. 1194 Mathilda Ave.
Sunnyvale, CA Sunnyvale, CA
US USA
Phone: +1 408 936 2272
EMail: kyum@juniper.net EMail: kyum@juniper.net
URI: http://www.juniper.com/ URI: http://www.juniper.com/
IPR Disclosure Acknowledgement Jozef Z. Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont K2H 8E9
Canada
Email: babiarz@nortel.com
URI: http://www.nortel.com/
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 15, line 38 skipping to change at page 18, line 42
of such proprietary rights by implementers or users of this of 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 http://www.ietf.org/ipr. at 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.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Notice
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 94 change blocks. 
288 lines changed or deleted 401 lines changed or added

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