Hi Stewart, For NTP there is no need to signal the offset since there is no CF update. And to be honest signaling the offset for PTP is not mandatory either, it just simplifies the HW parsing. There is also no need to signal the NTP since it can be derived from UDP port number.
Regards, Shahram -----Original Message----- From: Stewart Bryant [mailto:[email protected]] Sent: Tuesday, February 01, 2011 2:22 PM To: Shahram Davari Cc: [email protected] Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Well, you need to signal protocol type as well as offset which complicates the P nodes because of the different formats, whereas if you just have the correction field immediately after the BoS followed by the opaque payload, the P nodes can use a canonical time format and the correction can be applied in the PEs. Stewart On 01/02/2011 19:37, Shahram Davari wrote: > 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 > > > -- 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
