headers
Bhatia, Manav (Manav | 1 Feb 2011 01:09
Favicon

Re: 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: tictoc-bounces <at> ietf.org 
> [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Yaakov Stein
> Sent: Monday, January 31, 2011 10.50 PM
> To: Jack Kohn
(Continue reading)

Permalink | Reply | 15 comments |
headers
Yaakov Stein | 1 Feb 2011 16:39
Favicon

Re: Transporting PTP messages (1588) over MPLS Networks

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:manav.bhatia <at> alcatel-lucent.com] 
Sent: Tuesday, February 01, 2011 02:10
(Continue reading)

Permalink | Reply | 14 comments |
headers
Bhatia, Manav (Manav | 1 Feb 2011 16:52
Favicon

Re: Transporting PTP messages (1588) over MPLS Networks

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

> -----Original Message-----
> From: Yaakov Stein [mailto:yaakov_s <at> rad.com] 
> Sent: Tuesday, February 01, 2011 9.09 PM
> To: Bhatia, Manav (Manav); Jack Kohn; Shahram Davari
> Cc: tictoc <at> ietf.org
> Subject: RE: [TICTOC] Transporting PTP messages (1588) over 
> MPLS Networks
> 
> 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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Yaakov Stein | 1 Feb 2011 17:01
Favicon

Re: Transporting PTP messages (1588) over MPLS Networks

Manav

Then we basically agree.

Y(J)S

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:manav.bhatia <at> alcatel-lucent.com] 
Sent: Tuesday, February 01, 2011 17:52
To: Yaakov Stein; Jack Kohn; Shahram Davari
Cc: tictoc <at> ietf.org
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

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

> -----Original Message-----
> From: Yaakov Stein [mailto:yaakov_s <at> rad.com] 
> Sent: Tuesday, February 01, 2011 9.09 PM
> To: Bhatia, Manav (Manav); Jack Kohn; Shahram Davari
> Cc: tictoc <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stewart Bryant | 1 Feb 2011 18:48
Picon
Favicon

Re: 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
Permalink | Reply | 11 comments |
headers
Shahram Davari | 1 Feb 2011 20:37
Favicon

Re: 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: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, February 01, 2011 9:48 AM
To: tictoc <at> ietf.org
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.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Stewart Bryant | 1 Feb 2011 23:22
Picon
Favicon

Re: 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: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Stewart Bryant
> Sent: Tuesday, February 01, 2011 9:48 AM
> To: tictoc <at> ietf.org
> Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks
>
> On 01/02/2011 15:52, Bhatia, Manav (Manav) wrote:
>> Hi Yakov,
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Shahram Davari | 1 Feb 2011 23:25
Favicon

Re: 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:stbryant <at> cisco.com] 
Sent: Tuesday, February 01, 2011 2:22 PM
To: Shahram Davari
Cc: tictoc <at> ietf.org
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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bhatia, Manav (Manav | 2 Feb 2011 01:26
Favicon

Re: 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: tictoc-bounces <at> ietf.org 
> [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Shahram Davari
> Sent: Wednesday, February 02, 2011 1.08 AM
> To: stbryant <at> cisco.com; tictoc <at> ietf.org
> 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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bhatia, Manav (Manav | 2 Feb 2011 01:31
Favicon

Re: Transporting PTP messages (1588) over MPLS Networks

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: tictoc-bounces <at> ietf.org 
> [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Shahram Davari
> Sent: Wednesday, February 02, 2011 3.56 AM
> To: stbryant <at> cisco.com
> Cc: tictoc <at> ietf.org
> 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-----
(Continue reading)

Permalink | Reply | 0 comments |

Gmane