Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

From: Yaakov Stein <[email-masked]>
Date: Tue, 1 Feb 2011 15:39:03 +0000

Hi all, 

Interesting how everyone is changing their minds so quickly ...

When I brought up the question of NTP I was told that NTP is not interesting / not possible
since the ONLY question here is TC.

I tried pushing the issue of prioritization, and hinted at the asymmetry issue
(but wanted to discuss with the RSVP-TE experts first to see that it could be done)
and was told that I needed to explain why there is anything at all to do
in this regards.

Well, let's assume that I have become convinced by your arguments and really want TC.
Not just for 1588, but for the timing protocol that presently runs over the Internet.
In that case your proposal falls somewhat short, but can be easily retrofitted
to accomplish everything for both timing protocols.
If, in addition, I can get time correction for other protocols,
and measurement of one-way delay for PM, 
that sounds like a major advantage from my point of view.

I fully understand the advantage of re-using existing hardware,
and am not suggesting that we not advance the present proposal.
However, I think the generic mechanism can easily be implemented
based on existing building blocks, and should be investigated as well.

Y(J)S

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Tuesday, February 01, 2011 02:10
To: Yaakov Stein; Jack Kohn
Cc: [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

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-masked] 
> [mailto:[email-masked]] On Behalf Of Yaakov Stein
> Sent: Monday, January 31, 2011 10.50 PM
> To: Jack Kohn
> Cc: [email-masked]
> 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-masked]] 
> Sent: Monday, January 31, 2011 15:26
> To: Yaakov Stein
> Cc: [email-masked]
> 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-masked]
> > https://www.ietf.org/mailman/listinfo/tictoc
> >
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 1 Feb 2011 21:22:13 +0530

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. 

I responded to a comment on the list that the method described in this document cannot be applied to NTP. I think it can with a few tweaks here and there as you also suggest in your email (and had alluded to in the call last time).

Cheers, Manav

> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: Tuesday, February 01, 2011 9.09 PM
> To: Bhatia, Manav (Manav); Jack Kohn; Shahram Davari
> Cc: [email-masked]
> 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.
>

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 1 Feb 2011 16:01:40 +0000

Manav

Then we basically agree.

Y(J)S

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Tuesday, February 01, 2011 17:52
To: Yaakov Stein; Jack Kohn; Shahram Davari
Cc: [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Yakov,

Cheers, Manav

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Feb 2011 17:48:23 +0000

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

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 1 Feb 2011 11:37:30 -0800

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-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, February 01, 2011 9:48 AM
To: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Manav

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Feb 2011 22:22:18 +0000

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

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 1 Feb 2011 14:25:45 -0800

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-masked]] 
Sent: Tuesday, February 01, 2011 2:22 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Stewart

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 2 Feb 2011 05:56:59 +0530

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

> [mailto:[email-masked]] On Behalf Of Shahram Davari
> Sent: Wednesday, February 02, 2011 1.08 AM
> To: [email-masked]; [email-masked]
> 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
> 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> > 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
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 2 Feb 2011 06:01:10 +0530

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

> Sent: Wednesday, February 02, 2011 3.56 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> 
> >> 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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 2 Feb 2011 07:44:39 +0530

BTW, this will only work in the GMPLS environments. We still dont have a solution to asymmetric paths in the regular MPLS, so the problem still stands.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Monday, January 31, 2011 7.38 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Lizhong,

As a result of this discussion the RTGWG will add another requirement where the solution should be able to indicate to a composite link that both the directions of a bidirectional LSP must be bound to the same component link.

This is indeed what we want for 1588. We will also include a pointer to this in the next revision.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 31, 2011 6.10 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Manav,
I see the discussion at RTGWG, it is good.
Share within TICTOC: http://www.ietf.org/mail-archive/web/rtgwg/current/msg03181.html

Thanks
Lizhong

"Bhatia, Manav (Manav)" <[email-masked]> wrote on 2011-01-28 08:09:50:

