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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/