Network Working Group                                        S. Shalunov

Expiration Date: January April 2002                                B. Teitelbaum
                               Advanced Network & Services and Internet2
                                                           November 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-

   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

   The list of Internet-Draft shadow directories can be accessed at

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

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.  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 very accurate time
   sources--either 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
   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 ICMP-based tools like ping.  Even without very accurate
   timestamps one can measure characteristics such as, e.g., loss with
   acceptable for many practical purposes quality.

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

4. 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, average median delay, mean delay, jitter, 90th
   percentile of delay, etc.). etc.); this is achieved by keeping all the raw
   data for post-processing by the final data consumer, as specified in
   section 4.1.  Since RFC2679 and RFC2680 standardize metrics based on
   Poisson streams of test packets, sampling processes, Poisson streams at least should must be
   supported. 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 aren't areas that the protocol(s) need not be addressed.  However, they may be addressed if
   considered practical and not in contradiction to address. other design goals.

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.  (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
   available after it is finished if desired by endpoint the data consumer 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

   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 a
   protocol for conducting the actual measurement session on one side
   and a protocol for session setup/teardown/confirmation/retrieval on
   the other.  These protocols are further referred to as OWDP-Test OWAMP-Test and
   OWAMP-Control, respectively.

   It should be possible to use devices that only support OWDP-Test OWAMP-Test but
   not OWDP-Control OWAMP-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).


   OWAMP-Control would thus become a common protocol for different
   domains, which may or may not use it for session setup internally.

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

   +  Since  Allow UDP as the transport protocol, since the protocol needs to
      be able to measure individual packet delivery time times and has to run
      on various machines, it needs to
      support UDP as transport protocol. machines.

   +  It should be possible to use  Support varying packet sizes and network
      services, services (e.g., DSCP
      marking), as negotiated using OWDP-Control. by OWAMP-Control.

   +  To be a lowest common denominator, OWDP-Test  Be as simple as possible, but no simpler; the OWAMP-Test packet
      format should
      only include only universally meaningful fields, and
      minimum number of them.

   +  It should be possible to make generate OWAMP-Test packets generated by OWDP-Test as small as possible, enough,
      so that when encapsulated, each fits inside a single ATM cell.

   +  Data needed to calculate experimental errors on the final result
      should be able to accurately measure paths where
      packet-splitting technologies such as ATM are used. included in the packets.

4.5. Control Protocol

   Control protocol needs to provide abilities the capability 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 OWAMP-Test sessions (which do not have to be
      between the peers of OWDP-Control OWAMP-Control conversation);

   +  start sessions simultaneously or at a pre-scheduled per-session

   +  retrieve OWDP-Test OWAMP-Test session results (of OWDP-Test OWAMP-Test sessions
      scheduled in the current and other OWDP-Control OWAMP-Control sessions);

   +  confirm graceful completion of session or sessions and allow either side to
      abort them prematurely
      (for both sides). a session prematurely.

   The OWDP-Control OWAMP-Control design should not preclude the ability to record
   extended periods of losses.  It should always provide peers with the
   ability to always distinguish between network and peer failures.

5. Scalability


