Hi Yaakov, I am not sure if I understand why you think that the method described in this draft will not work for NTP? I agree that we have been concentrating on 1588, but that's ok for a draft that's called "Transporting PTP messages (1588) over MPLS Networks". We would require some very minimal changes to also accommodate NTP.
The draft states that a subset of PTP messages MUST be transported over some dedicated LSPs, lets call them timing LSPs for now. When setting up the RSVP tunnel we had also given a pointer to the start of the packet, thus it is trivial for implementations to note whether the incoming packet is 1588 or some other. If its 1588 event messages then they may want to compensate for residence time by updating the PTP packet Correction Field. At the very least such packets should be given some sort of priority over the others. Now this draft can be easily extended to carry NTP as well. All we need to say is that NTP packets MUST be transported over the timing LSPs. We will need to change section 13 where we have described routing extensions to now indicate the protocol (1588 or NTP) that the router supports. Additionally, it can also indicate that if its 1588, then is it capable of updating the CF. Similarly, we may need some minor changes in the RSVP section as well. The section on ECMP and QoS will remain as is without any changes. There can be a subsection for 1588 where we discuss the UDP checksum, etc. So I don't see why you think that this draft precludes the possibility of supporting NTP. Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Yaakov Stein > Sent: Monday, January 31, 2011 10.50 PM > To: Jack Kohn > Cc: [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > Jack > > There was a long discussion at the conference call and on the list, > with the draft authors and others maintaining that this method > is not applicable to NTP (mainly because its sole purpose is > to identify > LSRs that can perform TC correction to 1588 packets). > > By label range I mean the method used to identify the timing packets > in transit, whatever that method is. > > Y(J)S > > -----Original Message----- > From: Jack Kohn [mailto:[email protected]] > Sent: Monday, January 31, 2011 15:26 > To: Yaakov Stein > Cc: [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > Yakov, > > > I am thus led to reiterate my proposal for completely > generic MPLS mechanism for TC, > > a method that eliminates all the FCS and UDP checksum > problems that we have recently discussed. > > > > We need only to define a new PW type with an extended > control word that carries a CF. > > The payload could be anything - NTP, 1588, RFC-868, one-way > delay OAM, etc. > > We can use the label-range idea from the present draft, and > similar routing extensions > > What label range are you referring to? AFAIK there isnt any label > range defined in this document. The label that 1588 uses is signalled > by RSVP to all the other nodes. > > Also, what prevents the same mechanism to be used for NTP? If its NTP > that we are supporting then one does not need to provide the offset in > the RSVP object. The routing extensions remain the same and it NTP > also works. Thus the mechanism defined in this draft will work for NTP > as well. > > Jack > > > to signal the TC capability. > > > > Y(J)S > > > > > > > > _______________________________________________ > > 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
