Re: [TICTOC] PTP Enterprise Profile draft

["Laurent Montini (lmontini)" <[e-mail]>]

Hi Doug, Heiko,

Few questions and some comments and proposal:


	3. Technical Terms

PTP port is only mention in boundary clock definition.
To have consistent definition and text, the definition of boundary clock
should use master clock and slave clock terms. For instance the definition
may state that when BC has one PTP port in slave state, BC would then run
as slave clock and as master clock (if no ptp port in slave state, the BC
would be a grandmaster with multiple ptp ports in master).
Otherwise, the relationship between ptp port state, defined by BMCA, and
ptp master/slave clock shall be clarified. "ptp port" is not utilized
elsewhere in the draft.

"IEEE 1588: The timing and synchronization standard which defines PTP."
This can lead to think that IEEE 1588 = PTP
IEEE 1588 specifies PTP and "The node, system, and communication
properties necessary to support PTP."
E.g., all the clocks, BMCA for hierachy setting and clock selection,
transport modesŠ


Editorial: in BMCA definition, remove the return and line space.
I assume it should be:
     Best Master Clock Algorithm: A method for determining which of
     several PTP Master Clocks have priority to become the acting
     Grandmaster, based on the properties each Master Capable Clock
     sends in its Announce Message.
Editorial: Column after "Transparent Clock"

Editorial: Unicast Discovery: Announce with capital A


     5. Network Technology
"If a network contains both IPv4 and IPv6, then they SHALL be treated as
separate PTP systems."

This says that every node would have to either run IPv4 or IPv6 from GM to
slaves. This forces the whole PTP system (domain) to be uniquely design
with either IPv4 or IPv6.
I would contemplate the profile to allow both IPv4 and IPv6 in same PTP
system using BC and optionally TC as translation devices.
>From IEEE1588-2008 definition
"3.1.45 translation device: A boundary clock or, in some cases, a
transparent clock that translates the
protocol messages between regions implementing different transport and
messaging protocols".
This would give flexibility to engineer PTP network when the enterprise
network has to manage the transition and coexistence of IPv4 and IPv6.
Some transition techniques can be detrimental to PTP transmission.
The text could specify that a PTP communication path shall use either IPv4
or IPv6. 




     6. Time Transfer and Delay Measurement
It might be useful to specify that slave clock (or port) SHALL support
reception for one-step and two-step master clocks (i.e. shall support
Follow_up).

     6.1. Unicast Mode
This section is discussing a mixed multicast/unicast mode. It may be
useful for preventing misinterpretation to mention "Unicast mode" in this
profile is actually a mixed mode (see G.8265.1 Appendix I).

It is specified later that the profile prohibites Unicast Discovery and
thus Unicast Message Negotiation.
It would be worth stating such restriction in this section.

Unicast & Multicast Modes
"All Sync messages MUST be sent as multicast messages to the PTP event
message multicast address."
I assume Announce messages MUST use also multicast mode. It may be worth
mentioning it.

Note I assume you refer to the UDP port number to be PTP event or PTP
general.
The text might suggest this refers to the multicast group address (see
further comment below).
I would rephrase to clarify this is the UDP port number, e.g.:
"All Sync messages MUST be sent as multicast PTP event (UDP port number
319) messages."



Could you explain why Follow_up messages SHALL be sent as PTP event
message?
Follow_up is a PTP General message as Announce.

As pointed above, the draft does not mention what multicast address SHALL
be used.
When writing "PTP event message multicast address", are you refering to
the PTP-primary multicast group address allocated by IANA for PTP? The
draft does not mention the Annex D and Annex E.
I assume that PTP-primary multicast group addresses for IPv4 and IPv6
SHALL be the default addresses.

However, because the draft allows, in the section 5, that network devices
MAY not support PTP (neither BC nor TC), it can be useful in large
enterprise networks to have some flexibility in the multicast group
addressing.
Some group addresses such Source Specific Multicast group for IPv4 and
IPv6 or the as Administratively scoped IP Multicast group for IPv4 have
some administrative benefits for multicast routing.




The profile does not allow unicast negotiation: the ptp communication path
setup shall de clarified.
I assume that the slaves will learn the master unicast address from the
from source address in multicast PTP packets.
Alternatively, if the slave is configured with an Alternate Master
List/Table, it will know the unicast addresses of the master clocks.
In both cases if multiple masters exist, I assume the slave would transmit
Delay_Req only to the active (selected by BMCA) master clock.
It would be worth clarifying this item.



