Subject: [TICTOC] New draft: draft-shpiner-multi-path-synchronization

From: Tal Mizrahi <[email-masked]>
Date: Mon, 15 Oct 2012 17:41:02 +0200

Hi,

We have posted a new draft called "Multi-Path Time Synchronization".
This is an experimental draft that describes the usage of multiple concurrent paths between the master and slave in PTP and NTP.

http://tools.ietf.org/html/draft-shpiner-multi-path-synchronization

We will appreciate your feedbacks.

Thanks,
Tal.

---

From: "Meyer, Peter" <[email-masked]>
Date: Tue, 30 Oct 2012 18:40:48 -0400

Hi Tal et al,

Interesting.  Looks like a useful idea.  For the IEEE 1588 option, there
are a bunch of items that need some more thought as to how it would be
compliant or compatible with IEEE 1588-2008.  I didn't review the NTP
option.  I didn't comment on the Two-way MPPTP until I am better
understanding the One-way MPPTP option.

+ [SLAVEDIV] is not a publicly available document

+ Section 5 mandates using unicast, which would put the clock operation
as unicast negotiation for all message types.  I think there is
important distinction between unicast (not standard) and unicast
negotiation (standard), as contract negotiation uses the transport layer
(e.g. IP address) as the connection identifier, rather than the PTP
clock id.  This is perhaps something that should be fixed in the next
revision of IEEE 1588.

+ 5.1.1. One-Way MPPTP Synchronization Message Exchange

   The one-way MPPTP message exchange procedure is as follows.

   o Each one-way MPPTP clock has a fixed set of N IP addresses and N
corresponding clockIdentities . One of the IP addresses and
clockIdentity values are defined as the clock primary identity.

PGM> This makes N clocks in the domain per network element.  It is not
clear the determination of which one is the "primary".  There is no
clear indication how the N clocks talk to each other, if at all.

   o The BMC algorithm determines the master.

PGM> This BMCA runs per individual port per clock, so you now have N
best masters?  Could end up with N Grandmasters if the local network
element is the best in the network.

   o Every one-way MPPTP port that is not in the 'slave' state (i.e.,
either a master or a clock that has just joined the network)
periodically sends Announce messages using its primary identity.

PGM> Announce messages are negotiated by request of the remote entity.
It is unclear why the master would request Announce service from the
'slave' port, unless this other clock also is updated to follow a new
specification.

   o A one-way MPPTP clock that is in the 'slave' state periodically
transmits a set of N Announce messages using its N identities, while a
clock in the 'master' state only transmits Announce messages using its
primary identity.

PGM>  From previous bullet is unclear how the model has Announce per
port AND Announce per clock.  The Announce is negotiated by request of
the remote entity.

   o The master periodically sends unicast Sync messages from its
primary identity address to each of the slaves identified by the
sourcePortIdentity and IP address.

PGM> Sync messages are controlled by unicast negotiation contracts.
These are established exclusively by IP address in IEEE 1588-2008 (for
IP transport layer mapping Annex D & E).

   o The slave, upon receiving a Sync message, identifies its path
according to the destination IP address. In response to the Sync message
the slave sends a Delay_Req unicast message to the primary identity of
the master. This message is sent using the slave identity corresponding
to the path the Sync was received through.

PGM> There is no strict requirement to send a Delay_Req upon receiving a
Sync (there are a couple schemes allowed in IEEE 1588-2008).  With
uni-cast negotiation it may also be possible to run asymmetric rates for
Sync & Delay_Req.

   o The master, in response to a Delay_Req message from the slave,
responds with a Delay_Resp message using the IP address and
sourcePortIdentity from the Delay_Req message.

   o Upon receiving the Delay_Resp message, the slave identifies the
path using the destination IP address and the requestingPortIdentity.
The slave can then compute the corresponding path delay and the offset
from the master.

Regards,
Peter

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tal Mizrahi
Sent: October 15, 2012 11:41 AM
To: [email-masked]; [email-masked]
Subject: [TICTOC] New draft: draft-shpiner-multi-path-synchronization

Hi,

We have posted a new draft called "Multi-Path Time Synchronization".
This is an experimental draft that describes the usage of multiple
concurrent paths between the master and slave in PTP and NTP.

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 31 Oct 2012 13:40:34 +0200

Hi Peter,

