Network Working Group S. Shalunov
Internet Draft Internet2
Expiration Date: January 2002 B. Teitelbaum
Advanced Network & Services and Internet2
July 2001
A One-way Active Measurement Protocol Requirements
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
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
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Abstract
With growing availability of good time sources to network nodes, it
becomes increasingly possible to measure one-way IP performance
metrics with high precision. To do so in an interoperable manner, a
common protocol for such measurements is required. This document
specifies requirements for a one-way active measurement protocol
(OWAMP) standard. The protocol can measure one-way delay, as well as
unidirectional characteristics such as one-way loss and others.
Shalunov and Teitelbaum [Page 1]
INTERNET-DRAFT One-way Delay Protocol Requirements July 2001
3. Motivations and Goals
The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC 2680] across Internet paths. Although there are now several
measurement platforms that implement the collection of these metrics
([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a
standard for interoperability.
With the increasingly wide availability of affordable global
positioning system (GPS) and CDMA based time sources, hosts
increasingly have available to them very accurate time
sources--either directly or through their proximity to NTP primary
(stratum 1) time servers. By standardizing a technique for
collecting IPPM one-way active measurements, we hope to create an
environment where these metrics may be collected across a far broader
mesh of Internet paths than is currently possible. One particularly
compelling vision is of widespread deployment of open one-way active
measurement beacons that would make measurements of one-way delay as
commonplace as measurements of round-trip time are today using ICMP-
based tools like ping.
To support interoperability between alternative OWDP implementations
and make possible a world where "one-way ping" could become
commonplace, a standard is required that specifies how test streams
are initiated, how test packets are exchanged, and how test results
are retrieved. Detailed functional requirements are given in the
subsequent section.
4. Functional Requirements
The protocol(s) should provide ability to measure, record, and
distribute the results of measurements of one-way singleton network
characteristics such as characteristics defined in [RFC2679] and
[RFC2680].
It should be possible to measure arbitrary one-way singleton
characteristics (e.g., loss, average delay, mean delay, jitter, 90th
percentile of delay, etc.). Since RFC2679 and RFC2680 standardize on
Poisson streams of test packets, Poisson streams at least should be
supported.
Non-singleton characteristics (such as those related to trains of
packets, back-to-back tuples, and so forth) and application traffic
simulation aren't areas that the protocol(s) need to address.
Shalunov and Teitelbaum [Page 2]
INTERNET-DRAFT One-way Delay Protocol Requirements July 2001
4.1. Keeping All Data for Post-processing
To facilitate the broadest possible use of obtained measurement
results, the protocol(s) should not necessitate any required post-
processing. All data obtained during a measurement session should be
available after it is finished if desired by endpoint so that various
characteristics can be computed from the raw data using arbitrary
algorithms.
4.2. Result Distribution
A means to distribute measurement results (between hosts
participating in a measurement session and beyond) should be
provided. Since there can exist a wide variety of scenarios as to
where the final data destination should be, these should be invoked
separately from measurement requests (e.g., receiver should not have
to automatically send measurement results to the sender, since it may
be the receiver or a third host that are the ultimate data
destination).
At the same time, ability to transfer results directly to their
destination (without need for potentially large intermediate
transfers) should be provided.
4.3. Protocol Separation
Since measurement session setup and the actual measurement session
(i) are different tasks; (ii) require different levels of
functionality, flexibility, and implementation effort; (iii) may need
to run over different transport protocols, there should exist
different protocols for conducting the actual measurement session on
one side and for session setup/teardown/confirmation/retrieval on the
other. These protocols are further referred to as OWDP-Test and
OWDP-Control, respectively.
It should be possible to use devices that only support OWDP-Test but
not OWDP-Control to conduct measurement sessions (such devices will
necessarily need to support one form of session setup protocol or the
other, but it doesn't have to be known to external parties).
OWDP-Control would thus become a common protocol for different
domains, which may or may not use it for session setup internally.
Shalunov and Teitelbaum [Page 3]
INTERNET-DRAFT One-way Delay Protocol Requirements July 2001
4.4. Test Protocol
The test protocol needs to be implemented on all measurement nodes
and should therefore have the following characteristics:
+ Be lightweight and easy to implement.
+ Be suitable for implementation on a wide range of measurement
nodes.
+ Since the protocol needs to be able to measure individual packet
delivery time and has to run on various machines, it needs to
support UDP as transport protocol.
+ It should be possible to use varying packet sizes and network
services, as negotiated using OWDP-Control.
+ To be a lowest common denominator, OWDP-Test packet format should
only include universally meaningful fields, and minimum number of
them.
+ It should be possible to make packets generated by OWDP-Test as
small as possible, to be able to accurately measure paths where
packet-splitting technologies such as ATM are used.
4.5. Control Protocol
Control protocol needs to provide abilities to:
+ authenticate peers to each other using a common authentication
method that doesn't require building any new authentication
infrastructure, such as user ID and a shared secret;
+ schedule zero or more OWDP-Test sessions (which do not have to be
between the peers of OWDP-Control conversation);
+ start sessions simultaneously or at a pre-scheduled per-session
times;
+ retrieve OWDP-Test session results (of OWDP-Test sessions
scheduled in the current and other OWDP-Control sessions);
+ confirm graceful completion of session or abort them prematurely
(for both sides).
Shalunov and Teitelbaum [Page 4]
INTERNET-DRAFT One-way Delay Protocol Requirements July 2001
The OWDP-Control design should not preclude the ability to record
extended periods of losses. It should provide peers with the ability
to always distinguish between network and peer failures.
5. Scalability
While some measurement architecture designs have inherent scalability
problems (e.g., a full mesh of always-on measurements among N
measurement nodes requires O(N^2) total resources, such as storage
space and link capacity), OWDP itself should not exaggerate the
problem or make it impossible (where it is in principle possible) to
design other architectures that are free of scalability deficiencies.
6. Security Considerations
6.1. Being Hard to Detect
The design of the protocol should make it possible to run sessions
that would make it very difficult for any intermediate party to make
results appear better than they would be if no interference was
attempted.
6.2. Secrecy/Confidentiality
It should be possible to make it infeasible for any outside party
without knowledge of shared secret being used to learn what
information is exchanged using OWDP-Control by inspecting OWDP-
Control stream or by actively modifying it.
(It is recognized that some information will inevitably leak from the
mere fact of communication and from presence and timing of concurrent
and subsequent OWDP-Test traffic.)
6.3. Authentication
It should be possible to authenticate peers to each other using a
user ID and a shared secret. It should be infeasible for any
external party without knowledge of the shared secret to obtain any
information about it by observing, initiating, or modifying protocol
transactions.
It should also be infeasible for such party to use any information
obtained by observing, modifying or initiating protocol transactions
Shalunov and Teitelbaum [Page 5]
INTERNET-DRAFT One-way Delay Protocol Requirements July 2001
to impersonate (other) valid users.
6.4. Integrity
Facility to authenticate each message of the control protocol and
their exact sequence and attribution to a given session has to be
provided, so that any interference during a conversation (other than
detention of some messages) can be detected.
Facility to authenticate each message of the test protocol and its
attribution to a specific session has to be provided, so that
modifications of OWDP-Test messages can be detected.
Facility to do the latter in such a way that timestamps themselves
aren't encrypted and security properties are only valid for an
attacker that cannot observe valid traffic between OWDP-Test sender
and receiver has to be provided.
6.5. Modes of Operation
Since the protocol(s) will be used in widely varying circumstances
using widely varying equipment, it is necessary to have more than one
mode of operation security-wise.
A mode that is completely "open" (an unauthenticated mode) should be
provided, where no security mechanisms are used.
A mode where all security mechanisms are enabled and security
objectives are realized to fullest extent possible (an encrypted
mode) should be provided.
Since timestamp encryption takes certain time, which may be hard to
predict on some devices (with a time-sharing OS), a mode similar to
encrypted mode, but where timestamps aren't encrypted, should be
provided. In said mode, all security properties of encrypted mode
that can be retained without timestamp encryption should be present.
7. IANA Considerations
Relevant IANA considerations will be placed into the protocol
specification document itself, and not into the requirements
document.
Shalunov and Teitelbaum [Page 6]
INTERNET-DRAFT One-way Delay Protocol Requirements July 2001
8. References
[BRIX] Brix 1000 Verifier,
http://www.brixnet.com/products/brix1000.html
[CQOS] CQOS Home Page, http://www.cqos.com/
[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
9. Authors' Addresses
Stanislav Shalunov
Internet2
200 Business Park Drive
Armonk, NY 10504
USA
Phone: +1 914 765 1182
EMail: shalunov@internet2.edu
Benjamin Teitelbaum
Advanced Network & Services
200 Business Park Drive
Armonk, NY 10504
USA
Phone: +1 914 765 1118
EMail: ben@advanced.org
Expiration date: January 2002
Shalunov and Teitelbaum [Page 7]
