RFC 781 UNKNOWN IP · MEASUREMENT

Specification of the Internet Protocol (IP) timestamp option

An IP option that records timestamps as a packet passes through gateways.

On rfc-editor.org ↗
PUBLISHED
May 1981
AUTHORS
Z. Su
STREAM
Legacy
OPTION TYPE
68 decimal
MAXIMUM OPTION LENGTH
40 octets
TIMESTAMP WIDTH
32 bits
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.

ISO Plain Language

On this page
PROBLEMMeasuring delays across interconnected packet networks requires timestamp information from devices along the packet's path.
MECHANISMThe IP timestamp option provides space for timestamps and optional Internet IDs, with fields for offset, overflow, and mode flags.
THE OPTIONThe memo specifies the option format and notes that one-way delay measurement depends on synchronized device clocks.

§1Measuring Delay Across Networks

Packet-switched networks store and forward packets, so their delays vary. The memo says measuring those delays across gateways and member networks is important for catenet investigations.

It proposes timestamping packet headers for both user traffic and test packets. Measuring one-way delay requires synchronized clocks in the gateways and hosts involved.

A packet's travel time can vary across interconnected networks. Recording times at gateways can help measure that delay, but the clocks must be synchronized.

§2Timestamp Option Fields

The option uses type 68 decimal and has a maximum length of 40 octets. Its control fields include an offset to the next timestamp space, an overflow count for IP modules unable to add a timestamp, and flags selecting timestamp-only, ID-plus-timestamp, or pre-specified-ID operation.

Each timestamp is a right-justified 32-bit value in milliseconds modulo 24 hours from midnight UT. The option is not copied during fragmentation and is carried in the first fragment.

The option records times and can also record or check the Internet ID of the device adding each time. Its fields show where the next timestamp goes and whether devices ran out of space.

§3Timestamping and Available Space

In timestamp-only mode, an IP module records a timestamp. In the mode that includes Internet IDs, each timestamp is preceded by the registering entity's ID. In the prespecified-ID mode, a module records its timestamp only when the next ID matches its own.

When there is no more header space for timestamps, the offset indicates that condition and the overflow field counts modules that cannot register.

Depending on the flag, a device can add only its time, add its ID and time, or add time only when its ID is expected. The option also records when space runs out.