home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0781.txt < prev    next >
Text File  |  1996-05-07  |  4KB  |  49 lines
  1. RFC 781                                                            Zaw-Sing Su                                                                            SRI                                                                       May 1981 
  2.  
  3.  A SPECIFICATION OF THE INTERNET PROTOCOL (IP) TIMESTAMP OPTION 
  4.  
  5.  
  6.  
  7.  
  8.  
  9. I. INTRODUCTION 
  10.  
  11.      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. 
  12.  
  13.      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. 
  14.  
  15.      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.      
  16.  
  17. II.  FORMAT SPECIFICATION 
  18.  
  19.      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. 
  20.  
  21.       0               7               15              23              31      +---------------+---------------+---------------+---------------+      |     type      |    length     |    offset     |overflw| flags |      +---------------+---------------+---------------+---------------+      |                          internet ID                          |      +---------------+---------------+---------------+---------------+      |                          time stamp                           |      +---------------+---------------+---------------+---------------+                      .                      .                      . 
  22.  
  23.  
  24.  
  25.  
  26.      option type = 68 decimal (i.e., option class = 2 and option number = 4); 
  27.  
  28.      option length = the number of octets with a maximum of 40 (limited by          IHL = 15); 
  29.  
  30.      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; 
  31.  
  32.      overflow =  the number of IP modules that cannot register timestamps due          to lack of space; 
  33.  
  34.      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; 
  35.  
  36.      internet ID = ID for the timestamping device; 
  37.  
  38.      timestamp = a right-justified, 32-bit timestamp in milliseconds modulo          24 hours from midnight UT. 
  39.  
  40.      The timestamp option is not copied upon fragmentation.  It is carried in the first fragment. 
  41.  
  42.  REFERENCES 
  43.  
  44. [Cerf 78]   Cerf, V., "The Catenet Model for Internetworking," Defense         Advanced Research Projects Agency, Information Processing         Techniques Office, IEN 48, July 1978. 
  45.  
  46. [Mills 81]  Mills, D.L., "DCNET Internet Clock Service," RFC 778, COMSAT         Laboratories, April 1981. 
  47.  
  48. [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. 
  49.