One document matched: draft-mark-powd-00.txt
Internet Draft L. Mark
Document: <draft-mark-powd-00.txt> G. Pohl
Expires: January 2004 T. Zseby
Fraunhofer FOKUS
K. Sugauchi
Hitachi
June 2003
Passive One-way Delay Measurement
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.
Abstract
This document describes a non-intrusive method for measuring
one-way delay of IP packets.
Table of Contents
1. Introduction.................................................2
2. Terminology..................................................2
3. General Architecture.........................................3
4. Observation Point Selection..................................5
5. Packet Capturing.............................................5
6. Timestamping.................................................5
7. Filtering/Classification.....................................5
8. Packet ID Generation.........................................6
9. OWD Calculation Process......................................7
10. Measurement Result Transfer..................................7
11. Security Considerations......................................8
11.1 Measurement Infrastructure...................................8
11.2 Exchange of Measurement Data.................................8
11.3 Sensitivity..................................................9
12. References...................................................9
13. Author's Addresses..........................................10
14. Full Copyright Statement....................................10
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 1]
Internet Draft Passive One-way Delay Measurements June 2003
1. Introduction
There exist a variety of motivations for performing passive
measurements in IP networks. Many applications require the
measurement of the Quality of Service (QoS) for the transport of
specific IP flows or traffic aggregates. Network providers and
customers are interested whether negotiated QoS values in SLAs
are met (SLA validation). Measurements also provide the basis
for usage-based accounting. Furthermore, measurement results are
an important input for traffic engineering decisions.
Special motivations for One-way delay measurements are listed in
RFC2679. The advantage of passive measurements is that these
measurements are based on existing traffic within the network.
They provide a statement about the delay of the current traffic
in the observed network section. Since no test traffic is
generated, passive measurements can only be applied in cases
where the kind of traffic we are interested in is already
present in the network. This is the case for most applications
where a statements about the actual situation in the network is
required (like SLA validation, traffic engineering).
The goodness of the results of passive QoS measurements depend
on the choice of the right observation points because the
measurement results are only valid between the observation
points.
This draft adopts the terminology of IPFIX, PSAMP and IPPM.
2. Terminology
Collecting Process
The collecting process receives records of flow or packet
information. The data is stored for later processing (by
the calculation process)
Exporting Process
The exporting processes send flow and packet records to the
collecting processes. The records are generated by the
measurement process.
IP Packet Selection Process
An IP packet selection process takes IP packets or parts of
IP packets (e.g. header) as input and extracts a subset of
these packets by applying a selection function.
Filtering
Filtering selects a subset of packets by applying
deterministic functions on parts of the packet content like
header fields or parts of the payload. A filtering process
needs to process the packet (look at packet header and/or
payload) in order to make the selection decision.
Measurement Device
A measurement device has access to at least one observation
point. It is hosting at least one measurement process and
one export process.
Metering/Measurement Process
The measurement process generates records of packet and
flow information. Packets passing the observation point are
captured, timestamped, filtered and classified. The
measurement process calculates the packet IDs.
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 2]
Internet Draft Passive One-way Delay Measurements June 2003
3. General Architecture
Passive one-way delay measurements require two measurement
processes at two observation points û at a reference and at a
monitor observation point. We consider a unidirectional flow of
packets as determined by source and destination address of its
packets. The mentioned reference observation point is closer to
the source of the packets while the monitor observation point is
closer to the destination of the flow. The two measurement
processes at reference and monitor observation point generate a
timestamp and a unique packet ID for each packet as it passes an
observation point. The information is sent to a common
collecting process. A calculation process uses the data to
calculate the one-way delay. (This structure is shown in [Figure
3-1: Passive OWD Measurement Setup].)
+-----------------+
| Calculation |
| Process |
| |
+-----------------+
^
|
+--------+--------+
| Collecting |
+------>| Process |<-----+
| | | |
| +-----------------+ |
+----------+-----------+ +----------+-----------+
| Exporting | | Exporting |
| Process | | Process |
| (1)| | (2)|
+----------+-----------+ +----------+-----------+
^ ^
.............|................................|.................
. | | .
. +----------+-----------+ +----------+-----------+ .
. | Measurement | | Measurement | .
. | Process | | Process | .
. | (1)| | (2)| .
. +----------+-----------+ +----------+-----------+ .
. |reference point |monitor point .
.............|................................|.................
| |
| Network under Observation |
===========*================================*===============>>
[Figure 3-1: Passive OWD Measurement Setup]
For each packet that is measured a timestamp and a packet ID has
to be generated, stored and transmitted to a collecting process.
Then the delay calculation takes place, based on correlating
results from the different observation points. Therefore the
amount of measurement result data that arises per second depends
on the number of measured packets n per second, the number of
bits l_t used for the representation of the timestamp and the
number of bits l_id for the packet ID.
The location of the collecting process does not need to be
necessarily physically different from the measurement process.
Instead, the collecting process could be co-located with one of
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 3]
Internet Draft Passive One-way Delay Measurements June 2003
the measurement processes in order to reduce the effort for
transmitting measurement data.
[Figure 3-2] presents a refined view of the OWD Measurement
Processes.
to Exporting Process (1) to Exporting Process (2)
^ ^
| |
.............|................................|.................
. | | .
. | id, T_ref | id, T_mon .
. | [class] | [class] .
. +----------+-----------+ +----------+-----------+ .
. | Packet ID Generation | | Packet ID Generation | .
. +----------+-----------+ +----------+-----------+ .
. ^ ^ .
. |packet,T_ref, |packet,T_mon, .
. | [class] | [class] .
. +----------+-----------+ +----------+-----------+ .
. | Classification +--+ | Classification +--+ .
. +----------+-----------+ d| +----------+-----------+ d| .
. ^ i| ^ i| .
. |packet,T_ref s| |packet,T_mon s| .
. +----------+-----------+ c| +----------+-----------+ c| .
. | Timestamping | a| | Timestamping | a| .
. +----------+-----------+ r| +----------+-----------+ r| .
. ^ d| ^ d| .
. |packet v |packet v .
. +----------+-----------+ +----------+-----------+ .
. | Packet Capturing | | Packet Capturing | .
. +----------+-----------+ +----------+-----------+ .
. ^ ^ .
.............|................................|.................
|reference point |monitor point
| |
| Network under Observation |
===========*================================*===============>>
ts1 == timestamp at reference point
ts2 == timestamp at monitor point
id == generated packet id (e.g. CRC)
class == packet class can be assigned by a classification
process
[Figure 3-2: OWD Measurement Processes]
The processes involved are packet capturing, timestamping,
filtering and classification, generation of a packet ID and
transfer of measurement data. The requirements for these
processes are examined in detail in the following subsections.
Further issues that must be dealt with are the optimal selection
of the observation points, privacy issues when capturing public
traffic, difficulties in packet event correlation when packets
are lost or duplicated, and the overall amount of measurement
data captured and transmitted for evaluation.
A problem that has to be solved when using multiple measurement
points is clock synchronization between these points. Current
solutions are based on the Network Time Protocol (NTP)
[RFC1305], the Global Positioning System (GPS), and radio
signals (e.g. DCF77). Each solution has its own drawbacks and
advantages. [RFC2679] explains time keeping related terms like
æsynchronizationÆ, æaccuracyÆ, æresolutionÆ and æskewÆ -
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 4]
Internet Draft Passive One-way Delay Measurements June 2003
furthermore, it examines errors and uncertainties caused by
imperfect synchronization and clocks.
4. Observation Point Selection
The placement of measurement processes is crucial in the sense
that the observation point determines the endpoints for the
measurement of the delay. When we aim to measure the delay
between a source and destination host the locations for the
observation points have to be as close as possible to source and
destination, respectively. Although strictly speaking we never
are able to measure a true end-to-end delay, practically we will
have a very good estimation if we obeyed an appropriate
observation point selection.
There is a second point that has a direct impact on observation
point determination. We need a priori knowledge of the physical
path that packets or flows, that we intend to examine, will
follow. Then one has to select measurement processes, which are
located at observation points along this path.
5. Packet Capturing
A certain amount of bytes needs to be captured per packet as
basis for the generation of a packet ID. The packet ID collision
probability depends on the generation function and the number of
bytes that are used as input. In [DuGr00] it is stated that for
IPv4 the first 40 Bytes starting at the IP header are
sufficient.
6. Timestamping
A timestamp can be represented as absolute time. With this, the
number of bits needed for the representation of the timestamp
depends only on the desired accuracy for the measured metric. A
possibility to reduce the number of bits l_t used for the
timestamp is to use relative timestamps. One approach is to make
an assumption on the maximum time t_max a packet needs to
traverse the network from the ingress to the egress measurement
point. With this upper limit, the timestamp needs to be non-
ambiguous only within this limit. In this case the value l_t
depends not only on the desired accuracy of the time
representation but also on the predetermined limit for the
maximum time the packet needs to traverse the network. Another
possibility is to use an absolute timestamp only for the first
packet in a given time interval [0,t_int] and use timestamps
relative to this for successive packets that arrive in the same
interval.
Further issues are that the time that is needed for the time-
stamping process can differ for subsequent packets, which can
also lead to inaccuracy [ClDG00].
7. Filtering/Classification
A filtering or classification of packets is required if only
selected packets are used for the measurement. A filter is
useful to reduce the amount of resulting measurement data and
the required processing time for the subsequent processes (like
packet ID generation). The classification can filter out packets
with specific characteristics as to choose packets from the
population of interest. These can be for example all packets
that belong to a specific flow or traffic aggregate
(characterized by a common DiffServ Codepoint) in order to
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 5]
Internet Draft Passive One-way Delay Measurements June 2003
determine the quality for specific applications or traffic
classes.
In certain cases it is important to maintain the information to
which flow or class the measured packet belongs to. For instance
if the quality for different DiffServ traffic aggregates is
measured simultaneously it is desired to keep the information
about the class together with packet ID and timestamp.
In some cases, the packet ID already contains additional
information because it has been calculated with a bijective
function on the fields of information (e.g. a lossless
compression function that compresses the IP header can be
decompressed to determine the information on source and
destination). In all other cases, the wanted information has to
be transferred to the analysis application in addition to the
packet ID.
8. Packet ID Generation
Passive measurements are based on methods where packets are
neither marked nor modified. Consequently the recognition has to
be based on fields that already exist in the packet. In order to
get the same packet ID for one packet at both measurement points
the packet ID generation should be based only on fields that are
invariant or predictable during the transport. Fields that are
highly variable between the packets (e.g. the datagram ID for
IPv4) are more suitable than fields that are nearly constant or
vary only between a few values (e.g. version field). The
generation of a packet ID should be based on fields that
- already exist in the packet (no modification of the
packet),
- are invariant or predictable during the transport (at least
on the path from the ingress to the egress second
measurement point) and
- are highly variable between the different packets.
This topic is covered in [RFC2402], in [GrDM98], [DuGr00] and
[ZsZC01].
The request for low collisions (uniqueness of the ID)
contradicts the request for a small packet ID; because the more
bits are used for representing the packet ID the lower is the
probability of collisions. The collision probability within a
traffic trace depends on
- the distribution of the bit sequences taken as input to the
packet ID generation (that means it is highly dependent on
the considered traffic mix),
- the packet ID generation function,
- the size of the packet ID l_id,
- the used Operating System (OS) (if the datagram ID is
considered)
The goal is to achieve an acceptable low probability of
collisions with a packet ID that does not exceed the available
capacity for the measurement result data transfer. As for the
timestamp, the packet ID only needs to be unique in the given
time interval [0, t_max]. This limits the number of possible
combinations to the number of packets n_max that can be observed
within this interval. For example for a 155 Mbits/s link with an
average packet size of 512 Bytes and a maximum time to traverse
the network of 10s, n_max would be 378,420 packets. This amount
of combinations can be represented by 19 bits.
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 6]
Internet Draft Passive One-way Delay Measurements June 2003
IPv4 and IPv6 packets have different packet headers. That
implies that the fields of the IP packets, which can be used for
packet ID generation differ between IPv4 and IPv6 packets.
IPv4: ip-len, ip-ID, ip-prot, srcaddr, dstaddr, X bytes payload
IPv6: payload-len, ip-prot, srcaddr, dstaddr, Y bytes payload
There are different possibilities to generate an ID from the
considered fields:
- unprocessed plain
- one-way hash function (e.g. MD5)
- checksum CRC
- compression function
Functions that map a large bit sequence (the selected fields of
the packet) to a smaller bit sequence (the packet ID) can always
increase the collision probability. Using the selected fields of
the packet without further processing means to use the
calculation basis itself instead of a derived ID. This would
lead to the minimum collision probability that ever can be
achieved with the given traffic mix. Furthermore it would reduce
the required processing power because no function has to be
performed on the selected fields. Nevertheless this method would
result in a packet ID size m that is equal to the sum of bits in
the selected fields. Especially for small packets this would
increase the rate required for the measurement report messages
up to the rate for the data flow itself.
9. OWD Calculation Process
To estimate the one-way delay of an IP packet between two
observation points Ref (reference) and Mon (monitor) the
difference of the arrival times of the packet at the two
observation points is calculated:
T_owd = T_ref û T_mon
The correlation between the two timestamps to the same IP packet
is done via the packet ID in conjunction with a time window
T_delta. If a packet represented by its specific ID is captured
at the reference point but its ID is not detected at the monitor
point within T_delta the packet is considered as lost.
Note, that the difference in time, i.e. One-way delay, for a
specific packet between two monitor points is semantically
equivalent to the singleton metric defined in [RFC2679].
The IPPM Framework [RFC2330] refers to packet properties (packet
type) as ôtype-Pö. A ôtype-Pö might subsume properties such as
protocol (UDP/TCP), size, TOS/DSCP, and so on. For passive One-
way delay measurements, types of packets that are considered
within the metric depend on the applied filter. Therefore, a
description of set filters should be provided as part of any
result.
10. Measurement Result Transfer
In order to calculate QoS parameters like delay, two timestamps
have to be compared. Measurement results (timestamps and packet
ID) from different observation points have to be collected at a
common location in order to calculate the delay value. This
collection point can be located on a separate host. It also can
be co-located with one of the measurement processes in order to
reduce the amount of data that has to be transferred over the
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 7]
Internet Draft Passive One-way Delay Measurements June 2003
network. The following possibilities to transfer the measurement
results have to be distinguished:
a) In-band: The measurement results are sent directly on the
same path as the data.
b) Out-of-band: The measurement results are sent on a separate
path.
Solution a) leads to additional load on the network under test.
That means measurement result data packets can influence and
distort the original data flow and we might end up with
disadvantages that are inherent in active measurements. The in-
band sending of packets with measurement results therefore
somehow contradicts the passive approach where no influence on
the original traffic is desired. Nevertheless, there is a
difference between sending test traffic for active measurements
and the transmission of measurement results. The amount, type
and timeframe for the sending of test traffic for active
measurements are dictated by the measurement task. In contrast
to this, the sending of measurement results can be controlled by
other means. For instance, it could be sent with a lower
priority (e.g. lower-than-best-effort class) or only at times
when the network is lightly loaded, or routed over paths that
are currently not loaded (e.g. via MPLS). Which alternative is
to be preferred depends on the policy for the evaluation of the
metric (e.g. real-time or non-real-time).
Solution b) requires a separate path to the analysis application
or collection point. This can be achieved for instance via a
second interface card and a separate measurement network that
connects all measurement points. This approach does not
influence the data traffic but requires capacity in a different
network.
In all cases, additional transfer capacity (either within the
examined or a separate network) is required. For economic
reasons even a separate reporting network would probably have a
lower capacity then the ôproduction networkö. As a result, to
save resources (storage capacity and bandwidth) the measurement
result traffic should be kept as low as possible.
11. Security Considerations
11.1 Measurement Infrastructure
We have to distinguish between two different interfaces of a
measurement device: there is one interface to control the
devices and to exchange measurement data; a second interface is
used to capture the traffic.
The access to the measurement infrastructure and the measurement
devices in particular must be secured in a manner indicated by
best known praxis in order to prevent unintended malicious use
of the measurement infrastructure.
Malicious injection of packets into the network under test
through the capture interface can be prevented by properly
utilizing network taps or optical splitters or by proper design
of the physical interface.
11.2 Exchange of Measurement Data
The exchange of measurement data is vulnerable and appropriate
actions have to be taken to hinder injection of faked
measurement data. (However, the design of a data exchange
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 8]
Internet Draft Passive One-way Delay Measurements June 2003
protocol is out of the scope of this document. Please refer to
IPFIX related documents for further details.)
11.3 Sensitivity
When only packet identifier and timestamps are stored then the
measurement data itself do not contain sensitive content as long
as the packet identifier generation process is irreversible, so
that for instance IP addresses cannot be retrieved.
12. References
[ClDG00] John Cleary, et al.: Design Principles for Accurate
passive Measurement, The First Passive and Active
Measurement Workshop PAM 2000, Hamilton, New
Zealand, April 3-4, 2000
[DuGG03] Nick Duffield, et al.: A Framework for Passive
Packet Measurement, Internet Draft <draft-ietf-
psamp-framework-02.txt>, March 2003
[DuGr00] Nick Duffield, Matthias Grossglauser: ôTrajectory
Sampling for Direct Traffic Observationö,
Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,
August 28 - September 1, 2000
[GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN,
Jed MARTENS, John G. CLEARY: Nonintrusive and
Accurate Measurement of Unidirectional Delay and
Delay Variation on the Internet, INET'98, Geneva,
Switzerland, July 21-24, 1998
[QuZC03] J. Quittek, et al.: Requirements for IP Flow
Information Export, Internet Draft <draft-ietf-
ipfix-reqs-10.txt>, June 2003
[TPBC03] T. Tseby, R. Penno, N. Brownly, B. Claise:
IPFIX Applicability, Internet Draft <draft-ietf-
ipfix-as-00.txt>, June 2003
[ZsZC01] T. Zseby, S. Zander, G. Carle: Evalutation of
building blocks for passive one-way delay
measurements, PAM2001, Amsterdam, April 23-24, 2001
[RFC2330] Paxon, V., Almes, G., Mahdavi, J.,Mathis, M.,
ôFramework for IP Performance Metricsö, RFC 2330,
May 1998
[RFC2402] Kent, S., Atkinson, R., ôIP Authentication Headerö,
RFC 2402, Nov 1998
[RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, ôA One-
way Delay Metric for IPPMö, RFC 2679, September
1999
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 9]
Internet Draft Passive One-way Delay Measurements June 2003
13. Author's Addresses
Lutz Mark
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7306
Fax: +49-30-34 53 8306
Email: mark@fokus.fraunhofer.de
Guido Pohl
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7164
Fax: +49-30-34 53 8164
Email: pohl@fokus.fraunhofer.de
Tanja Zseby
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7153
Fax: +49-30-34 53 8153
Email: zseby@fokus.fraunhofer.de
Kiminori Sugauchi
Hitachi, ltd., System Development Laboratory
1099, Ohzenji, Asao-ku, Kawasaki-shi, Kanagawa-ken,
215-0013 Japan
Phone: +81-44-959-0266
Fax: +81-44-959-0860
E-mail: sugauchi@sdl.hitachi.co.jp
14. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided
on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 10]
Internet Draft Passive One-way Delay Measurements June 2003
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Mark, Pohl, Zseby, Sugauchi Expires January 2004 [Page 11] | PAFTECH AB 2003-2026 | 2026-04-23 09:41:01 |