4.6. Support for Measurements with Different Packet Types

   Since the notion of a packet of type P from [RFC2330], section 13
   doesn't always imply precise definition of packet type, some
   decisions narrowing the scope of possible packet types need to be
   made at measurement architecture designs have inherent scalability
   problems (e.g., a full mesh protocol design stage.  Further, measurement with
   packets of always-on certain types, while feasible in more closed settings than
   those implied by OWAMP, become very hard to perform in an open inter-
   domain fashion (e.g., measurements among N with particular packets with
   broken IP checksum or particular loose source routing options).

   In addition, very general packet type specification could result in
   several problems:

   +  Many OWAMP-Test speakers will be Unix or other general purpose
      computers.  These will inevitably have higher losses when
      listening to raw network traffic.  Raw sockets will induce higher
      loss rate than one would have with UDP measurements.

   +  It's not at all clear (short of standardizing tcpdump syntax) how
      to describe formally the filter that a receiver should use to
      listen for test traffic.

   +  Suppose an identity of an authenticated user becomes compromised.
      Now the attacker could use that to run TCP sessions to the rlogin
      port of machines around servers that trust this user to perform
      measurements (or, less drastically, to send spam from that
      network).  The ability to perform measurements is transformed into
      an ability to generate arbitrary traffic on behalf of all the
      senders an OWAMP-Control server controls.

   +  Carefully crafted packets could cause disruption to some link-
      layer protocols.  Implementors can't know what to disallow
      (scrambling is different for different link-layer technologies).

   It appears that allowing one to ask a measurement server to generate
   arbitrary packets becomes an unmanageable security hole and a
   formidable specification and implementation hurdle.

   For these reasons, we only require OWAMP to support a small subspace
   of the whole packet type space.  Namely, it should be possible to
   conduct measurements with a given Differentiated Services Codepoint
   (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB
   ID) [RFC2836].

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 OWAMP 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

   design other architectures that are free of scalability deficiencies.

   It is the protocol user's responsibility to decide how to use the
   protocol and which measurements to conduct.

6. Security Considerations

6.1. 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.

   It should be possible to operate in a completely "open" mode, where
   no security mechanisms are used.  We call this "unauthenticated

   It should also be possible to operate in a mode where all security
   mechanisms are enabled and security objectives are realized to the
   fullest extent possible.  We call this "encrypted mode".

   Since timestamp encryption takes a certain amount of time, which may
   be hard to predict on some devices (with a time-sharing OS), a mode
   should be provided that is similar to encrypted mode, but in which
   timestamps are not encrypted.  In this mode, all security properties
   of the encrypted mode that can be retained without timestamp
   encryption should be present.

   To make implementation more manageable, the number of other options
   and modes should be kept to the absolute practical minimum.  Where
   choosing a single mechanism for achieving anything related to
   security is possible, such choice should be made at specification
   phase and be put into the standard.

6.2. Being Hard to Detect Interfere with by Applying Special Treatment to
   Measurement Packets

   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


6.3. Secrecy/Confidentiality

   It should be possible to make it infeasible for any outside party
   without knowledge of the shared secret being used to learn what
   information is exchanged using OWDP-Control OWAMP-Control by inspecting OWDP- an OWAMP-
   Control stream or by actively modifying it.

   (It is recognized that some information will inevitably leak from the
   mere fact of communication and from the presence and timing of
   concurrent and subsequent OWDP-Test OWAMP-Test traffic.)


6.4. 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

   It should also be infeasible for such party to use any information
   obtained by observing, modifying or initiating protocol transactions
   to impersonate (other) valid users.


6.5. Integrity


   So that it is possible to detect any interference during a
   conversation (other than the detention of some messages), facility
   must be provided to authenticate each message of the control protocol and
   their exact sequence and
   protocol, its attribution to a given session has to be
   provided, so that any interference during a conversation (other than
   detention session, and its exact placement
   in the sequence of some messages) can control protocol exchanges.

   It must also be detected.

   Facility possible to authenticate each message of the test
   protocol and its attribution to a specific session has to be provided, session, so that
   modifications of OWDP-Test OWAMP-Test messages can be detected.

   Facility  It must be
   possible to do the latter this in such a way fashion that does not require timestamps
   aren't encrypted and to be encrypted; in this case, security properties are only
   valid for only when 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
   OWAMP-Test sender 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. receiver.

7. IANA Considerations

   Relevant IANA considerations will be placed into the protocol
   specification document itself, and not into the requirements

8. References

   [BRIX] Brix 1000 Verifier,

   [CQOS] CQOS Home Page,

   [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for
        IP Performance Metrics", RFC 2330, May 1998.

   [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.

   [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.

   [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior
        Identification Codes", RFC 2836, May 2000.

   [RIPE] RIPE NCC Test-Traffic Measurements home,

   [SURVEYOR] Surveyor Home Page,

9. Authors' Addresses

   Stanislav Shalunov
   200 Business Park Drive Drive, Suite 307
   Armonk, NY  10504

   Phone: +1 914 765 1182

   Benjamin Teitelbaum
   Advanced Network & Services
   200 Business Park Drive Drive, Suite 307
   Armonk, NY 10504

   Phone: +1 914 765 1118

   Expiration date: January April 2002