> Lizhong,
>
> > [Lizhong] I mean the LAG between two end-points,
> > not MC-LAG. E.g, one LAG interface with physical link
> > A & B between two end-points, it is possible that the forward
> > path will go through A, and backward path will go through B,
> > then the physical path is not symmetric. If I understand correctly,
> > you just assume the transport delay on link A & B are the
>
> On an ordinary lag, unless it's a MC-LAG this can be assumed to be
> more or less the same.
>
> > same, but this is not always true, especially for the composite
> > link defined in RTGWG (draft-ietf-rtgwg-cl-requirement).
>
> I quickly glanced through this draft and these can imo be easily
> avoided by defining a new link type - Composite link, in the link
> type sub-TLV of Link TLV in OSPF [RFC3630]. Such links MUST be
> avoided for setting up the PTP LSPs. Similarly the extended IS
> reachability TLV could be extended for IS-IS to avoid composite links.
>
> One could also use coloring to avoid these links, but this would
> entail manual configuration which may not be desirable.
>
> Cheers, Manav
>

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 2 Feb 2011 09:53:27 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Wednesday, February 02, 2011 02:27
To: Shahram Davari; [email-masked]; [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Cheers, Manav

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 2 Feb 2011 10:02:54 -0800

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-masked]] 
Sent: Wednesday, February 02, 2011 1:53 AM
To: Bhatia, Manav (Manav); Shahram Davari; [email-masked]; [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Manav and Shahram

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Wednesday, February 02, 2011 02:27
To: Shahram Davari; [email-masked]; [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Cheers, Manav

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 02 Feb 2011 18:19:37 +0000

Shahram

I think that it would be useful to retrofit TC to NTP to give it greater 
accuracy.

There are far more NTP clients out  there than there 1588 clients, a 
situation that is likely to continue for the foreseeable future.

Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 2 Feb 2011 10:28:11 -0800

Hi Stewart,

That is a bigger issue which is outside the scope of this draft. We shouldn't add capabilities to this draft for an NTP function that doesn't exist yet.

Besides even assuming NTP is retrofitted with CF capability you still can use our draft to update its CF since existing HW can easily parse an IP/UDP packet. But adding new fields to CW is something that requires extensive HW change.

Thanks,
Shahram

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2011 10:20 AM
To: Shahram Davari
Cc: Yaakov Stein; Bhatia, Manav (Manav); [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Shahram

Stewart

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 3 Feb 2011 05:01:22 +0530

Stewart,

Shouldn't the work on retrofitting TC to NTP happen in the NTP WG? This sounds like NTPv4++ to me.

Also as Shahram has earlier said, if we do decide to extend NTP for TC, then all that needs to change in the current draft is that the RSVP object will now point to the start of the NTP header instead of the PTP header. Most of the things defined in this draft should work for NTP as well.

Cheers, Manav

> Sent: Wednesday, February 02, 2011 11.50 PM
> To: Shahram Davari
> > 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
> 
>

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 4 Feb 2011 10:32:59 +0000

Manav and Shahram

What I proposed is exactly NOT updating NTP,
but making a generic mechanism that MAY be used for ANY protocol that cares about time.

For NTP, all one needs to do is to give the present code corrected arrival times,
that will automatically reduce PDV and thus increase accuracy.

For RFC-868 the ToD is delivered with much reduced delay error.

Where change is needed is for one-way delay measurement (e.g., OWAMP).

Regarding updating NTP to a new generation,
that is precisely one of TICTOC's charter items
(and indeed in some people's eyes the only thing we should be doing).
TICTOC's purpose is to find improvements to both NTP and 1588,
certainly not only 1588 (which is an IEEE protocol, not an IETF one).

Y(J)S

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Thursday, February 03, 2011 01:31
To: [email-masked]; Shahram Davari
Cc: Yaakov Stein; [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Stewart,

Cheers, Manav