Thanks for your comments.
You have made a few comments regarding the usage of Announce messages and unicast negotiation. This is good feedback, and in the next draft we will clarify these two aspects.

See some comments inline, marked with [TM].

Thanks.
Tal.

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2012 12:41 AM
To: Tal Mizrahi
Cc: [email-masked]; [email-masked]
Subject: RE: [TICTOC] New draft: draft-shpiner-multi-path-synchronization

Hi Tal et al,

Interesting.  Looks like a useful idea.  For the IEEE 1588 option, there are a bunch of items that need some more thought as to how it would be compliant or compatible with IEEE 1588-2008.  I didn't review the NTP option.  I didn't comment on the Two-way MPPTP until I am better understanding the One-way MPPTP option.

 [TM] It is available from IEEE Xplore. If you do not have access please contact me offline.

+ Section 5 mandates using unicast, which would put the clock operation
as unicast negotiation for all message types.  I think there is important distinction between unicast (not standard) and unicast negotiation (standard), as contract negotiation uses the transport layer (e.g. IP address) as the connection identifier, rather than the PTP clock id.  This is perhaps something that should be fixed in the next revision of IEEE 1588.

 [TM] We probably need to add some details about the negotiation. But anyway, the fact that the IP address is used as the identifier does not conflict with the assumption in this subsection, which is that each clockIdentity uses a different IP address.

   o Each one-way MPPTP clock has a fixed set of N IP addresses and N corresponding clockIdentities . One of the IP addresses and clockIdentity values are defined as the clock primary identity.

PGM> This makes N clocks in the domain per network element.  It is not
clear the determination of which one is the "primary".  There is no clear indication how the N clocks talk to each other, if at all.

 [TM] Each clock arbitrarily chooses one of its identities as the "primary" one. The "primary" identity is the one that takes part in the BMCA and may become a master. If the BMCA determines that the "primary" identity is a master, then only the "primary" identity is active, while the other identities do not send/receive any PTP messages. 
We will clarify this in the next draft.

PGM> This BMCA runs per individual port per clock, so you now have N
best masters?  Could end up with N Grandmasters if the local network element is the best in the network.

 [TM] Only the primary clock takes part in the BMCA, which prevents us from getting N grandmasters in this case. Again, we will clarify this.

   o Every one-way MPPTP port that is not in the 'slave' state (i.e., either a master or a clock that has just joined the network) periodically sends Announce messages using its primary identity.

PGM> Announce messages are negotiated by request of the remote entity.
It is unclear why the master would request Announce service from the 'slave' port, unless this other clock also is updated to follow a new specification.

   o A one-way MPPTP clock that is in the 'slave' state periodically transmits a set of N Announce messages using its N identities, while a clock in the 'master' state only transmits Announce messages using its primary identity.

PGM>  From previous bullet is unclear how the model has Announce per
port AND Announce per clock.  The Announce is negotiated by request of the remote entity.

   o The master periodically sends unicast Sync messages from its primary identity address to each of the slaves identified by the sourcePortIdentity and IP address.

PGM> Sync messages are controlled by unicast negotiation contracts.
These are established exclusively by IP address in IEEE 1588-2008 (for IP transport layer mapping Annex D & E).

   o The slave, upon receiving a Sync message, identifies its path according to the destination IP address. In response to the Sync message the slave sends a Delay_Req unicast message to the primary identity of the master. This message is sent using the slave identity corresponding to the path the Sync was received through.

PGM> There is no strict requirement to send a Delay_Req upon receiving a
Sync (there are a couple schemes allowed in IEEE 1588-2008).  With uni-cast negotiation it may also be possible to run asymmetric rates for Sync & Delay_Req.

 [TM] Right, we are not implying that it is mandatory to send a Delay_Req for each Sync, so we will rephrase this.

   o The master, in response to a Delay_Req message from the slave, responds with a Delay_Resp message using the IP address and sourcePortIdentity from the Delay_Req message.

   o Upon receiving the Delay_Resp message, the slave identifies the path using the destination IP address and the requestingPortIdentity.
The slave can then compute the corresponding path delay and the offset from the master.

Regards,
Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: October 15, 2012 11:41 AM
To: [email-masked]; [email-masked]
Subject: [TICTOC] New draft: draft-shpiner-multi-path-synchronization

Hi,

Thanks,
Tal.