idnits 2.17.1 draft-mogul-pps-api-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 246 has weird spacing: '... long tv_...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 January 1998) is 9599 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 503 looks like a reference -- Missing reference section? '2' on line 170 looks like a reference -- Missing reference section? '4' on line 85 looks like a reference -- Missing reference section? 'EBADF' on line 483 looks like a reference -- Missing reference section? 'EOPNOTSUPP' on line 487 looks like a reference -- Missing reference section? 'EPERM' on line 444 looks like a reference -- Missing reference section? 'EFAULT' on line 485 looks like a reference -- Missing reference section? 'EINVAL' on line 441 looks like a reference -- Missing reference section? '1' on line 615 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jeffrey Mogul, DECWRL, 3 Internet-Draft David Mills, UDel 4 Expires: 15 July 1998 Jan Brittenson, Sun 5 12 January 1998 7 Pulse-Per-Second API for UNIX 9 draft-mogul-pps-api-01.txt 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress." 25 To learn the current status of any Internet-Draft, please 26 check the "1id-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za 28 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 29 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 30 West Coast). 32 Distribution of this document is unlimited. Please send 33 comments to the authors. 35 ABSTRACT 37 RFC1589 describes a UNIX kernel implementation model for 38 high-precision time-keeping. This is meant for use in 39 conjunction with the Network Time Protocol (NTP, RFC1305), 40 or similar time synchronization protocols. One aspect of 41 this model is an accurate interface to the high-accuracy, 42 one pulse-per-second (PPS) output typically available from 43 precise time sources (such as a GPS or GOES receiver). 44 RFC1589 did not define an API for managing the PPS 45 facility. This document specifies such an API. 47 TABLE OF CONTENTS 49 1 Introduction 2 50 2 Data types for representing timestamps 3 51 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 53 2.1 Resolution 4 54 2.2 Time scale 4 55 3 API 4 56 3.1 New data structures 5 57 3.2 Mode bit definitions 6 58 3.3 New functions 7 59 3.3.1 New functions: access to PPS events 7 60 3.3.2 New functions: setting PPS mode bits 8 61 3.3.3 New functions: access to PPS timestamps 9 62 3.3.4 New functions: disciplining the kernel timebase 10 63 3.4 Example 10 64 4 PPSDISC Line discipline 11 65 4.1 Example 11 66 5 Security Considerations 12 67 6 Acknowledgements 12 68 7 References 13 69 8 Authors' addresses 13 71 1 Introduction 73 RFC1589 [3] describes a model and programming interface for generic 74 operating system software that manages the system clock and timer 75 functions. The model provides improved accuracy and stability for 76 most workstations and servers using the Network Time Protocol 77 (NTP) [2] or similar time synchronization protocol. The model 78 supports the use of external timing sources, such as the precision 79 pulse-per-second (PPS) signals typically available from precise time 80 sources (such as a GPS or GOES receiver). 82 However, RFC1589 did not define an application programming interface 83 (API) for the PPS facility. This document specifies such an 84 interface, for use with UNIX (or UNIX-like) operating systems. Such 85 systems often conform to the ``Single UNIX Specification'' [4], 86 sometimes known as POSIX. 88 One convenient means to provide a PPS signal to a computer system is 89 to connect that signal to a modem-control pin on a serial-line 90 interface to the computer. The Data Carrier Detect (DCD) pin is 91 frequently used for this purpose. Typically, the time-code output of 92 the time source is transmitted to the computer over the same serial 93 line. The computer detects a signal transition on the DCD pin, 94 usually by receiving an interrupt. 96 Although existing practice has focussed on the use of serial lines 97 and DCD transitions, PPS signals might also be delivered by other 98 kinds of devices. The API specified in this document does not 99 require the use of a serial line, although it may be somewhat biased 100 in that direction. 102 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 104 The typical use of this facility is for the operating system to 105 record a high-resolution timestamp as soon as possible after it 106 detects a PPS signal transition (usually indicated by an interrupt). 107 This timestamp can then be made available, with less stringent delay 108 constraints, to timekeeping software. The software can compare the 109 captured timestamp to the received time-code to accurately determine 110 the absolute offset between the system clock and the precise time 111 source. 113 The operating system may also deliver the PPS event immediately to a 114 procedure used to discipline its internal timebase, such as the 115 hardpps() procedure described in RFC1589. 117 The API specified in this document allows for one or more signal 118 sources attached to a computer system to provide PPS inputs, at the 119 option of user-level software. User-level software may obtain 120 DCD-transition timestamps for any of these PPS sources. User-level 121 software may optionally specify that at most one of these PPS sources 122 be used to discipline the system's internal timebase. 124 Although the primary purpose of this API is for capturing true 125 pulse-per-second events, the API may also be used for accurately 126 timestamping events of other periods, or even aperiodic events, when 127 these can be expressed as signal transitions. 129 This document does not define how the API must be implemented, and 130 does not specify constraints on the accuracy, resolution, or latency 131 of the PPS feature. However, the utility of this feature is 132 inversely proportional to the delay (and variance of delay), and 133 implementors are encouraged to take this seriously. 135 In principle, the rate of events to be captured, or the frequency of 136 the signals, can range from once per day (or less often) to several 137 thousand per second. However, since in most implementations the 138 timestamping function will be implemented as a processor interrupt at 139 a relatively high priority, it is prudent to limit the rate of such 140 events. This may be done either by mechanisms in the hardware that 141 generates the signals, or by the operating system. 143 2 Data types for representing timestamps 145 Computer systems use various representations of time. Because this 146 API is concerned with the provision of high-accuracy, high-resolution 147 time information, the choice of representation is significant. (Here 148 we consider only binary representations, not human-format 149 representations.) 151 The two interesting questions are: 153 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 155 1. what is the resolution of the representation? 157 2. what time scale is represented? 159 These questions often lead to contentious arguments. Since this API 160 is intended for use with NTP and POSIX-compliant systems, however, we 161 can limit the choices to representations compatible with existing NTP 162 and POSIX practice, even if that practice is considered ``wrong'' in 163 some quarters. 165 2.1 Resolution 166 In the NTP protocol, ``timestamps are represented as a 64-bit 167 unsigned fixed-point number, in seconds relative to 0h on 1 January 168 1900. The integer part is in the first 32 bits and the fraction part 169 in the last 32 bits [...] The precision of this representation is 170 about 200 picoseconds'' [2]. 172 However, most computer systems cannot measure time to this resolution 173 (this represents a clock rate of 5 GHz). The POSIX gettimeofday() 174 function returns a ``struct timeval'' value, with a resolution of 1 175 microsecond. The POSIX clock_settime() function returns a ``struct 176 timespec'' value, with a resolution of 1 nanosecond. 178 This API uses the ``struct timespec'' representation, since in a 179 general-purpose computer system it is just barely feasible to measure 180 time to a precision of a few microseconds. It might become possible 181 to improve this resolution within the next few years. We do not 182 expect it to be feasible for a general-purpose system to measure time 183 to a precision of less than one nanosecond in the foreseeable future. 185 2.2 Time scale 186 Several different time scales have been proposed for use in computer 187 systems. UTC and TAI are the two obvious candidates. 189 Some people would prefer the use of TAI, which is identical to UTC 190 except that it does not correct for leap seconds. Their preference 191 for TAI stems from the difficulty of computing precise time 192 differences when leap seconds are involved, especially when using 193 times in the future (for which the exact number of leap seconds is, 194 in general, unknowable). 196 However, POSIX and NTP both use UTC, albeit with different base 197 dates. Given that support for TAI would, in general, require other 198 changes to the POSIX specification, This API uses the POSIX base date 199 of midnight January 1, 1970. 201 3 API 203 A PPS facility can be used in two different ways: 205 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 207 1. An application can obtain a timestamp, using the system's 208 internal timebase, for the most recent PPS event. 210 2. A kernel may directly utilize PPS events to discipline its 211 internal timebase, thereby providing highly accurate time 212 to all applications. 214 This API supports both uses, individually or in combination. The 215 timestamping feature may be used on any number of PPS sources 216 simultaneously; the timebase-disciplining feature may be used with at 217 most one PPS source. 219 Although the proper implementation of this API requires support from 220 the kernel of a UNIX system, this document defines the API in terms 221 of a set of library routines. This gives the implementor some 222 freedom to divide the effort between kernel code and library code 223 (different divisions might be appropriate on microkernels and 224 monolithic kernels, for example). 226 3.1 New data structures 227 The data structure declarations and symbol definitions for this API 228 will appear in the header file . 230 The API defines one new data structure: 232 typedef struct ppsinfo { 233 pps_seq_t sequence; /* event sequence # */ 234 struct timespec timestamp; /* time of event */ 235 int flags; /* flag bits */ 236 } ppsinfo_t; 238 The ``pps_seq_t'' type is an unsigned integer data type of at least 239 32 bits. The precise declaration of this type is system-dependent. 241 --------- 242 Note: the standard declaration for "struct timespec" is: 244 typedef struct timespec { 245 time_t tv_sec; /* seconds */ 246 long tv_nsec; /* nanoseconds */ 247 } timespec_t; 249 --------- 251 The sequence number increases once per captured timestamp. Its 252 initial value is undefined. If incremented past the largest unsigned 253 long value, the next value is zero. 255 --------- 256 Note that the sequence number is most useful in applications 257 where events other than PPS transitions are to be captured, 259 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 261 which might be involved in a precision stopwatch application, 262 for example. In such cases, the sequence number may be used to 263 detect overruns, where the application has missed one or more 264 events. It may also be used to detect an excessive event rate, 265 or to detect that an event has failed to occur between two 266 calls to the time_pps_fetch() function (defined later). 267 --------- 269 The timestamp field represents the value of the operating system's 270 internal timebase when the timestamped occurred, or as close as 271 possible to that time. 273 The flag bits are: 275 #define PPSFLAG_ASSERT 0x01 276 #define PPSFLAG_CLEAR 0x02 278 whose meanings are: 280 PPSFLAG_ASSERT The timestamp was captured when the PPS signal was 281 asserted (set to logical TRUE). 283 PPSFLAG_CLEAR The timestamp was captured when the PPS signal was 284 cleared (set to logical FALSE). 286 3.2 Mode bit definitions 287 The API defines these mode bits: 289 #define PPSMODE_NONE 0x00 290 #define PPSMODE_ONASSERT 0x01 291 #define PPSMODE_ONCLEAR 0x02 292 #define PPSMODE_ONBOTH (PPSMODE_ONASSERT|PPSMODE_ONCLEAR) 293 #define PPSMODE_HARDPPS 0x04 295 whose meanings are: 297 PPSMODE_NONE No timestamps will be captured. 299 PPSMODE_ONASSERT 300 Causes a timestamp to be captured when the PPS signal 301 is asserted (set to logical TRUE). 303 PPSMODE_ONCLEAR Causes a timestamp to be captured when the PPS signal 304 is cleared (set to logical FALSE). 306 PPSMODE_ONBOTH Causes a timestamp to be captured when the PPS signal 307 changes states, in either direction. 309 PPSMODE_HARDPPS Causes the most recently captured timestamp to be 310 communicated to the operating system module that 311 disciplines the system's internal timebase. 313 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 315 The operating system will enforce two restrictions on the use of 316 PPSMODE_HARDPPS: 318 1. It may be applied to at most one signal source at any 319 given time. 321 2. It may only be set by a process with sufficient privileges 322 to modify the system's internal timebase. (On UNIX 323 systems, such modification is normally done using 324 settimeofday() and/or adjtime(), and is restricted to 325 users with superuser privilege.) 327 If PPSMODE_HARDPPS is set, at least one of PPSMODE_ONASSERT or 328 PPSMODE_ONCLEAR should also be set. Otherwise, the behavior of 329 PPSMODE_HARDPPS is undefined. 331 The operating system may implement all of these mode bits, or just a 332 subset of them. If an attempt is made to set an unsupported mode 333 bit, the API will return an error. 335 3.3 New functions 336 In the description of functions that follows, we use the following 337 function parameters: 339 filedes A file descriptor (type: int), for a serial line or 340 other source of PPS events. 342 ppsinfobuf A record of type ``struct ppsinfo'', as defined in 343 section 3.1. 345 mode A set of mode bits (type: int), whose possible values 346 are defined in section 3.2. 348 3.3.1 New functions: access to PPS events 349 The API includes several functions use to enable or disable the use 350 of a file descriptor for other PPS-related functions. 352 SYNOPSIS 354 int time_pps_enable(int filedes); 355 int time_pps_disable(int filedes); 357 DESCRIPTION 359 Before an application can use any of the other PPS-related functions, 360 it must first call time_pps_enable() on an already-open file 361 descriptor for an appropriate special file. (The definition of what 362 special files are appropriate for use with the PPS API is outside the 363 scope of this specification, and may vary based on both operating 365 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 367 system implementation, and local system configuration. The usual 368 case is a serial line, whose DCD pin is connected to a source of PPS 369 events.) 371 After having successfully enabled the use of PPS events on a file 372 descriptor, an application may call time_pps_disable() on that file 373 descriptor. This stops the use of the PPS source for disciplining 374 the system's timebase, if it had been configured to do so. 376 The behavior of other functions in the PPS API is undefined, except 377 when applied to a file descriptor after time_pps_enable() has been 378 applied, and before time_pps_disable() has been applied. 380 RETURN VALUES 382 On successful completion, the time_pps_enable() and 383 time_pps_disable() functions return 0. Otherwise, a value of -1 is 384 returned and errno is set to indicate the error. 386 ERRORS 388 If the time_pps_enable() or time_pps_disable() function fails, errno 389 may be set to one of the following values: 391 [EBADF] The filedes parameter is not a valid file descriptor. 393 [EOPNOTSUPP] The use of the PPS API is not supported for the file 394 descriptor. 396 [EPERM] The process's effective user ID does not have the 397 required privileges to use the PPS API. 399 3.3.2 New functions: setting PPS mode bits 400 The API includes several functions use to control the mode of a 401 PPS-enabled file descriptor. 403 SYNOPSIS 405 int time_pps_setmode(int filedes, int mode); 406 int time_pps_getmode(int filedes, int *mode); 408 DESCRIPTION 410 An application may use time_pps_setmode() to set the mode value for a 411 PPS line. Mode bits are defined in section 3.2. An application may 412 use time_pps_getmode() to discover the current settings of the PPS 413 mode bits. An application that needs to change only a subset of the 415 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 417 existing mode bits must first call time_pps_getmode() to obtain the 418 current mode bit values, then set the new values using 419 time_pps_setmode(). 421 The default value for the mode bits is PPSMODE_NONE. 423 RETURN VALUES 425 On successful completion, the time_pps_setmode() and 426 time_pps_getmode() functions return 0. Otherwise, a value of -1 is 427 returned and errno is set to indicate the error. 429 ERRORS 431 If the time_pps_setmode() or time_pps_getmode() function fails, errno 432 may be set to one of the following values: 434 [EBADF] The filedes parameter is not a valid file descriptor. 436 [EFAULT] A parameter points to an invalid address. 438 [EOPNOTSUPP] The use of the PPS API is not supported for the file 439 descriptor. 441 [EINVAL] The operating system does not support all of the 442 requested mode bits. 444 [EPERM] The process's effective user ID does not have the 445 required privileges to use the PPS API, or to set the 446 given mode. 448 3.3.3 New functions: access to PPS timestamps 449 The API includes one function that gives applications access to PPS 450 timestamps. 452 SYNOPSIS 454 int time_pps_fetch(int filedes, struct ppsinfo *ppsinfobuf); 456 DESCRIPTION 458 An application may use time_pps_fetch() to obtain the most recent 459 timestamp captured for the signal source corresponding to the filedes 460 parameter. 462 The result is left in the ppsinfobuf parameter, whose fields are 463 defined in section 3.1. 465 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 467 If this function is invoked before the system has captured a 468 timestamp for the signal source, the ppsinfobuf returned will have 469 its timespec field set to the POSIX base date (i.e., both the tv_sec 470 and tv_nsec fields will be zero). 472 RETURN VALUES 474 On successful completion, the time_pps_fetch() function returns 0. 475 Otherwise, a value of -1 is returned and errno is set to indicate the 476 error. 478 ERRORS 480 If the time_pps_fetch() function fails, errno may be set to one of 481 the following values: 483 [EBADF] The filedes parameter is not a valid file descriptor. 485 [EFAULT] A parameter points to an invalid address. 487 [EOPNOTSUPP] The use of the PPS API is not supported for the file 488 descriptor. 490 3.3.4 New functions: disciplining the kernel timebase 491 The API does not include an explicit function for configuring the use 492 of a PPS signal to discipline the operating system timebase. This is 493 done using time_pps_setmode() and time_pps_getmode(). 495 Warning: If this feature is configured for a special file that does 496 not have an accurate 1-pulse-per-second signal, use of this feature 497 may result in seriously incorrect timekeeping for the entire system. 498 For best results, the 1-PPS signal should have much better frequency 499 stability than the system's internal clock source (usually a 500 crystal-controlled oscillator), and should have jitter (variation in 501 interarrival time) much less than the system's clock-tick interval. 503 See RFC1589 [3] for more information about how the system's timebase 504 is disciplined using a PPS signal. 506 3.4 Example 507 A typical use of this API might be: 509 int fd; 510 int mode; 511 ppsinfo infobuf; 513 /* Open a file descriptor and enable PPS on rising edges */ 514 fd = open(PPSfilename, O_RDONLY, 0); 516 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 518 time_pps_enable(fd); 519 mode = PPSMODE_ONASSERT; 520 time_pps_setmode(fd, mode); 522 /* loop, printing the most recent timestamp every second or so */ 523 while (1) { 524 sleep(1); 525 time_pps_fetch(fd, &infobuf); 526 printf("Timestamp: %d.%09d, sequence: %ld\n", 527 infobuf.timestamp.tv_sec, 528 infobuf.timestamp.tv_nsec, 529 infobuf.sequence); 530 } 532 Note that this example omits all of the error-checking that would be 533 expected in a reliable program. 535 4 PPSDISC Line discipline 537 One possible implementation of this API might be to define a new 538 ``line discipline'' and then map the API onto a set of ioctl() 539 commands. Here we sketch such an implementation; note that this is 540 not part of the specification of the API, and applications should not 541 expect this low-level interface to be available. 543 In this approach, the set of line disciplines is augmented with one 544 new line discipline, PPSDISC. This discipline will act exactly the 545 same as the TTYDISC discipline, except for its handling of modem DCD 546 interrupts. 548 Once the TIOCSETD ioctl() has been used to select this line 549 discipline, PPS-related operations on the serial line may be invoked 550 using new ioctl() commands. For example (values used only for 551 illustration): 553 #define PPSGETTIME _IOR('t', 75, struct ppsinfo) 554 #define PPSSETMODE _IOW('t', 76, int) 555 #define PPSGETMODE _IOR('t', 77, int) 557 4.1 Example 558 A typical use might be: 560 int ldisc = PPSDISC; 561 int ppsmode; 562 struct ppsinfo ppsbuf; 564 ioctl(fd, TIOCSETD, &ldisc); /* set discipline */ 566 /* 568 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 570 * Set this line to timestamp on a rising-edge interrupt, 571 * and assign this line for the kernel hardpps() input 572 */ 573 mode = PPSMODE_ONASSERT | PPSMODE_HARDPPS; 574 ioctl(fd, PPSSETMODE, &mode); 576 sleep(2); /* allow time for the PPS pulse to happen */ 578 /* obtain most recent timestamp and sequence # for this line */ 579 ioctl(fd, PPSGETTIME, &ppsbuf); 581 Again, this example imprudently omits any error-checking. 583 5 Security Considerations 585 This API gives applications three capabilities: 587 - Causing the system to capture timestamps on certain events. 589 - Obtaining timestamps for certain events. 591 - Affecting the system's internal timebase. 593 The first capability should not affect security directly, but might 594 cause a slight increase in interrupt latency and interrupt-handling 595 overhead. 597 The second capability might be useful in implementing certain kinds 598 of covert communication channels. 600 In most cases, neither of these first two issues is a significant 601 security threat. The system administrator may prevent applications 602 from using this API by simply using the traditional UNIX file 603 protection facility to limit access to the relevant special files, so 604 the risk inherent in providing the API is minimal. 606 The final capability is reserved to highly privileged users. In UNIX 607 systems, this means those with superuser privilege. Such users can 608 evade protections based on file permissions; however, such users can 609 in general cause unbounded havoc, and can set the internal timebase 610 (and its rate of change), so this API creates no new vulnerabilities. 612 6 Acknowledgements 614 The API in this document draws some of its inspiration from the LBL 615 ``ppsclock'' distribution [1], originally implemented in 1993 by 616 Steve McCanne, Craig Leres, and Van Jacobson. We also thank Craig 617 Leres, Judah Levine, and Ulrich Windl for helpful comments they 618 contributed during the drafting of this document. 620 Internet-Draft Pulse-Per-Second API 12 January 1998 15:53 622 7 References 624 1. Steve McCanne, Craig Leres, and Van Jacobson. PPSCLOCK. 625 ftp://ftp.ee.lbl.gov/ppsclock.tar.Z. 627 2. David L. Mills. Network Time Protocol (Version 3): 628 Specification, Implementation and Analysis. RFC 1305, IETF, March, 629 1992. 631 3. David L. Mills. A Kernel Model for Precision Timekeeping. RFC 632 1589, IETF, March, 1994. 634 4. The Open Group. The Single UNIX Specification, Version 2 - 6 Vol 635 Set for UNIX 98. Document number T912, The Open Group, February, 636 1997. 638 8 Authors' addresses 640 Jeffrey C. Mogul 641 Western Research Laboratory 642 Digital Equipment Corporation 643 250 University Avenue 644 Palo Alto, California, 94305, U.S.A. 645 Email: mogul@wrl.dec.com 646 Phone: 1 650 617 3304 (email preferred) 648 David L. Mills 649 Electrical Engineering Department 650 University of Delaware 651 Newark, DE 19716 652 Phone: (302) 831-8247 653 EMail: mills@udel.edu 655 Jan Brittenson 656 Sun Microsystems, Inc. 657 901 San Antonio Rd M/S MPK17-202 658 Palo Alto, CA 94303 659 Email: Jan.Brittenson@Eng.Sun.COM