Internet Engineering Task Force Lijun Qian
INTERNET-DRAFT Rutgers University
Expiration Date: January 2001 Anwar Elwalid
Bell Labs
Indra Widjaja
Fujitsu Network Communications
ICMP Extension for One-Way Performance Metrics
<draft-elwalid-icmp-ext-01.txt>
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
In this document we define two new ICMP message types. These new
types of ICMP messages can be used as probe packets to support a
variety of measurement applications. This draft gives detailed
definition and format of these two new ICMP message types. It is in
full conformance with the original RFC on ICMP [1], and complements
the work of the IPPM working group [6][7][8]. The extension of ICMP
for one-way traffic measurement is also useful for traffic
engineering.
1. Introduction
The Internet Control Message Protocol (ICMP) allows hosts/routers to
Elwalid et al. Expires Jan 2001 [Page 1]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
send error or control messages to other hosts/routers. ICMP provides
communication between the Internet Protocol software on one machine
and the Internet Protocol software on another[4]. ICMP is considered
a required part of IP and must be included in every IP
implementation. Although ICMP messages are encapsulated and sent
using IP, ICMP is NOT considered a higher level protocol than IP.
2. One-Way Performance Metrics
One-way performance metrics such as one-way delay and one-way loss
are useful in many situations. Unfortunately, the current ICMP
messages do not accommodate format that would facilitate such
measurements. ICMP messages type 15 and 16, information request and
information reply messages, are now considered obsolete and should
NOT be implemented by hosts [2]. In this document, we propose adding
two message types that would enable one-way measurements.
3. Backward Compatibility
ICMP extensions proposed in this document MUST be backward compatible
with the syntax described in RFC-792 [1].
4. Probe Request and Reply
The ICMP messages types are listed below in table 1.
Type Name Reference
---- ------------------------- --------------------
0 Echo Reply [RFC792]
1 Unassigned [JBP]
2 Unassigned [JBP]
3 Destination Unreachable [RFC792]
4 Source Quench [RFC792]
5 Redirect [RFC792]
6 Alternate Host Address [JBP]
7 Unassigned [JBP]
8 Echo [RFC792]
9 Router Advertisement [RFC1256]
10 Router Selection [RFC1256]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792] (obsolete)
Elwalid et al. Expires Jan 2001 [Page 2]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
16 Information Reply [RFC792] (obsolete)
17 Address Mask Request [RFC950]
18 Address Mask Reply [RFC950]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [David Johnson]
33 IPv6 Where-Are-You [Bill Simpson]
34 IPv6 I-Am-Here [Bill Simpson]
35 Mobile Registration Request [Bill Simpson]
36 Mobile Registration Reply [Bill Simpson]
37 Domain Name Request [Simpson]
38 Domain Name Reply [Simpson]
39 SKIP [Markson]
40 Photuris [Simpson]
41-255 Reserved [JBP]
Table 1. The ICMP messages types
The format of ICMP message type 41 for Probe Request and type 42 for
Probe Reply (need to get the official types from the IANA) is encoded
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originate Timestamp (first 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originate Timestamp (next 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp (first 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp (next 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As described in [1], all ICMP messages begin with the same 3 fields:
Type field (8 bits), Code field (8 bits) and Checksum field (16
bits).
Elwalid et al. Expires Jan 2001 [Page 3]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
The type field indicates the type of the message. Its value
determines the format of the remaining data.
The code field depends on the message type. It is used to create an
additional level of message granularity.
The checksum field is used to detect data corruption in the entire
ICMP message.
IP Fields:
Addresses
The address of the source in a probe request message MUST be
the destination of the probe reply message. To form a probe
reply message, the source and destination addresses are simply
reversed, the type value changed to 42, and the checksum
recomputed.
ICMP Fields:
Type
41 for probe request message;
42 for probe reply message.
Code
0 for probe data;
1 for clear;
2 for clear acknowledgement.
Checksum
The checksum is the 16-bit ones's complement of the one's
complement sum of the entire ICMP message starting with the
ICMP Type field. For computing the checksum, the checksum
field should be first set to zero.
Identifier
An identifier to aid in matching probe replies to probe
requests. The identifier of a probe reply is
obtained from the invoking probe request.
Description
Elwalid et al. Expires Jan 2001 [Page 4]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
The identifier may be used by the sender to aid in matching the
replies with the requests. For example, the identifier might be
used like a port in TCP or UDP to identify a session. The
destination returns these same values in the reply.
The data received (a probe) in the probe request message is
returned in the probe reply together with additional
information on receive timestamp and destination sequence
number.
All timestamps are 64 bits. The current time is expressed
in elapsed seconds and microseconds since 00:00 Universal
Coordinated Time, January 1, 1970. The resolution of the system
clock is hardware dependent; the time may be updated
continuously or in clock ticks.
The Originate Timestamp is the time the sender last touches the
message before sending it, the Receive Timestamp is the time
the receiver first touches the message on receipt.
The first four octets record the time in seconds, and the next
four octets give the microseconds granularity.
The source encodes a Source Sequence Number to notify the
destination how many probe packets have been transmitted by the
source. The destination encodes a destination Sequence Number
to notify the source how many probe packets have been received
by the destination.
If the time is not available in microseconds or cannot be
provided with respect to midnight UT then any time can be
inserted in a timestamp provided the high order bit of the
timestamp is also set to indicate this non-standard value.
ICMP message type 41 and 42 SHOULD be implemented in all internet
hosts to support one-way traffic measurement.
The delay of a packet on any route can be obtained by transmitting
an ICMP probe request packet from the source to the destination.
The ICMP probe request packet is timestamped at the source at
time t1 and recorded at the destination at time t2. Then (t2-t1)
is the total delay adjusted with the time difference between the
source clock and destination clock. For applications which
synchronization is needed, estimation of one-way delay may be done
based on [9][10]. Network Time Protocol is defined in [11] and is
beyond the scope of this document. The specific synchronization
technique which determines the accuracy of the measurement is
beyond the scope of this document.
Elwalid et al. Expires Jan 2001 [Page 5]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
When an ICMP probe reply packet returns, the source is able to
estimate the one-way packet loss rate based on the two
sequence numbers encoded in the ICMP probe reply packet. The
detailed procedure is included in Appendix 1. The mechanism is
intended to combat against losses and re-ordering in the reverse
channel. It is recommended that if responses are reordered, then
the sender uses the most recent response; that is, the response
with the higher "x" value.
5. Security Considerations
This memo presents no security considerations beyond those that have
been presented by current ICMP applications.
6. Acknowledgement
The authors thank Ron Bonica for useful discussions.
7. Reference
[1] RFC 792, "Internet Control Message Protocol", J.Postel, Sep.,1981.
[2] RFC 1122, "Requirements for Internet hosts -- Communication layers,
R.Braden ed., Oct.,1989.
[3] R. Bonica et al., "ICMP Extensions for MPLS", <draft-bonica-icmp-
mpls-01.txt>, May 1999.
[4] Internetworking with TCP/IP, vol.1 (3rd. Ed.), D.E.Comer, Prentice
Hall, Inc., 1995.
[5] Internet Draft: MATE: MPLS Adaptive Traffic Engineering, Indra Widjaja
and Anwar Elwalid, July, 1998. <draft-widjaja-mpls-mate-00.txt>.
[6] RFC 2330, "Framework for IP Performance Metrics", V.Paxson et.al.,
May,1998.
[7] RFC 2679, "A One-way Delay Metric for IPPM", G.Almes et.al.,
Sep.1999.
[8] RFC 2680, "A One-way Packet Loss Metric for IPPM", G.Almes et.al.,
Sep.1999.
[9] RFC 956, "Algorithms for Synchronizing Network Clocks", D.L.Mills,
Sep.1985.
[10]RFC 957, "Experiments in Network Clock Synchronization", D.L.Mills,
Sep.1985.
[11]RFC 1305, "Network Time Protocol(Ver.3) - Specification,
Implementation and Analysis", D.L.Mills, Mar.1992.
Appendix 1.
Elwalid et al. Expires Jan 2001 [Page 6]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
If an endpoint (sender or receiver) wants to terminate the
measurement phase and clears its state, it sends an ICMP packet with
Code = 1. Upon receiving this, the recipient is obligated to
acknowledge this with Code = 2. This exchange should be reliable in
the sense that the endpoint keeps re-transmitting, if neccessary,
until it receives the acknowledgement.
Sender behavior:
0. Create ICMP control block and set Source_Sequence_Number = 1.
1. Send an ICMP Request with Originate_Timestamp = t1.
2. Set an inter-probe interval timer.
3. If receive a Reply with Source_Sequence_Number = x, and
Destination_Sequence_Number = y,
updates one-way packet loss to 1 - y / x.
4. If receive a Reply with Code = 1
Clear control block, if any.
Acknowledge with Code = 2
Go to 7.
5. If measurement is completed,
# clear measurement
Send ICMP Request with Code = 1
and wait for an acknowledgement.
Re-transmit until the ack is received.
Go to 7.
6. If the inter-probe interval timer expires,
Increment Source_Sequence_Number.
Go to 1.
7. Clear control block and done.
Receiver behavior:
1. Receive an ICMP Request.
2. If (Code = 1)
Clear control block, if any.
Acknowledge with Code = 2 Go to 5.
3. If <Source_IP, Dest_IP, Identifier> is not found,
# this is the first packet in the train
Create an ICMP control block.
Set Destination_Sequence_Number to 1.
S <- Source_Sequence_Number.
Send an ICMP Reply with Receive_Timestamp = t2.
Set a timer for the control block
Clear control block if timer expires
Else # this is the succeding packet
If (Source_Sequence_Number > S)
S <- Source_Sequence_Number.
Increment Destination_Sequence_Number
Send an ICMP Reply with Receive_Timestamp =
Elwalid et al. Expires Jan 2001 [Page 7]
Internet Draft ICMP Extension for One-Way Performance Aug 2000
t2.
Else
# out-of-order packet is detected
# clear measurement
Send ICMP Reply with Code = 1
and wait for an acknowledgement.
Re-transmit until the ack is received.
Clear control block
Go to 5.
4. Go to 1.
5. Done.
Elwalid et al. Expires Jan 2001 [Page 8]