D. Mills. Network time protocol (version 3) specification, implementation. Request for Comments 1305, Internet Engineering Task Force, Mar. 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....can be applied to end to end delays as well. 2.6 Problems in One Way Delay Measurement Three potential problems exist in One Way Delay measurement: Clock synchronization. Two di erent hosts (especially remote ones) usually do not have their computer clocks synchronized. The NTP protocol [25] has been suggested to synchronize remote clocks. The typical performance of NTP on the Internet is in the order of 10ms [24] This is a non negligible portion for a typical Internet one way delay. If we consider the propagation delay to be a main contributor of one way delay, then a US ....

David L. Mills. Network time protocol (version 3) specication, implementation. Request for Comments (Draft Standard) 1305, Internet Engineering Task Force, March 1992.

....9 clock i and now is at most =2: for each process i: now =2 clock i now =2. This implies that the maximum di erence between two processes internal clocks is at most . The assumption that clocks are synchronized within a bound is very reasonable. For example, the Network Time Protocol (NTP) [Mil92] can synchronize clocks to within one to fty milliseconds on most network environments today. The synchronization level depends on the network technology, and on the distances between the synchronizing processes. In addition to clock synchronization, we make the assumption that each process can ....

David L. Mills. Network Time Protocol (Version 3) Specication, Implementation, RFC 1305, March 1992. Internet Engineering Task Force, Network Working Group.

....can be applied to end to end delays as well. 2.6 Problems in One Way Delay Measurement Three potential problems exist in One Way Delay measurement: Clock synchronization. Two di erent hosts (especially remote ones) usually do not have their computer clocks synchronized. The NTP protocol [25] has been suggested to synchronize remote clocks. The typical performance of NTP on the Internet is in the order of 10ms [24] This is a non negligible portion for a typical Internet one way delay.Ifwe consider the propagation delay to be a main contributor of one way delay, then a US ....

David L. Mills. Network time protocol (version 3) specication, implementation. Request for Comments (Draft Standard) 1305, Internet Engineering Task Force, March 1992.

....is at most Gamma. In this paper we represent the algorithm as timed automata (cf. 27] Ch. 23) and assume that the processes clocks guarantee the above properties. The assumption that clocks are synchronized within a bound is very reasonable. For example, the Network Time Protocol (NTP) [32] can synchronize clocks to within one to fifty milliseconds on most network environments today. The synchronization level depends on the network technology, and on the distances between the synchronizing processes. In addition to clock synchronization, we make the assumption that each process can ....

D. L. Mills. Network Time Protocol (Version 3) Specification, Implementation, RFC 1305, March 1992. Internet Engineering Task Force, Network Working Group.

....different regions of the distribution tree, which represent their region in distance calculation estimates. This scheme significantly improves the scalability of RTT calculation in SRM. The requirement for background session messages to build distance information is removed, if receivers use NTP [Mills, 1996] and have synchronised clocks. Although the level of deployment of NTP on current Mbone hosts is not very good, there is no reason why it should not be in use. With synchronised clocks a distance estimate can be obtained from a single timestamped message. A receiver of a request or an offer can ....

D. Mills. SimpleNetwork Time Protocol (SNTP) version 4 for IPv4, IPv6 and OSI. Request for comments (Proposed Standard) RFC 2030, Internet Engineering Task Force, October 1996. Obsoletes RFC 1769.

....any key of the one way key chain commits to all following keys, so we call such a key a one way key chain commitment, or simply key chain commitment. 2. 2 Time Synchronization TESLA does not need the strong time synchronization properties that sophisticated time synchronization protocols provide [22, 24, 37], but only requires loose time synchronization, and that the receiver knows an upper bound on the sender s local time. We now outline a simple and secure time synchronization protocol that achieves this requirement. For simplicity, we assume the clock drift of both sender and receiver is ....

....3.3 Bootstrapping Receivers Before a receiver can authenticate messages with TESLA, it needs to be loosely time synchronized with the sender, know the disclosure schedule of keys, and receive an authenticated key of the one way key chain. Various approaches exist for time synchronization [24, 37, 22]. TESLA, however, only requires loose time synchronization between the sender and the receivers, so a simple algorithm is sufficient. The time synchronization property that TESLA requires is that each receiver can place an upper bound of the sender s local time, as we discuss in Section 2.2. The ....

D. Mills. Network Time Protocol (version 3) specification, implementation and analysis. Internet Request for Comment RFC 1305, Internet Engineering Task Force, March 1992.

....in section 3.1.2) The agent IP address may be set when a mobile node decides to use a particular agent. This allows other agents to quickly discard the beacon and avoid the authentication computation. The time portion of the beacon, which includes both seconds and fractional seconds in NTP format [10], makes replay attacks harder. The security parameter index is an opaque identifier shared by the sender and recipients that indicates which algorithm and key to use to authenticate the packet. Nodes share a secret key they use as input to a MAC algorithm. Our implementation only provides keyed ....

David Mills. Network Time Protocol (Version 3). Request for Comments, RFC 1305, Internet Engineering Task Force, March 1992. University of Delaware.

....to timestamps in HTTP messages, although it does point out that insufficient timestamp resolution in server and proxy logs can interfere with log analysis. Several studies have reported on time synchronization in the Internet, using the facilities provided by the Network Time Protocol (NTP) [4]. The largest and most recent of these surveys, by Minar [5] reports a surprising number of bad timekeepers. That is, many ostensibly synchronized clocks are not. This study did not look specifically at Web server clocks. Wills and Mikhailov [7] studied a set of URLs taken from a proxy cache ....

David Mills. Network Time Protocol (v3). RFC RFC 1305, Internet Engineering Task Force, April, 1992.

No context found.

D. Mills. Network time protocol (version 3) specification, implementation. Request for Comments 1305, Internet Engineering Task Force, Mar. 1992.

No context found.

D. Mills. Network Time Protocol (Version 3), Specification, Implementation and Analysis. Internet Engineering Task Force, RFC 1305, March 1992.

No context found.

D. L. Mills. Network time protocol (version 3). Request for Comments (Draft Standard) RFC 1305, Internet Engineering Task Force, March 1992.

No context found.

D. Mills. Network time protocol (version 3) specification, implementation. RFC 1305, Internet Engineering Task Force, March 1992.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC