RFC 781

RFC 781: The Internet Protocol (IP) Timestamp Option 💖

Author: Zaw-Sing Su, SRI 🎀 Date: May 1981 🌸 Category/status: not given in this document's header 🤷‍♀️ Obsoletes/Updates: nothing listed in the header ✨

I. Introduction ✨

Okay so packet switching is store-and-forward by nature 📦, which means network delay is therefore a critical performance measure for packet-switching communications 😤. A catenet is a system of packet-switched communication networks interconnected via gateways [Cerf 78]. Because of that, the catenet "link" delays are thus variable 🌈. Measuring them, meaning measuring the delays across the member networks of a catenet, becomes super important for catenet investigations 🔍.

An effective way to measure catenet delays is packet header timestamping 🦋. It lets you monitor catenet delays for user traffic, like when Ft. Bragg users are accessing ISID across the catenet 💅. It's also compatible with using test packets for catenet delay measurement 🧪. Another perk is that header timestamping is an IP option, so the gateway doesn't make much difference in how it treats the packet 🫶. This note presents a specification of the timestamp option format for IP 📝.

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

II. Format Specification 🎀

As an IP option, the first two octets are dictated by the IP header format: they're the option type and the 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                           |
     +---------------+---------------+---------------+---------------+
                     .
                     .
                     .

Here's the breakdown, and it's giving very organized 😭:

• 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 the next timestamp). It's 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 has three possible values:
  • 0 -- time stamps only 🕰️
  • 1 -- each timestamp is preceded with the 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. Don't forget this one, bestie, it's a whole plot twist 💀🌸

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. 🌈💅