The draft clearly says the following on the offset that's sent in RSVP: The OFFSET to the start of the PTP message header MAY also be signaled. Implementations can trivially locate the correctionField (CF) location given this information.
When used for NTP this will be set to 0. Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Shahram Davari > Sent: Wednesday, February 02, 2011 3.56 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > 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 > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
