Network Working Group                                        S. Shalunov Request for Comments: 4656                                B. Teitelbaum Category: Standards Track                                        A. Karp                                                                J. Boote                                                            M. Zekauskas                                                                Internet2                                                          September 2006            A One-way Active Measurement Protocol (OWAMP)
Status of This Memo
This document specifies an Internet standards track protocol for the    Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The One-Way Active Measurement Protocol (OWAMP) measures
unidirectional characteristics such as one-way delay and one-way
loss.  High-precision measurement of these one-way IP performance
metrics became possible with wider availability of good time sources    (such as GPS and CDMA).  OWAMP enables the interoperability of these    measurements.
Table of Contents
1. Introduction (2)
1.1. Relationship of Test and Control Protocols (3)
1.2. Logical Model (4)
2. Protocol Overview (5)
3. OWAMP-Control (6)
3.1. Connection Setup (6)
3.2. Integrity Protection (HMAC) (11)
3.3. Values of the Accept Field (11)
3.4. OWAMP-Control Commands (12)
3.5. Creating Test Sessions (13)
3.6. Send Schedules (18)
3.7. Starting Test Sessions (19)
3.8. Stop-Sessions (20)
3.9. Fetch-Session (24)
Shalunov, et al.            Standards Track                    [Page 1]
4. OWAMP-Test (27)
4.1. Sender Behavior (28)
4.1.1. Packet Timings (28)
4.1.2. OWAMP-Test Packet Format and Content (29)
4.2. Receiver Behavior (33)
5. Computing Exponentially Distributed Pseudo-Random Numbers (35)
5.1. High-Level Description of the Algorithm (35)
5.2. Data Types, Representation, and Arithmetic (36)
5.3. Uniform Random Quantities (37)
6. Security Considerations (38)
6.1. Introduction (38)
6.2. Preventing Third-Party Denial of Service (38)
6.3. Covert Information Channels (39)
6.4. Requirement to Include AES in Implementations (39)
6.5. Resource Use Limitations (39)
6.6. Use of Cryptographic Primitives in OWAMP (40)
6.7. Cryptographic Primitive Replacement (42)
6.8. Long-term Manually Managed Keys (43)
6.9. (Not) Using Time as Salt (44)
6.10. The Use of AES-CBC and HMAC (44)
7. Acknowledgements (45)
8. IANA Considerations (45)
9. Internationalization Considerations (46)
10. References (46)
10.1. Normative References (46)session下载
10.2. Informative References (47)
Appendix A: Sample C Code for Exponential Deviates (49)
Appendix B: Test Vectors for Exponential Deviates (54)
1.  Introduction
The IETF IP Performance Metrics (IPPM) working group has defined
metrics for one-way packet delay [RFC2679] and loss [RFC2680] across    Internet paths.  Although there are now several measurement platforms    that implement collection of these metrics [SURVEYOR] [SURVEYOR-INET]  [RIPE] [BRIX], there is not currently a standard that would permit
initiation of test streams or exchange of packets to collect
singleton metrics in an interoperable manner.
With the increasingly wide availability of affordable global
positioning systems (GPS) and CDMA-based time sources, hosts
increasingly have available to them very accurate time sources,
either directly or through their proximity to Network Time Protocol
(NTP) primary (stratum 1) time servers.  By standardizing a technique    for collecting IPPM one-way active measurements, we hope to create an    environment where IPPM 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 OWAMP servers Shalunov, et al.            Standards Track                    [Page 2]
that would make measurement of one-way delay as commonplace as
measurement of round-trip time using an ICMP-based tool like ping.
Additional design goals of OWAMP include: being hard to detect and
manipulate, security, logical separation of control and test
functionality, and support for small test packets.  (Being hard to
detect makes interference with measurements more difficult for
intermediaries in the middle of the network.)
OWAMP test traffic is hard to detect because it is simply a stream of    UDP packets from and to negotiated port numbers, with potentially
nothing static in the packets (size is negotiated, as well).  OWAMP
also supports an encrypted mode that further obscures the traffic and    makes it impossible to alter timestamps undetectably.
Security features include optional authentication and/or encryption
of control and test messages.  These features may be useful to
prevent unauthorized access to results or man-in-the-middle attacks
that attempt to provide special treatment to OWAMP test streams or
that attempt to modify sender-generated timestamps to falsify test
results.
In this document, the key words "MUST", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" are to be interpreted as described in
[RFC2119].
1.1.  Relationship of Test and Control Protocols
OWAMP actually consists of two inter-related protocols: OWAMP-Control    and OWAMP-Test.  OWAMP-Control is used to initiate, start, and stop
test sessions and to fetch their results, whereas OWAMP-Test is used    to exchange test packets between two measurement nodes.
Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, the authors have deliberately
chosen to include both protocols in the same RFC to encourage the
implementation and deployment of OWAMP-Control as a common
denominator control protocol for one-way active measurements.  Having    a complete and open one-way active measurement solution that is
simple to implement and deploy is crucial to ensuring a future in
which inter-domain one-way active measurement could become as
commonplace as ping.  We neither anticipate nor recommend that
OWAMP-Control form the foundation of a general-purpose extensible
measurement and monitoring control protocol.
OWAMP-Control is designed to support the negotiation of one-way
active measurement sessions and results retrieval in a
straightforward manner.  At session initiation, there is a
Shalunov, et al.            Standards Track                    [Page 3]
negotiation of sender and receiver addresses and port numbers,
session start time, session length, test packet size, the mean
Poisson sampling interval for the test stream, and some attributes of    the very general [RFC 2330] notion of packet type, including packet
size and per-hop behavior (PHB) [RFC2474], which could be used to
support the measurement of one-way network characteristics across
differentiated services networks.  Additionally, OWAMP-Control
supports per-session encryption and authentication for both test and    control traffic, measurement servers that can act as proxies for test    stream endpoints, and the exchange of a seed value for the pseudo-
random Poisson process that describes the test stream generated by
the sender.
We believe that OWAMP-Control can effectively support one-way active    measurement in a variety of environments, from publicly accessible
measurement beacons running on arbitrary hosts to network monitoring    deployments within private corporate networks.  If integration with
Simple Network Management Protocol (SNMP) or proprietary network
management protocols is required, gateways may be created.
1.2.  Logical Model
Several roles are logically separated to allow for broad flexibility    in use.  Specifically, we define the following:
Session-Sender      The sending endpoint of an OWAMP-Test session;
Session-Receiver    The receiving endpoint of an OWAMP-Test session;  Server              An end syste
m that manages one or more OWAMP-Test                        sessions, is capable of configuring per-session
state in session endpoints, and is capable of
returning the results of a test session;
Control-Client      An end system that initiates requests for
OWAMP-Test sessions, triggers the start of a set                        of sessions, and may trigger their termination;
and
Fetch-Client        An end system that initiates requests to fetch
the results of completed OWAMP-Test sessions. Shalunov, et al.            Standards Track                    [Page 4]
One possible scenario of relationships between these roles is shown
below.
+----------------+              +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+              +------------------+
^                                    ^
|                                    |
|                                    |
|                                    |
|  +----------------+<----------------+
|  |    Server    |<-------+
|  +----------------+        |
|    ^                      |
|    |                      |
| OWAMP-Control        OWAMP-Control
|    |                      |
v    v                      v
+----------------+    +-----------------+
| Control-Client |    |  Fetch-Client  |
+----------------+    +-----------------+
(Unlabeled links in the figure are unspecified by this document and
may be proprietary protocols.)
Different logical roles can be played by the same host.  For example,  in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Fetch-Client, and Session-
Sender, and the other playing the roles of Server and Session-
Receiver.  This is shown below.
+-----------------+                  +------------------+
| Control-Client  |<--OWAMP-Control-->| Server          |
| Fetch-Client    |                  |                  |
| Session-Sender  |---OWAMP-Test----->| Session-Receiver |
+-----------------+                  +------------------+
Finally, because many Internet paths include segments that transport    IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR).  Consequently, OWAMP has been    designed to allow for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in
unauthenticated mode).
Shalunov, et al.            Standards Track                    [Page 5]

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。