Here is a proposed description of use cases and requirements for general
internet time, which I took to mean traditional uses of ntp by IT
professionals.
//Doug Arnold
3.6. ToD/ Internet
General time distribution over the Internet or IP networks, is often
called Time of Day or Wall-clock. Most existing use cases are using
NTP over the Internet with low precision requirements. However, new
applications are arising that require higher precision rates than
what is currently available.
The users of Internet time
3.6.1. ToD/Internet
Internet TOD is used is imporant to the maintenance of IT infrastrucute
in an organization. Generally the larger an organization becomes,
the more important time synchronization is. Time synchronization is
critical for the following:
1. Server and router log file entry time tags
2. "Date modified" attributes for files
3. Chron job scheduling
4. Security protocol with limited time windows for key exchange.
Server and Router log file time tag accuracy is essential to network
diagnostic tools. Such tools are used to determine the root cause of
a network failure or security breach. Often it is important to
determine the order in which certain events occur amongst a number of
network devices. The "Date modified" fields of files may also be part
of this type of analysis.
Often Chron jobs perform operations on files depending on the times in
the "Date modified" attributes files. These files might reside on more
than one computer or server.
Many security protocols, such as Kerberos, depend on athentication
"tickets" which expire after a short time. This means that an
authenicating server gives a ticket to a client, which the client can
send to another server for some service which requires authentication.
The time limit is intended to reduce the threat of the "Man in the middle
attack." To work the two servers need to have clocks synchronized to
a time error which is smaller than the ticket time out period. To
increase security there is a desire to reduce the ticket time interval.
As the time interval becomes shorter the need for server clock agreement
is increased. The trend over time is to reduce the ticket time out period.
The requirements for the ToD/Internet is summarized in the table 6.
ToD/Internet Requirements
+-------------------------------------+-----------------------------+
| Requirements | ToD/Internet |
+-------------------------------------+-----------------------------+
| Synchronization type (e.g. time, | |
| frequency or phase) | time |
| --------------------------- | --------------------------- |
| Frequency stability | no requirement |
| --------------------------- | --------------------------- |
| Frequency accuracy | no requirement |
| --------------------------- | --------------------------- |
| Uncalibrated time/time stability | no requirement |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | 10 ms |
| --------------------------- | --------------------------- |
| Stabilization time | 1 hour |
| --------------------------- | --------------------------- |
| Jitter on recovered timing signal | 100 ms |
| --------------------------- | --------------------------- |
| Wander on recovered timing signal | 10 ms |
| --------------------------- | --------------------------- |
| What expected network | |
| characteristics (WAN, LAN, MAN, | All network types |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | |
| security? (if so, which one: | Authentication sometimes |
| authentication, encription, | used |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | high availability. Clients |
| fault tolorence) | must see multipe servers |
| --------------------------- | --------------------------- |
| Traceability to a specific clock, | Not important |
| clock quality, path, time | |
| --------------------------- | --------------------------- |
| Holdover requirement | 1 hour to 1 year. Depends |
| | on server redundancy |
| | architecture |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | |
| carrier) | 0* - $10,000 USD |
| --------------------------- | --------------------------- |
| Auto-configuration (plug and play) | No |
| --------------------------- | --------------------------- |
| Manageability (how much effort the | 30-90 minutes to configure |
| operator needs to put in to manage | a new server. 5 minutes to |
| this application?) - In-band or | configure a new client. |
| out-of-band of protocol (MIBs?) | Almost no management after |
| | initial deployment. |
| --------------------------- | --------------------------- |
| Scale and scalability | system must cover entire IT |
| | infrastructure of |
| | organization. Any 1 server |
| | will cover 1 building or |
| | campus. |
| --------------------------- | --------------------------- |
+-------------------------------------+-----------------------------+
Table 6
* The free option implies pointing all clients at ntp servers available on
the public internet._______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
