September 1998
IP Measurement Protocol (IPMP)
1. Status of this memo
Replaced by new version This version is
for reference only.
2. Introduction
The practice and need for active network measurement is well
established however current tools are not well suited to this
task, mostly because the protocols which they employ have not
been designed for measurement of the modern Internet.
ICMP, for example, is widely used for measurement despite its
well known limitations for this task. These limitations include
it being treated different to other IP protocols at routers and
hosts. ICMP has also received bad press from denial of service
attacks and because of the number of sites generating monitoring
traffic. As a consequence some ISPs disable ICMP even though
this potentially causes poor performance and does not comply
with RFC1009 [1].
In an attempt to avoid these restrictions there is a risk of
network measurement teams sending traffic in other protocols,
such a TCP or UDP despite their unsuitability for this purpose.
Such measurement traffic has the potential to disrupt the normal
operation of the network and the router or host to which it is
sent.
IPMP addresses these issues by providing a measurement protocol
that is tightly constrained, efficient and easy to implement.
The protocol has been designed so measurement packets can be
processed with about the same level of computation as IP packet
forwarding.
The protocol operates as an echo protocol allowing packet loss,
path length, RTT and in some cases, one-way delay measurements
to be taken. Packets are generated by a measurement host and
returned by an echoing router or host, known as an echoing
system in this memo. The translation of router time stamps to
real time time stamps is support through a separate information
request and reply exchange between the measurement system and
systems that insert time stamps into the echo request or reply.
2.1 Packet formats
2.1.1 IPMP Echo Request and Echo Reply
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Queue type | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 00000000 | Type | Returned TTL | Return Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Path Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Data |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Path Record(s) |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (if required) |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path Record format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version = 0.
Type = 1, echo request
0, echo reply
Return type = 0 echo request
any value in the echo reply
Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the IPMP message starting with the version
number. For computing the checksum, the checksum and returned
checksum fields are zero.
Length
The total length, in bytes, of the IPMP packet. The length
should not normally exceed 556 bytes. That is the data field
plus the space allocated for path records should not exceed 544
bytes. Longer packets risk being discarded if they need to be
forwarded over a path with an MTU less that 576. Within these
limits a maximum of 45 path records may be included in the
packet, allowing 4 bytes for a unique identifier in the data
field.
Queue type
The queue type specifies how the echoing system and the
intermediate routers schedule this packet if they implement a
packet scheduling discipline that is not FIFO.
If a non FIFO discipline is used the IPMP packet must be
scheduled as if it were a packet from the IP protocol specified
in Queue Type. For example a Queue Type of 6 means schedule this
packet as if it was a TCP packet.
Returned TTL 0 in the echo request. Either 0 or the value of the
IP header TTL field when the packet was received by the echoing
system.
Path Pointer
The position, in bytes from the beginning of the IPMP packet, of
the next available path record location. If there are no
path pointer fields available this field is set to length.
Data
The data field is set by the measurement host. The echo reply
contains an identical data field to the echo request. The
content of the data field must allow the echo reply to be
matched with the echo request when it arrives at the measurement
host.
Forwarding IP Address
The address of interface at which the packet was received by the
system that inserted the Path Record into the Echo Request or
Echo Reply packet.
Timestamp
The time at which the interface received the packet recorded as
an RFC1305 NTP format [2] timestamp. The relationship between
this timestamp and real time, if there is one, must be derived
using information from an IPMP Information Reply (see section
4.3). If the timestamp is not included its value is 0.
If a timestamp is included by a system the system must be able
to processes IPMP Information Request Packets at the address
included in the Path Record.
2.1.1 IPMP Information Request and Information Reply
2.1.1.1 Request
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | 00000000 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 00000000 | Type | 00000000 | 00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1.2 Reply
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | 00000000 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 00000000 | Type | 00000000 | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Performance Data Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accuracy |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPMP Processing Overhead |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Real Time Reference Points |
| |
| |
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Performance Data |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Real Time Reference Point
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Real Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reported Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version = 0.
Type = 32, Information Request
33, Information Reply
Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the IPMP message starting with the version
number. For computing the checksum, the checksum and returned
checksum fields are zero.
Precision
The number of bits in the fractional part of timestamps that are
valid.
Length
The total length, in bytes, of the IPMP packet. The length
should not normally exceed 556 bytes. That is the Real Time
Reference Points and Performance Data fields should not exceed
524 bytes. Longer packets risk being discarded if they need to
be forwarded of a path with a MTU less that 576. If no
performance data is included 32 Real Time Reference Points may be
included in the packet.
Performance Data Pointer
The position, in bytes from the beginning of the IPMP packet, of
the performance data field if it exists. If there is no
performance data this field is 0.
Forwarding IP Address
The address of the interface to which the Information Request was
sent.
Accuracy
The maximum difference between actual real time and and the
inferred real time (see section 4.3.2) of any timestamp
generated by this interface. If there is no relationship
between real time and the timestamps recorded by the interface
or the extent of the difference from real time is unknown
accuracy is set to 0.
IPMP Processing Overhead
The maximum difference between the time taken to process and
forward an IPMP packet and the time taken to forward an IP
packet with the same characteristics. If the overhead is unknown
this is reported as MAX_TIME, i.e. all bits to 1.
Real Time Reference Point
A real time reference point gives the relationship between real
time and the timestamp that would have been placed in a Path
Record by the interface at that time. If there is no
relationship between real time and timestamps no reference
points are included in the Information Reply. If any reference
points are included there must be at least two. Within the
bounds of the overall size of the packet any number of reference
points may be included.
Performance Data
The Performance Data field allows arbitrary information from the
MIB of the system or the interface to optionally be included in
the Information Reply. It is formated as a VarBindList from the
SNMPv2-PDU defined in [4]. In this context ObjectSyntax is the
only valid choice within VarBind.
I.E.
IPMP-PERFORMANCE-DATA DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax,
FROM SNMPv2-SMI;
-- IPMP simplified list element
IPMPVarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
-- variable-binding list
VarBindList ::=
SEQUENCE (SIZE (0..max-bindings)) OF
IPMPVarBind
END
2.2 IP Protocol Header Values
Version = 4
IHL = 5
Identification = 0
Flags = DF
Fragment offset = 0
IP Protocol type = TO BE ASSIGNED.
IP options are forbidden.
3 Processing of IPMP packets
3.1 Measurement host processing
A measurement host constructs an IPMP request, encapsulates it
in an IP datagram and the appropriate link layer protocol and
sends it into the network. Performance information is gleaned
from the presence or absence of a reply, the delay between the
request and the reply the value of TTL and the path record(s) if
present and possibly the presence of errors.
The measurement host, when constructing the echo request, sets
all words from the end of the data field to the end of the echo
request (the space allocated for path records) to zero.
The data field must contain information that allows the
measurement host to match echo replies to echo requests. The
data field might also contain checking information for part or
all of the data and/or control fields of the IPMP packet. This
checking information may allow matching of echo requests and
replies where there are errors in other parts of the IPMP packet
and the determination of the BER of the path.
When an IPMP echo reply arrives the checksum is recomputed.
Unless further protection is provided in the data field an IPMP
echo reply with an incorrect checksum should be discarded
because of the risk of data corruption causing incorrect
matching with the echo request.
3.2 Echoing system processing
The IPMP Echo Request and Echo Reply packet formats have been
designed to make processing at the echoing host simple and
efficient.
On receipt of the IPMP Echo Request the echoing system
constructs the echo reply from the echo request by:
1. exchanging the IP source and destination addresses
2. exchanging the third and fourth 16-bit words of the IPMP
packet or otherwise setting the type field (see section 4.1)
3. optionally inserting a path record (as described in
section 3.3.1).
4. scheduling the packet for forwarding taking account of the
queue type field if appropriate.
The echoing system does not:
o calculate or check the IPMP checksum
o decrement or otherwise alter TTL or recalculate the IP checksum
o process fragments or IP options
Processing IPMP Information Request packets requires more
resources than an Echo Request. Direct measurements are not
made from Information Request packets. Consequently an
implementor may choose to processes Information Request packets
off the interface card and/or at low priority.
3.3 Forwarding System Processing
A forwarding router does not need to be IPMP aware. In the
simplest case IPMP is forwarded like any other IP protocol.
If the router forwards schedules packets based (perhaps in part)
on the value of the IP protocol field, from the IP header, then
the forwarding router must use the queue type field of the IPMP
field for scheduling instead of the IP protocol field.
A forwarding router may include a path record as described
below.
3.3.1 Path Record
Inclusion of path records is optional. A path record MAY be
inserted by forwarding routers (on the forward or reverse path)
and the echoing system.
A system which adds a path record must increase the Path Pointer
by 12 and must also update the Checksum field. The length of
the packet is not changed. Before updating the Path Pointer it
must be compared with length to ensure that sufficient space is
available for the new path record.
A system that adds a path record may include a timestamp in the
path record using the timestamp NTP format described in section
4.3. If it does not include a timestamp the timestamp field in the
path record is left unaltered.
3.4 Denial of service attacks
Because IPMP echo request packets are processed with about the
same effort as forwarding an IP packet they do not introduce any
new denial of service opportunities.
IPMP Information Request packets require more processing and may
be used as the basis of a denial of service attack in the same
way as any information request on a router or host. Because
Information Request packets are not used to make measurements an
implementor may implement protection against denial of service
attacks made with these packets in the same way as other
information requests. This might involve processing IPMP
Information Requests at a low priority or regulating the
maximum flow of packets.
4 Discussion
4.1 Echoing system update of the type field.
The echoing system might set the type field in the IPMP field
(see step 2 in section 3.2) in any one of a number of ways. An
implementor should use the most efficient for the architecture in
use. These methods include:
o swapping the third and fourth 16-bit words
o swapping the sixth and eighth bytes
o writing a 0 to the sixth byte and a 1 to the eighth byte
o writing a 0 to the third 16-bit word and a 1 to the fourth 16
bit word
o writing a 0 to the sixth byte or third 16-bit word
4.2 Checksums
The IPMP checksum is calculated by the measurement host when it
creates the echo request packet. It is updated (as described in
section 4.2.1) by forwarding routers that insert a route record
into the IPMP packet. The checksum is not checked by the
echoing system. Errors that occur between the measurement host
and the echoing system are detected when the echo reply is
received at the measurement host (as are errors that occur
between the echoing system and the measurement host).
The IP header in the encapsulated echo reply packet is identical
to the IP header in the encapsulated echo request except that
the source and destination IP addresses are revered. Because
the IP checksum algorithm does not detect miss-ordered (16-bit)
words this means that the checksum in IP header on the echo
reply has the same value as the checksum in IP header of the
echo request.
A similar argument applies to the IPMP checksum, however the
echoing system is at liberty to place any value in the return
type field. The measurement host must replace this value with 1
before checking the IPMP checksum.
The algorithm for checking the integrity of an IPMP echo receive
packet is:
1. set the Return Code field to 1
2. recalculate the checksum as described in section 2.1
3. compare the calculated checksum with the received checksum
and discard the packet if they are not equal
4.2.1 Checksum update at a forwarding router.
A forwarding router that does not include a path record does not
check or modify the IPMP checksum. (Normal IP forwarding occurs
including decrementing TTL and updating the IP header checksum.)
A forwarding router that includes a path pointer must update the
IPMP checksum. This may be done in two ways:
a) Absolute. Check that the checksum matches for the received
packet. If it does not set the checksum in the forwarded
packet to 0. If the checksum in the received packet does
match add the Route Record to the packet and recalculate
the checksum.
b) Relative. Form the checksum of the path record (this will
be a constant for a particular interface if timestamps are
not used) and the previous checksum.
Option a) or b) is selected on the basis of efficiency.
4.3 Timestamps
The timestamp field is coded following the conventions described
in RFC1305 NTP [2].
4.3.1 Timestamp format
Summarising from RFC1305:
In conformance with standard Internet practice, timestamps
are specified as integer or fixed-point quantities, with
bits numbered in big-endian fashion from 0 starting at the
left, or high-order, position. All quantities are unsigned
and may occupy the full field width with an implied 0
preceding bit 0.
Timestamps are represented as a 64-bit unsigned fixed-point
number, in seconds relative to 0h on 1 January 1900. The
integer part is in the first 32 bits and the fraction part
in the last 32 bits. In the fraction part, the
non-significant low order can be set to 0.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format allows convenient multiple-precision arithmetic
and conversion to UDP/TIME representation (seconds), but
does complicate the conversion to ICMP Timestamp message
representation, which is in milliseconds. The most future
time that can be represented is 4,294,967 (some time in the
year 2036) with a precision of about 200 picoseconds, which
should be adequate for even the most demanding measurements.
RFC 2030 (SNTP) contains a proposal for extending timestamps
beyond the year 2036.
4.3.2 Inferred Real Time
the real time of the timestamp may be inferred when a system
provides an IPMP Information Reply with at least one Real Time
Reference Point earlier and one later than the timestamp. For
the purpose of this inference the clock drift of the interfaces
clock is assumed to be linear and linear interpolation is used
between the two nearest Real Time Reference Points where one is
greater than and one is less than, the timestamp.
The accuracy field of an Information Reply reports the greatest
difference between an inferred real time, calculated using linear
interpolation, and true real time.
4.4 Minimum Implementations.
4.4.1 Echoing System
The simplest echoing system implementation returns the IPMP echo
request without a path record. As described in section 3.2 this
only requires that the IP source and destination addresses be
exchanged, the type field changed and the packet scheduled for
forwarding. Because of the format of the IPMP echo request and
echo reply packets this can be implemented with a very small
number of instructions. A system that does not insert path
records does not need to processes IPMP Echo Requests.
Systems which just provide this level of implementation allow a
number of measurements to be made that are not currently
possible, particularly if they are routers that processes ICMP
at a low priority to avoid DOS attacks.
4.4.2 Forwarding System
Forwarding systems do not need to be IPMP aware (unless they
implement protocol based scheduling).
A forwarding system that is IPMP aware may include path records
with only the Forwarding IP Address set. This requires writing
the address to the packet and updating the checksum and Path
Pointer in the packet as described in section 3.3.1 and 4.2.1.
In this case the forwarding system does not need to process IPMP
Information Request packets.
References
[1] Braden, R., and J. Postel, "Requirements for Internet Gateways",
STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[2] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[3] Mills, D. "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI." RFC 2030, October 1996.
[4] Case, J., et al. "Protocol Operations for Version 2 of the
Simple Network Management Protocol (SNMPv2)"
RFC 1905, October 1996.
QUESTIONS: