RFC 781 UNKNOWN IP · MEASUREMENT · PERFORMANCE

Specification of the Internet Protocol (IP) timestamp option

Adding clock timestamps to IP packets to measure network delays.

On rfc-editor.org ↗
PUBLISHED
May 1981
AUTHORS
Z. Su
STREAM
Legacy
OPTION TYPE
68 (decimal)
MAXIMUM LENGTH
40 octets
TIMESTAMP SIZE
32 bits
TIME UNIT
Milliseconds modulo 24 hours from midnight UT
DOI
10.17487/RFC0781

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
RFC 781                                                            Zaw-Sing Su
                                                                           SRI
                                                                      May 1981


A SPECIFICATION OF THE INTERNET PROTOCOL (IP) TIMESTAMP OPTION





I. INTRODUCTION

     Packet switching is store-and-forward by nature.  Network delay is a
therefore a critical performance measure for packet-switching communications.
A catenet is a system of packet-switched communication networks interconnected
via gateways [Cerf 78].  The catenet "link" delays are thus variable.  Their
measurement, the measurement of delays across member networks of a catenet,
becomes important for catenet investigations.

     An effective way to measure catenet delays is by means of packet header
timestamping.  Header timestamping allows monitoring of catenet delays for
user traffic, such as the case of Ft. Bragg users accessing ISID across the
catenet.  Packet header timestamping is also compatible with the use of test
packets for catenet delay measurement.  Another advantage of header
timestamping is that since it is an IP option, the gateway imposes little
difference in the treatment of such a packet.  In this note, a specification
of the timestamp option format for IP is presented.

     Measurement of one-way delay, either end-to-end or across an individual
network, requires that device clocks be synchronized, using such facilities as
WWVB clocks [Mills 81].  This specification assumes this capability in the
gateways and involved network hosts.


II.  FORMAT SPECIFICATION

     As an IP option, the contents of the first two octets are dictated by the
IP header format to be option type and option length in octets [Postel 80].
The next two octets are used to control this option.


     0               7               15              23              31
     +---------------+---------------+---------------+---------------+
     |     type      |    length     |    offset     |overflw| flags |
     +---------------+---------------+---------------+---------------+
     |                          internet ID                          |
     +---------------+---------------+---------------+---------------+
     |                          time stamp                           |
     +---------------+---------------+---------------+---------------+
				     .
				     .
				     .

     option type = 68 decimal (i.e., option class = 2 and option number = 4);

     option length = the number of octets with a maximum of 40 (limited by
		 IHL = 15);

     offset =    the number of octets from the beginning of this option to the
		 end of timestamps (i.e., the beginning of space for next
		 timestamp).  It is set to one, an odd number, when no more
		 space remains in the header for timestamps;

     overflow =  the number of IP modules that cannot register timestamps due
		 to lack of space;

     flag = 0 -- time stamps only
	    1 -- each timestamp is preceded with internet ID of the
		 registering entity
	    3 -- the internet ID fields are prespecified.  An IP module only
		 registers its timestamp if it matches its own ID with the
		 next specified internet ID;

     internet ID = ID for the timestamping device;

     timestamp = a right-justified, 32-bit timestamp in milliseconds modulo
		 24 hours from midnight UT.

     The timestamp option is not copied upon fragmentation.  It is carried in
the first fragment.


REFERENCES

[Cerf 78]   Cerf, V., "The Catenet Model for Internetworking," Defense
	    Advanced Research Projects Agency, Information Processing
	    Techniques Office, IEN 48, July 1978.

[Mills 81]  Mills, D.L., "DCNET Internet Clock Service," RFC 778, COMSAT
	    Laboratories, April 1981.

[Postel 80] Postel, J. (ed.), "DoD Standard Transport Internet Protocol,"
	    Defense Advanced Reseach Projects Agency, Information Processing
	    Techniques Office, RFC 760, IEN 128, January 1980.

AI ELI5

On this page
PROBLEMNetwork engineers needed to measure the time delay as packets traveled through interconnected networks (catenets), but had no standard way to collect timing data.
MECHANISMThis RFC defines an IP header option that lets routers and gateways stamp the current time into a packet as it passes through, creating a trail of clock readings along the packet's path.
PERFORMANCE MEASUREMENT TOOLThis allows operators to measure end-to-end delays and delays across individual networks by examining the sequence of timestamps in a packet that reaches its destination.

§1Measuring Network Delay

As networks became interconnected via gateways into larger catenets, measuring the delay experienced by packets became important for understanding performance. The RFC defines an IP timestamp option that allows gateways to record the time when each packet passes through them.

Measurement requires that device clocks be synchronized, using facilities such as WWVB time service. The timestamp is a 32-bit value representing milliseconds modulo 24 hours from midnight UT.

When a packet travels through the network, each router can write down what time it saw it. By collecting all these times, you can figure out how long the packet took.

§2The Timestamp Option

The option type is 68 (decimal), with a maximum length of 40 octets. The format includes an offset field (the byte count to the end of timestamps), an overflow counter (devices that could not stamp due to lack of space), and a flags field controlling the mode:

  • Flag 0: timestamps only
  • Flag 1: each timestamp is preceded by the Internet ID of the router
  • Flag 3: the Internet ID fields are pre-specified; routers only stamp if they match the next expected ID

When the offset becomes odd (indicating no more room for timestamps), no additional routers can add timestamps. The option is carried in the first fragment of a fragmented packet.

The timestamp field is like a logbook with limited pages. Each router writes its ID and the time, then passes it on. If the book gets full, later routers skip it and mark how many could not fit.

§3Using Timestamps for Delay Measurement

To measure one-way delay, the originating host sends a packet with the timestamp option, and the destination examines the sequence of timestamps collected. The difference between consecutive timestamps shows the delay across that segment of the network.

Applications can use test packets specifically for measurement, or can piggyback timestamps on user traffic. Because the timestamp option is an IP-level option, gateways impose minimal additional overhead compared to handling normal packets.

Each timestamp shows when the packet left that location. By comparing times, you can see how long the packet spent on each hop of its journey.

§4References