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 protected]] Sent: Wednesday, October 31, 2012 12:41 AM To: Tal Mizrahi Cc: [email protected]; [email protected] 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. + [SLAVEDIV] is not a publicly available document [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. + 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. [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. 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. [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 protected] [mailto:[email protected]] On Behalf Of Tal Mizrahi Sent: October 15, 2012 11:41 AM To: [email protected]; [email protected] 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. http://tools.ietf.org/html/draft-shpiner-multi-path-synchronization We will appreciate your feedbacks. Thanks, Tal. _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
