One-way Active Measurement Protocol (OWAMP) Requirements
RFC 3763

Document Type RFC - Informational (April 2004; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3763 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
Send notices to <>, <>
Network Working Group                                        S. Shalunov
Request for Comments: 3763                                 B. Teitelbaum
Category: Informational                                        Internet2
                                                              April 2004

        One-way Active Measurement Protocol (OWAMP) Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   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
   other unidirectional characteristics, such as one-way loss.

1.  Motivations and Goals

   The IETF IP Performance Metrics (IPPM) working group has proposed
   standards track 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.  This requirements document is aimed
   at defining a protocol that allows users to do measurements using
   devices from different vendors at both ends and get meaningful

   With the increasingly wide availability of affordable global
   positioning system (GPS) and CDMA based time sources, hosts
   increasingly have available to them time sources that allow hosts to
   time-stamp packets with accuracies substantially better than the
   delays seen on the Internet--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

Shalunov & Teitelbaum        Informational                      [Page 1]
RFC 3763                   OWAMP Requirements                 April 2004

   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.  Even without very accurate
   timestamps one can measure characteristics such as loss with quality
   acceptable for many practical purposes, e.g., network operations.

   To support interoperability between alternative OWAMP 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.

2.  Functional Requirements

   The protocol(s) should provide the ability to measure, record, and
   distribute the results of measurements of one-way singleton network
   characteristics such as characteristics defined in [RFC2679] and
   [RFC2680].  Result reporting, sampling, and time stamps are to be
   within the framework of [RFC2330].

   It should be possible to measure arbitrary one-way singleton
   characteristics (e.g., loss, median delay, mean delay, jitter, 90th
   percentile of delay, etc.); this is achieved by keeping all the raw
   data for post-processing by the final data consumer, as specified in
   section 2.1.  Since RFC2679 and RFC2680 standardize metrics based on
   Poisson sampling processes, Poisson streams must be supported by the

   Non-singleton characteristics (such as those related to trains of
   packets, back-to-back tuples, and so forth) and application traffic
   simulation need not be addressed.  However, they may be addressed if
   considered practical and not in contradiction to other design goals.

2.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.  (This does not apply to implementation details such as
   converting timestamps from ticks since midnight into a canonical form
   or applying calibration constants; such details should naturally be
   hidden.)  All data obtained during a measurement session should be
Show full document text