In message <a3c5df08d38b6049839a6f553b331c76d6fbb66...@ilptmail02.ecitele.com>
Alexander Vainshtein writes:
>
> Curtis, and all,
>
> To the best of my understanding, this is not about accuracy of
> synchronization using NTP or PTP. It is about the default timestamp
> format in the Delay Measurement (DM) messages for MPLS.
>
> Whatever accuracy can be achieved with one of these, the timestamp
> format is probably the least significant factor affecting the result.
For very high timestamp accuracy, the timestamp must be generated in
hardware. Perhaps the answer is send either format (maximize the
supported hardware) and accept both.
On the receive side, the locally generated time stamp can be converted
or the sent timestamp can be converted to achieve a common format.
It is the transmit timestamp that is hard to get into a format that
the hardware does not support.
> I have already stated on this list that, IMHO, the question itself is
> moot, because the DM can operate with disparate timestamp formats at
> two ends: actual format is specified in the message, and there is no
> need to do conversion in HW or in hard real time. What's more, 2-way
> DM does not even require conversion from one timestamp format to
> another, just ability to compute differences between two timestamps in
> the same format both for NTP and PTP formats.
It seems that the timestamp fields are nearly identical.
IEEE-1588-2008 section 5,2,3 contains:
struct Timestamp {
UInteger48 secondsField;
UInteger32 nanosecondsFeild;
};
Hopefully IEEE will see this excerpt as an acceptable "fair use".
This is very similar to the unix/bsd/linux timespec.
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* and nanoseconds */
};
The NTP 64 bit timestamp is also quite similar (RFC5905).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Timestamp Format
Briefly (from RFC5905) "It includes a 32-bit unsigned seconds field
spanning 136 years and a 32-bit fraction field resolving 232
picoseconds." The resolution of NTP 64 bit timestamp is slightly
better by about a factor of four.
The draft-ietf-mpls-loss-delay-01 draft chops off the top 16 bits and
therefore is really using unix/bsd/linux timespec format.
The conversion for PTP to timespec is tacking on or removing 16 bits
of leading zeros. That conversion will work for the next 90+ years,
which gives us a lot of time to decide how to extend time_t and
timespec and all the things that go with it, however NTP has this
covered in the 128 bit format when we go beyond era 0.
Is there an endian-ness issue that I'm missing? In any case, this is
acheivable as long as we specify "send either" and "accept both".
Perhaps the expected lifetime of the solar system would be an adequate
target, but 2106 may be OK for now so NTP 64 bit format is OK. :-)
OTOH, NTP also supports a 32 bit stamp:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again from RFC5905 "The 32-bit short format is used in delay and
dispersion header fields where the full resolution and range of the
other formats are not justified. It includes a 16-bit unsigned
seconds field and a 16-bit fraction field."
1 second / 65536 is less than 20 usec. This should be fine in delay
measurements. It is less than 4km worth of fiber if I've done the
math right. Otherwise we stick with the 64 bit format only.
I should also point out that 20 usec accuracy may be within the range
acheivable in software, or at least packet processor microcode.
As spcified in draft-ietf-mpls-loss-delay-01 the 32 bit timestamp
would be padded out to 64 bits, so there is no motivation to use it.
> In addition, the points in the data path where the timestamps are
> captured by a HW assist for the needs of a given protocol do not
> necessarily match the points where these timestamps should be taken
> for the purpose of DM. While it is probably possible to live with DM
> that ignores the time a packet is queued for transmission in the
> originating LSR, the results could look fishy, especially if the
> objective is to measure PDV and not delay per se. In other words, a
> timestamping HW assist that is optimal from the point of view of PTP
> "as close to actual ingress/egress as possible"), may be not very
> effective for DM (and, of course, vice versa).
We have been specifying hardware that allows the PTP and NTP 64 bit
and 32 bit time stamp formats to be placed at an arbitrary byte
location. Packets from CPU to hardware have an internal header that
gets stripped before going out and one thing that can go in that
header is an indication of time stamp format and where to put it (byte
offset). Final modifications for NTP, PTP, LM, DM, happen there.
I am aware that some "merchant silicon" has some built in assumptions
about how these timestamps will be used and may only be able to
support hardware asssisted time synchronization using PTP over
Ethernet. That does not mean we should limit our specs in IETF to use
PTP formats only.
> My 2c,
> Sasha
Therefore I support "send any", and "accept all" as the MUST. This
guarentees interoperability and removes any need to negociate formats.
As long as hardware can record stamps, software can convert them and
produce a delay value.
Thanks,
Curtis
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Curtis Villamizar
> > Sent: Tuesday, March 08, 2011 1:20 AM
> > To: Mallette, Edwin
> > Cc: [email protected]; Zhao, Peng (NSN - CN/Shanghai); Pietilainen, Antti
> > (NSN - FI/Espoo); [email protected]; [email protected]
> > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp
> >
> >
> > In message <c99a56f5.7dd8%[email protected]>
> > "Mallette, Edwin" writes:
> > >
> > > I concur with the points made by Nurit and Ben. In addition there is
> > > the asymmetric delay problems (for a given link) that lots of work
> > has
> > > gone into to solve with 1588 - 1588 Transparent Clock / 1588
> > residency
> > > time compensation. To the best of my knowledge this is not being
> > > addressed for NTP.
> > >
> > > Thus +1 for the default of IEEE1588.
> > >
> > > Ed
> >
> >
> > NTP has always, probably from day one but at least going back to the
> > early 1990s (AFAIK), compensated for asymetric delay.
> >
> > With hardware assist, NTP deployed over a link is every bit as
> > accurate as PTP deployed over a link with hardware assist. It is
> > probably more accurate due to the jitter compensation used by NTP and
> > omited by PTP. Some hardware doesn't quite get all the jitter out.
> >
> > Admitedly, NTP is more complex due to the compensation that is
> > included in NTP and not in PTP.
> >
> > OTOH if there is something that favors PTP, then we should approach
> > the TICTOC WG and pass along that requirements. For example, a two
> > step transmit, allowing the transmit timestamp on a given packet to be
> > sent with the next packet, may simplify hardware. If so, we ask
> > TICTOC to support that in NTP.
> >
> > I support making the default NTP. This is the IETF and given a very
> > nearly equivalent IETF solution and an IEEE solution we should require
> > the IETF solution, make the IEEE solution optional, and if there are
> > any shortcomings to the IETF solution, address that in the appropriate
> > IETF WG.
> >
> > Curtis
> >
> >
> > > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
> > > <[email protected]<mailto:[email protected]>>
> > > Date: Fri, 4 Mar 2011 05:32:07 -0500
> > > To: "[email protected]<mailto:[email protected]>"
> > > <[email protected]<mailto:[email protected]>>,
> > > "[email protected]<mailto:[email protected]>"
> > > <[email protected]<mailto:[email protected]>>
> > > Cc: "Zhao, Peng (NSN - CN/Shanghai)"
> > > <[email protected]<mailto:[email protected]>>, "Pietilainen,
> > > Antti (NSN - FI/Espoo)"
> > > <[email protected]<mailto:[email protected]>>,
> > > "[email protected]<mailto:[email protected]>"
> > > <[email protected]<mailto:[email protected]>>
> > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp
> > >
> > > Stewart hi,
> > > The accuracy targets as described below are approaching a level where
> > > on-path support is needed.
> > > In this case the clear choice is IEEE 1588 because it specifies
> > > on-path support whereas NTP does not.
> > > Even without on-path support IEEE 1588 could be better if better
> > > accuracy is pursued by sending multiple timing packets per second per
> > > slave/client, because standard NTP clients send messages at a very
> > low
> > > rate for saving server resources.
> > > I support the default of IEEE1588!
> > > Best regards,
> > > Nurit
> > >
> > > From: [email protected]<mailto:[email protected]>
> > [mailto:[email protected]] On Behalf Of ext Stewart Bryant
> > > Sent: Thursday, March 03, 2011 6:07 PM
> > > To: [email protected]<mailto:[email protected]>
> > > Cc: [email protected]<mailto:[email protected]>
> > > Subject: [mpls] 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)
> >
> > _______________________________________________
> > mpls mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
