Hi Yaakov, But I thought NTP doesn't require TC capability (Correction Field Update) at every hop. If so then why do we need such capability for NTP? If what you have in mind is for faster synchronization without waiting for local clock convergence then that is not the way NTP is implemented today.
Thx Shahram -----Original Message----- From: Yaakov Stein [mailto:[email protected]] Sent: Wednesday, February 02, 2011 1:53 AM To: Bhatia, Manav (Manav); Shahram Davari; [email protected]; [email protected] Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Manav and Shahram The whole idea of my proposal is that it can add TC capability to NTP without opening up the protocol at the IP level. This can not be done using the present proposal. Furthermore, think of a one-way delay measurement OAM packet. Instead of having to first have a local clock converge at the remote site, we can just send a packet with the proposed MPLS-level CF, and read the delay (assuming that the packet handling time is much longer than flight time - otherwise we still need some bidirectional processing). So I disagree that there is no advantage to the generic mechanism. Y(J)S -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bhatia, Manav (Manav) Sent: Wednesday, February 02, 2011 02:27 To: Shahram Davari; [email protected]; [email protected] Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks I agree with Shahram. There is not much that needs to be done for NTP in case we would like to extend this mechanism for NTP as well. NTP is almost like a BC where the LSP will terminate. There is no TC happening in NTP. Thus the only thing that needs to be done for NTP is to map an LSP/PW with NTP so that it can be adequately processed by the end nodes. Once the end nodes identify a labelled packet with NTP they should HW timestamp it asap and pass it on to CPU for further processing. Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Shahram Davari > Sent: Wednesday, February 02, 2011 1.08 AM > To: [email protected]; [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > Hi Stewart, > > I think with our mechanism you can support NTP as well. NTP > does not need TC processing and only needs Transmit and > Receive timestamps, which are local to the LSP ingress and > Egress nodes. The UDP port number for NTP is different from > PTP and therefore no TC processing will be applied to NTP packets. > > So our mechanism could be generalized to NTP a well. The > co-routed symmetry is needed for both NTP and PTP. The PTP > label is needed for the LSP egress node (for both NTP and > PTP) to sample the timestamp. > > Thx > Shahram > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Stewart Bryant > Sent: Tuesday, February 01, 2011 9:48 AM > To: [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > On 01/02/2011 15:52, Bhatia, Manav (Manav) wrote: > > Hi Yakov, > > > > And I still stand by what I said earlier that I don't think > NTP needs to be included here. I'd rather that we keep NTP > and 1588 separate and only merge them if we think its > absolutely essential that a common uniform solution is > developed for the two protocols. > Manav > > It is the normal practice of the IETF to design a single common > mechanism for a problem, so you need to justify why we need > to develop a > special purpose protocol rather than develop for instance a time > correction protocol. > > It would be better in my view to design a correction > mechanism that sits > as preamble to an opaque payload and then fix up the timing packet in > the Timing equivalent of a PW NSP. That would work for any > protocol that > needed time of flight correction. > > Stewart > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
