< draft-ietf-ippm-twamp-00.txt   draft-ietf-ippm-twamp-01.txt >
J. Babiarz J. Babiarz
Internet Draft Nortel Networks Internet Draft Nortel Networks
Expires: May 11, 2006 K. Hedayat Expires: December 2006 K. Hedayat
Brix Networks Brix Networks
R. Krzanowski R. Krzanowski
Verizon Verizon
Kiho Yum Kiho Yum
Juniper Networks Juniper Networks
November 7, 2005 June 2006
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-00 draft-ietf-ippm-twamp-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The IPPM One-way Active Measurement Protocol [OWAMP] provides a The IPPM One-way Active Measurement Protocol [OWAMP] provides a
common protocol for measuring one-way metrics between network common protocol for measuring one-way metrics between network
devices. OWAMP [OWAMP] can be used in both directions devices. OWAMP [OWAMP] can be used in both directions
independently to measure one-way metrics in both directions between independently to measure one-way metrics in both directions between
two network elements. However, it does not accommodate round-trip two network elements. However, it does not accommodate round-trip
or two-way measurements. This draft proposes a Two-way Active or two-way measurements. This draft proposes a Two-way Active
Measurement Protocol, based on the One-way Active Measurement Measurement Protocol, based on the One-way Active Measurement
Protocol [OWAMP], that will accommodate two-way or round-trip Protocol [OWAMP], that will accommodate two-way or round-trip
skipping to change at page 2, line 37 skipping to change at page 2, line 37
4.6 Stop-Sessions.............................................6 4.6 Stop-Sessions.............................................6
4.7 Fetch-Session.............................................6 4.7 Fetch-Session.............................................6
5. TWAMP Test....................................................7 5. TWAMP Test....................................................7
5.1 Sender Behavior...........................................7 5.1 Sender Behavior...........................................7
5.2 Reflector Behavior........................................8 5.2 Reflector Behavior........................................8
6. Implementers Guide...........................................12 6. Implementers Guide...........................................12
6.1 Complete TWAMP...........................................12 6.1 Complete TWAMP...........................................12
6.2 TWAMP Light..............................................12 6.2 TWAMP Light..............................................12
7. Security Considerations......................................13 7. Security Considerations......................................13
8. IANA Considerations..........................................13 8. IANA Considerations..........................................13
9. References...................................................13 9. References.................................................1413
9.1 Normative References.....................................14 9.1 Normative References.....................................14
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has proposed The IETF IP Performance Metrics (IPPM) working group has proposed
the draft standard for round-trip delay [RFC2681] metric. IPPM has the draft standard for round-trip delay [RFC2681] metric. IPPM has
also proposed a new protocol for establishment of sessions for also proposed a new protocol for establishment of sessions for
measurement of one-way metrics [OWAMP]. Two-way Active Measurement measurement of one-way metrics [OWAMP]. Two-way Active Measurement
Protocol uses the methodology and architecture of OWAMP [OWAMP] to Protocol uses the methodology and architecture of OWAMP [OWAMP] to
define an open protocol for measurement of two-way or round-trip define an open protocol for measurement of two-way or round-trip
skipping to change at page 11, line 29 skipping to change at page 11, line 29
Sender Sequence Number is the Sequence Number of the packet Sender Sequence Number is the Sequence Number of the packet
transmitted by the Session-Sender that corresponds to this test transmitted by the Session-Sender that corresponds to this test
packet. packet.
Similar to OWAMP [OWAMP] the TWAMP packet layout is the same in Similar to OWAMP [OWAMP] 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-Receiver packet follow the same rules of Session-Sender
packets as defined in OWAMP [OWAMP]. packets as defined in OWAMP [OWAMP].
The minimum data segment length is, therefore, 36 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.
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
skipping to change at page 13, line 20 skipping to change at page 13, line 20
| 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-Receiver behavior of TWAMP as
described in section 5.2.1. The controller receives the reflected described in section 5.2.1 with the following exceptions. The
test packets and collects two-way metrics. This architecture allows Session-Reflector SHOULD copy the sequence number of the received
for collection of two-way metrics. packet to the Sequence Number field of the reflected packet. This
is necessary since in case of TWAMP Light the Session-Reflector
does not have knowledge of the session state. The controller
receives the reflected test packets and collects two-way metrics.
This architecture allows for collection of two-way metrics.
This example eliminates the need for the TWAMP-Control protocol and 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.
Furthermore, the Server does not support the Fetch-Session command Furthermore, the Server does not support the Fetch-Session command
and the responder does not collect the received packet information. and the responder does not collect the received packet information.
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 the controller while copying the necessary information and
generating sequence number and timestamp values per section 5.2.1. generating sequence number and timestamp values per section 5.2.1.
skipping to change at page 16, line 4 skipping to change at page 16, line 8
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2006).
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 8 change blocks. 
10 lines changed or deleted 15 lines changed or added

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