"Hybrid mode" is specified as default mode for this profile.
I understand a default mode as a mandatory mode that device compliant to
this profile must support.
At least the "hybrid mode" is mandatory for master clocks.
Moreover, whatever the modes, they all have common master-slave
communication behavior. Unicast and Multicast mode being applied only for
Delay messages, those can be subsections.


Proposed new text:
******************
6. Time Transfer and Delay Measurement

        Master clocks and Transparent clocks MAY be either one-step clocks
        or two-step clocks. Slave clocks MUST support both behaviors. The
End to End Delay Measurement Method MUST be used.

All Sync messages MUST be sent as multicast PTP event messages. Two
step clocks SHALL send Follow-up messages as multicast PTP general
[or event -see previous comment] messages.

All Announce messages MUST be sent as multicast PTP general messages.


Delay Request Messages MAY be sent as either multicast or unicast
PTP event messages. Master clocks SHALL respond to multicast Delay
Request messages with multicast Delay Response PTP general messages.
Master clocks SHALL respond to unicast Delay Request PTP event messages
with unicast Delay Response PTP general messages.

6.1. Unicast Mode

All Delay Request PTP event messages and Delay Response PTP general
messages MUST be sent as unicast messages. Unicast Discovery and Unicast
Message Negotiation options MUST NOT be utilized.

[path communication setup shall be defined - see options in comment above]


6.2. Multicast Mode

All Delay Request PTP event messages and Delay Response general messages
MUST be sent as multicast messages.
*****************


I believe the three modes aims defining the behavior of a slave for delay
message transmission.
By defining these modes, a master port can force attached slave ports to
use either unicast, multicast or any of them (i.e. last mode leaves the
choice of unicast or mulitcast delay messages to the slave).


If this understanding is correct, it could be defined in separate sections
or in sections 9 & 10. See later.

Moreover, "hybrid mode" looks more an "open mode" as only unicast and
multicast modes are actually available and "hybrid/open" mode allows any
of them to be used.


     8. Timing Domains
As per discussion above, this section could be moved down, i.e. after
introducing the different options.

The section does not explain the reason for having distinct domain numbers.
>From my understanding, one option is that the transmission mode would be
defined by the gransmaster and MUST be used for all the PTP domain (or
system). Is that correct understanding?
If so, why defining distinct PTP domain numbers for unicast and multicast?



         
However the transmission mode could be defined per master port and not for
the entire system/domain. Some links, such as WAN, might benefit of
unicast transmission mode when multicast might be prefered for LAN. That
is, transmission mode can be defined per PTP communication path (between
master and slave ports) using again the translation device function.
Note that PTP domain number shall be consistent throughout the
system/domain (i.e. from GM to slave sync'd to this GM) whatever the
transmission mode.



    9. Requirements for Master Clocks

It is not specified if the TLV is sent by the grandmaster and forwarded
unmodified downwards (to slave ports).
If sent by master clocks (and not gransmaster clocks), it could mean that
each master clock can define the mode it will use (per interface), thus
overwriting the TLV for downwards distribution.
I would thus consider that the mode is defined per communication path
because some segments of the network might be easier to manage with
multicast when others would benefit of unicast.


The behavior of the transparent clock wrt the TLV and the support of the
transmission mode, i.e. multicast or unicast Delay messages, should be
specified.

As proposed previously, the distinct modes for transmission of Delay
messages, can be defined in that section.
Proposed text:
*************
The master clocks/ports SHALL tell what transmission mode the
slave ports SHALL or MAY use for Delay messages.
Three options are available: the unicast mode, the multicast
mode or the open mode. Unicast mode requires the Delay messages
to use unicast. Multicast mode requires the Delay messages to
use multicast. With open option the master clock/port allows
the slave to use either unicast or multicast Delay Request
messages.
**************
Value 02hex = Open mode
**************


     10. Requirements for Slave Clocks

Proposed text (can be moved to 9):
**********
"If master clock/port annonce an Open mode, the slave MUST use only one
type of transmission. The master clock MUST respond with same mode.

**********



Regards,
Laurent



From:  Doug Arnold <[e-mail]>
Date:  Monday, February 25, 2013 10:52 PM
To:  "[e-mail]" <[e-mail]>
Subject:  [TICTOC] PTP Enterprise Profile draft


Here is a first cut at a draft of a PTP profile foe enterprise networks.
Any feedback/suggestions would be much appreciated.

 
I enclose both a MS Word version and a pure text version, since I used the
Joe Touch¹s template.
 
//Doug