draft-ietf-ippm-twamp-03.txt   draft-ietf-ippm-twamp-04.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: September 2007 R. Krzanowski Expires: November 2007 R. Krzanowski
Verizon Verizon
K. Yum K. Yum
Juniper Networks Juniper Networks
A. Morton A. Morton
AT&T Labs AT&T Labs
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-03 draft-ietf-ippm-twamp-04
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 35 skipping to change at page 2, line 35
3. TWAMP Control.................................................5 3. TWAMP Control.................................................5
3.1 Connection Setup..........................................5 3.1 Connection Setup..........................................5
3.2 Integrity Protection......................................6 3.2 Integrity Protection......................................6
3.3 Value of the Accept Fields................................6 3.3 Value of the Accept Fields................................6
3.4 TWAMP Control Commands....................................6 3.4 TWAMP Control Commands....................................6
3.5 Creating Test Sessions....................................6 3.5 Creating Test Sessions....................................6
3.6 Send Schedules............................................8 3.6 Send Schedules............................................8
3.7 Starting Test Sessions....................................8 3.7 Starting Test Sessions....................................8
3.8 Stop-Sessions.............................................8 3.8 Stop-Sessions.............................................8
3.9 Fetch-Session.............................................8 3.9 Fetch-Session.............................................8
4. TWAMP Test....................................................8 4. TWAMP Test....................................................9
4.1 Sender Behavior...........................................9 4.1 Sender Behavior...........................................9
4.2 Reflector Behavior........................................9 4.2 Reflector Behavior.......................................10
5. Implementers Guide...........................................15 5. Implementers Guide...........................................15
5.1 Complete TWAMP...........................................15 5.1 Complete TWAMP...........................................15
5.2 TWAMP Light..............................................16 5.2 TWAMP Light..............................................16
6. Security Considerations......................................17 6. Security Considerations......................................17
7. Acknowledgements.............................................17 7. Acknowledgements.............................................17
8. IANA Considerations..........................................17 8. IANA Considerations..........................................17
9. Internationalization Considerations..........................17 9. Internationalization Considerations..........................18
10. References..................................................18 10. References..................................................18
10.1 Normative References....................................18 10.1 Normative References....................................18
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has completed The IETF IP Performance Metrics (IPPM) working group has completed
a draft standard for the round-trip delay [RFC2681] metric. IPPM a draft standard for the round-trip delay [RFC2681] metric. IPPM
has also completed a protocol for the control and collection of has also completed a protocol for the control and collection of
one-way measurements, the One-way Active Measurement Protocol one-way measurements, the One-way Active Measurement Protocol
(OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip
or two-way measurements. or two-way measurements.
skipping to change at page 7, line 12 skipping to change at page 7, line 12
connection for control. The server MUST interpret any non-zero connection for control. The server MUST interpret any non-zero
value as zero. value as zero.
The Session-Reflector in TWAMP does not process incoming test The Session-Reflector in TWAMP does not process incoming test
packets for performance metrics and consequently does not need to packets for performance metrics and consequently does not need to
know the number of incoming packets and their timing schedule. know the number of incoming packets and their timing schedule.
Consequently the Number of Scheduled Slots and Number of Packets Consequently the Number of Scheduled Slots and Number of Packets
MUST be set to 0. MUST be set to 0.
The Sender Port is the UDP port from which TWAMP-Test packets will The Sender Port is the UDP port from which TWAMP-Test packets will
be sent. Receiver Port is the UDP port to which TWAMP test packets be sent and the port to which TWAMP-Test packets will be sent by
are reflected by the Session-Reflector (the port where the the Session-Reflector (Session-Sender will use the same UDP port to
Session-Sender wants to receive test packets). send and receive packets). Receiver Port is the desired UDP port
to which TWAMP test packets will be sent by the Session-Sender (the
port where the Session-Reflector is asked to receive test packets).
Receiver Port is also the UDP port from which TWAMP test packets
will be sent by the Session-Reflector (Session-Reflector will use
the same UDP port to send and receive packets).
The Sender Address and Receiver Address fields contain, The Sender Address and Receiver Address fields contain,
respectively, the sender and receiver addresses of the endpoints of respectively, the sender and receiver addresses of the endpoints of
the Internet path over which a TWAMP test session is requested. the Internet path over which a TWAMP test session is requested.
They MAY be set to 0, in which case the IP addresses used for the They MAY be set to 0, in which case the IP addresses used for the
Session-Sender to Session-Reflector Control Message exchange MUST Session-Sender to Session-Reflector Control Message exchange MUST
be used in the test packets. be used in the test packets.
The SID is as defined in OWAMP [RFC4656]. Since the SID is always The SID is as defined in OWAMP [RFC4656]. Since the SID is always
generated by the receiving side, the Session-Reflector determines generated by the receiving side, the Session-Reflector determines
skipping to change at page 7, line 49 skipping to change at page 8, line 6
Type-P descriptor is as defined in OWAMP [RFC4656]. The only Type-P descriptor is as defined in OWAMP [RFC4656]. The only
capability of this field is to set the Differentiated Services Code capability of this field is to set the Differentiated Services Code
Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST
be used in test packets reflected by the Session-Reflector. be used in test packets reflected by the Session-Reflector.
Since there are no Schedule Slot Descriptions, the Request-Session Since there are no Schedule Slot Descriptions, the Request-Session
Message is completed by MBZ and HMAC fields. This completes one Message is completed by MBZ and HMAC fields. This completes one
logical message, referred to as the Request-Session Command. logical message, referred to as the Request-Session Command.
The Session-Reflector MUST respond to each Request-Session Command The Session-Reflector MUST respond to each Request-Session Command
with an Accept-Message as defined in OWAMP [RFC4656]. The Port is with an Accept-Message as defined in OWAMP [RFC4656]. When the
the port to which TWAMP test packets are sent by the Session-Sender Accept Field = 0, the Port field confirms (repeats) the port to
toward the Session-Reflector. In other words, the Port field which TWAMP test packets are sent by the Session-Sender toward the
indicates the port number where the Session-Reflector expects to Session-Reflector. In other words, the Port field indicates the
receive packets from the Session-Sender. port number where the Session-Reflector expects to receive packets
from the Session-Sender.
When the requested Receiver Port is not available (e.g., port in
use), the Server at the Session-Reflector MAY suggest an alternate
and available port for this session in the Port Field. The
Session-Sender either accepts the alternate port, or composes a new
Session-Request message with suitable parameters. Otherwise, the
Server at the Session-Reflector uses the Accept Field to convey
other forms of session rejection or failure and MUST NOT suggest an
alternate port. 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-Sender MAY autonomously decide the Send Schedule. The Session-Sender MAY autonomously decide the Send Schedule. The
Session-Reflector SHOULD return each test packet to the Session-Reflector SHOULD return each test packet to the
Session-Sender as quickly as possible. Session-Sender as quickly as possible.
3.7 Starting Test Sessions 3.7 Starting Test Sessions
skipping to change at page 10, line 17 skipping to change at page 10, line 29
- Timestamp the received packet. Each packet that is actually - Timestamp the received packet. Each packet that is actually
received MUST have the best possible approximation of its real received MUST have the best possible approximation of its real
time of arrival entered as its timestamp (in the packet). time of arrival entered as its timestamp (in the packet).
- In authenticated or encrypted mode, decrypt the first block (16 - In authenticated or encrypted mode, decrypt the 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.
- Sender TTL value is extracted from the TTL/Hop Limit value of
received packets. Session-Reflector Implementations SHOULD
fetch the TTL/Hop Limit value from the IP header of the packet,
replacing the value of 255 set by the Session-Sender. If an
implementation does not fetch the actual TTL value (the only
good reason not to do so is an inability to access the TTL
field of arriving packets), it MUST set the Sender TTL value as
255.
- 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, the Session-Reflector MUST enter the best of the test packet, the Session-Reflector MUST enter the best
possible approximation of its actual sending time of as its possible approximation of its actual sending time of as its
Timestamp (in the packet). This permits the determination of the Timestamp (in the packet). This permits the determination of
elapsed time between the reception of the packet and its the elapsed time between the reception of the packet and its
transmission. transmission.
- Packets not received within the Timeout are ignored by the - Packets not received within the Timeout are ignored by the
Reflector. The Session-Reflector MUST NOT generate a test Reflector. The Session-Reflector MUST NOT generate a test
packet to the Session-Sender for packets that are ignored. packet to the Session-Sender for packets that are ignored.
4.2.1 TWAMP-Test Packet Format and Content 4.2.1 TWAMP-Test Packet Format and Content
The Session-Reflector MUST transmit a packet to the Session-Sender The Session-Reflector MUST transmit a packet to the Session-Sender
in response to each packet received. The Session-Reflector SHOULD in response to each packet received. The Session-Reflector SHOULD
skipping to change at page 11, line 27 skipping to change at page 11, line 40
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number | | Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ | | Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+++++++++++++++++ |
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated and encrypted modes: For authenticated and encrypted modes:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 12, line 41 skipping to change at page 12, line 41
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | | | Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) | | MBZ (6 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+++++++++++++++++ |
| MBZ (7 octets) |
| |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
skipping to change at page 13, line 19 skipping to change at page 13, line 25
Timestamp and Error Estimate are the Session-Reflector's transmit Timestamp and Error Estimate are the Session-Reflector's transmit
timestamp and error estimate for the reflected test packet, timestamp and error estimate for the reflected test packet,
respectively. The format of all timestamp and error estimate respectively. The format of all timestamp and error estimate
fields follow the definition and formats defined by OWAMP[RFC4656]. fields follow the definition and formats defined by OWAMP[RFC4656].
Sender Timestamp and Sender Error Estimate are exact copies of the Sender Timestamp and Sender Error Estimate are exact copies of the
timestamp and error estimate from the Session-Sender test packet timestamp and error estimate from the Session-Sender test packet
that corresponds to this test packet. that corresponds to this test packet.
Sender TTL is 255 when transmitted by the Session Sender. Sender
TTL 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
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 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 associated with the Session-Reflector. The Error Estimate associated with the
Timestamp field also applies to the Receive Timestamp. Timestamp field 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 transmitted by the Session-Sender that caused the packet transmitted by the Session-Sender that caused the
Session-Reflector to generate and send this test packet. Session-Reflector to generate and send this test packet.
skipping to change at page 16, line 39 skipping to change at page 17, line 4
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-Reflector behavior of TWAMP as The responder follows the Session-Reflector behavior of TWAMP as
described in section 4.2 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 necessarily have knowledge of the session state. The
receives the reflected test packets and collects two-way metrics. controller receives the reflected test packets and collects two-way
This architecture allows for collection of two-way metrics. 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. The its configuration with the Server through non-standard means. The
Session-Reflector simply reflects the incoming packets back to the Session-Reflector simply reflects the incoming packets back to the
controller while copying the necessary information and generating controller while copying the necessary information and generating
sequence number and timestamp values per section 5.2.1. sequence number and timestamp values per section 5.2.1.
6. Security Considerations 6. Security Considerations
Fundamentally TWAMP and OWAMP use the same protocol for Fundamentally TWAMP and OWAMP use the same protocol for
establishment of Control and Test procedures. The main difference establishment of Control and Test procedures. The main difference
between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
vs. the Session-Receiver behavior in OWAMP. This difference in vs. the Session-Receiver behavior in OWAMP. This difference in
behavior does not introduce any known security vulnerabilities that behavior does not introduce any known security vulnerabilities that
are not already addressed by the security features of OWAMP. The are not already addressed by the security features of OWAMP. The
entire security considerations of OWAMP [RFC4656] applies to TWAMP. entire security considerations of OWAMP [RFC4656] applies to TWAMP.
The only area where TWAMP may introduce new security considerations
is the TWAMP Light version described above. The non-standard means
to control the responder and establish test sessions SHOULD offer
the features listed below.
The non-standard responder control protocol SHOULD have an
authenticated mode of operation. The responder SHOULD be
configurable to accept only authenticated control sessions.
The non-standard responder control protocol SHOULD have a means to
activate the authenticated and encrypted modes of the TWAMP-Test
protocol.
7. Acknowledgements 7. Acknowledgements
We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
and Stanislav Shalunov for their comments, suggestions, reviews, and Stanislav Shalunov for their comments, suggestions, reviews,
helpful discussion and proof-reading. helpful discussion and proof-reading.
8. IANA Considerations 8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol which also OWAMP-Control part of the OWAMP [RFC4656] protocol which also
applies to the TWAMP-Control part of the TWAMP protocol. applies to the TWAMP-Control part of the TWAMP protocol.
9. Internationalization Considerations 9. Internationalization Considerations
The protocol does not carry any information in a natural language, The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in TWAMP-Control, which is with the possible exception of the KeyID in TWAMP-Control, which is
encoded in UTF-8. encoded in UTF-8.
 End of changes. 15 change blocks. 
19 lines changed or deleted 68 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/