[ntpwg] Documents, slides, etc. from WG meeting
heiko.gerstung at meinberg.de
Wed Oct 24 12:07:27 UTC 2007
Brad Knowles schrieb:
> On 10/23/07, Danny Mayer wrote:
>>> A long discussion at end of meeting discussing the future of
>>> timekeeping here in the IETF. Is the future 1588 over IP?
>>> NTP over IP? No consensus was reached.
>> Could some explain exactly what that means? Is this a question of
>> certain protocols (DNS and Kerberos come immediately to mind) that
>> require that two interacting servers keep their clocks within X minutes
>> of each other in order for various security requirements to work
>> correctly or ro be assumed to be valid? Is it something else?
> Well, NTP is inherently an IP protocol. From reading the IEEE 1588
> page, it's not clear whether this works over IP or not, although it
> does seem to work over Ethernet (and maybe others?). But IEEE 1588
> seems to focus on ultra-high resolution, like sub-microsecond or even
> sub-nanosecond. Meinberg appears to have a clock that does both NTP
> and IEEE 1588.
> But I'm not seeing how IEEE 1588 can provide synchronization to an
> outside reference, and I'm not seeing how it can be used outside of
> certain limited circumstances on a pretty much pure Ethernet network.
There are several mappings for IEEE1588 in V2, I guess that the UDPv4,
UDPv6 (layer 3) and Ethernet (layer 2) based mappings will see a larger
installation base in the future. As far as I remember, V2 is still being
worked on in the standardization process, although it looks like it is
almost done. That might be the reason why the IEEE1588 page does not say
anything about it.
The main purpose of PTP/IEEE1588 is not "absolute" synchronization to
UTC but "relative" synchronization to the same source. Since one of its
design goals (as far as I interprete it) is sub-microsecond accuracy, it
is not working very well over WAN links and other asymmetric network
infrastructures (imagine the unpredictable delay a regular
store-and-forward switch introduces when it is queueing packets) . NTP
does a much better job in such an environment, no doubt about that.
From our perspective (as a vendor selling products in both worlds) we
see that PTP is trying to solve a lot of problems that NTP takes care of
since a couple of years, like redundancy of sync references, unicast
operation and security. The one thing that really enables PTP to reach
an impressive accuracy level over an Ethernet/UDP connection is the fact
that it uses hardware time stamping and therefore requires specialized
hardware (if you want to benefit from that superior level of accurcacy).
Our GPS synchronized grandmaster is in fact a stratum 1 NTP timeserver
with an add-on module which adds a PTP/IEEE1588 network port (with
hardware timestamping) to the package. Of course there are other
products (GPS synchronized grandmaster clocks) from other vendors. This
type of product results in a PTP network being synchronized to an
outside source (GPS), just like a GPS synchronized NTP server does the
same for its clients.
More information about the ntpwg