I do not think that rollover or leap seconds are much of a problem in
this application. We are measuring the transit time of a packet across a
network. That is less than a second. Rollover or leap second errors mean
that we make a mistake once in every 136 years in the first case and
maybe never in the case of leap seconds. I am sure that it would be
acceptable to simply state that for that for that one second at some
time in the future we cannot make that measurement.
BTW we are only going to use 32 bits of seconds and 32 bits of sub
seconds in the 1588 case, and even then most of the sub second bits will
be ignored. I don't thing that we need to be measuring time of flight
over 8" of cable.
Stewart
On 03/03/2011 22:12, Shahram Davari wrote:
Agree.
Shahram
------------------------------------------------------------------------
*From*: Ron Cohen <[email protected]>
*To*: Shahram Davari
*Cc*: [email protected] <[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>
*Sent*: Thu Mar 03 13:35:11 2011
*Subject*: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp
Hi Shahram, I guess adding a requirement to take timestamp rollover
into account would do. If there is a strong reason to also leave NTP
timestamp as an option, a note explaining the ramification of leap
seconds should be added. I suggest that a continuous timescale (i.e.
PTP) would be selected in the draft as the default/must option. Best, Ron
On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari <[email protected]
<mailto:[email protected]>> wrote:
Hi Ron,
Although the PTPv2 is 80 bytes, but I don’t see a need to use all
80 bytes for delay measurement. The upper 2^32 seconds covers
almost 136 years, which should be good enough to measure delay.
Also lets’ be compatible with Y.1731 format since that HW already
exist.
Thx
Shahram
*From:*Ron Cohen [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Thursday, March 03, 2011 11:22 AM
*To:* [email protected] <mailto:[email protected]>
*Cc:* Shahram Davari; [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Subject:* Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp
Hi,
I apologize in advance if my comments below where already been
discussed.
The draft specify using PTPv1 timestamp format and not PTPv2
timestamp format. The seconds part of the PTPv2 timestamp is
48bits, and not 32bits as written in the draft. NTP timestamps
will roll over in 2036. PTPv2 timestamps do not rollover.
I don't think its advisable to include timestamps that rolls over
~20 years from now.
In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap
seconds events. This makes calculation of time differences hard,
and would render some measurements ambiguous. It is much easier to
use continuous timescale like PTP.
In my opinion changing the timestamp format to PTPv2 timestamp
format (i.e. 48bit/32bit sec/ns) should be the right way to go. I
would also remove the NTP timestamp format option to avoid leap
seconds confusion and 2036 rollover events.
Best,
Ron
On Thu, Mar 3, 2011 at 8:26 PM, <[email protected]
<mailto:[email protected]>> wrote:
My feeling is 1588 is the right answer in the long run since it is
already
coupled to the hardware and widely deployed in networks using the
"packet
clock derived time" in precise time and frequency delivery.
Pat
"Shahram Davari"
<davari@broadcom.
com>
To
Sent by: "[email protected]
<mailto:[email protected]>"
tictoc-bounces@ie <[email protected]
<mailto:[email protected]>>,
tf.org <http://tf.org> "[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
cc
"[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
03/03/2011 10:05
Subject
AM Re: [TICTOC]
draft-ietf-mpls-loss-delay
Timestamp
Hi Stewart,
Accurate delay measurement requires the Timestamp to be done in
HW. It is
true that most routers support NTP today, but the majority of
those are
really maintained in Software and AFAIK most HW based timestamps
implementations are 1588 based and really the industry is shifting
toward
1588 and SyncE for network synchronization. So I support 1588 as
being the
default.
Thanks,
Shahram
From: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>]
On Behalf Of
Stewart Bryant
Sent: Thursday, March 03, 2011 8:07 AM
To: [email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>
Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp
We have received a LC comment on draft-ietf-mpls-loss-delay
concerning the
default timestamp.
In the first version of the draft we proposed NTP, but following
initial
comments from the MPLS-TP community we changed to IEEE1588. This
requirement for IEEE1588 can be traced back to the choice of using
IEEE1588
in Y.1731.
We have now received a LC request to change the default back to NTP.
NTP is the "natural" choice for an IETF protocol. NTP is specified
in IETF
and is used in other MPLS protocols such as LSP ping. It is
implemented on
almost every host and every router. However in general the
implementations
provides a relatively low precision timestamp, and the NTP time
distribution infrastructure operates on a best effort basis. Thus
even a
good client implementation would normally have a relatively low
quality
path to the server, which would result in a low quality of
timestamp. NTP
could be made to work to higher accuracy, but defacto upgrading
NTP and
providing high quality NTP paths to the time servers is not
getting much
attention. Computing timestamp differences is easier with NTP.
On the other hand IEEE1588 has defacto become the two way time tranfer
protocol for precision applications. IEEE1588 only provides high
quality
time in well engineered networks with some form of hop by hop
assistance.
It is not widely implemented other than in equipment targeted to
specific
markets, although one of those markets is in mobile backhaul
applications
where we expect to see significant initial deployment of MPLS-TP.
Computing
timestamp differences is harder with IEEE1588
The loss-delay work is targeting to be able to do one way packet delay
measurement, so it does need a higher quality of timestamp than is
required
in general purpose network instrumentation.
Converting from IEEE1588 to NTP is not trivial, since they use
different
epochs, and different representations of sub-second time. In a
"traditional" NTP implementation the time error due to on the fly
conversion is likely to be small compared to the time error in the
time
synchronization system, but an IEEE1588 system would need hardware
conversion to maintain the accuracy for an NTP timestamp.
So the question arises, should we make IEEE1588 or NTP the default for
draft-ietf-mpls-loss-delay. Much as I would like to suggest that
we should
go back to NTP for consistency with other IETF protocols, I have
difficulty
reconciling this with the situation in network deployments and
thus suggest
that we continue to use IEEE1588.
What is the opinion of the working group?
Stewart (speaking as a draft editor)
_______________________________________________
TICTOC mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
mpls mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mpls
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
