Subject: [TICTOC] PTP Enterprise Profile draft

From: Doug Arnold <[email-masked]>
Date: Mon, 25 Feb 2013 21:52:09 +0000

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

---

From: Karen O'Donoghue <[email-masked]>
Date: Mon, 25 Feb 2013 20:12:32 -0500

TICTOC working group members,

This document will be on the agenda for the upcoming meeting in Orlando. 
Because of incomplete guidance from me as working group co-chair, the 
document was not submitted correctly and will not be in the 
internet-drafts repository in time for the meeting. I will provide a 
link to the email including the document as part of the meeting agenda. 
Please review and come prepared to discuss the contents.

Regards,
Karen

On 2/25/13 4:52 PM, Doug Arnold wrote:
>
> Here is a first cut at a draft of a PTP profile foe enterprise 
> networks.  Any feedback/suggestions would be much appreciated.
>
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 26 Feb 2013 22:32:43 +0200

Hi Doug, Heiko,

I believe the draft is well written, and is valuable to the industry.
A few comments below.

Comments:

1.       Section 4: “The accuracy currently required can be as tight as 1 µs.”

a.       It doesn’t say ‘SHALL’ or ‘SHOULD’, but I suggest to clarify whether this accuracy number is brought as a requirement, or as an informational figure.

b.      I suggest to clarify exactly what 1us accuracy means from the 2 options below (unfortunately the two meanings below are used inconsistently :)

                                                               i.      The maximal difference between 2 clocks in the domain is 1us
or

                                                             ii.      All clocks are synchronized to the master by at most ±1 us.

2.       Section 6: “Master clocks and Transparent clocks MAY be either one-step clocks or two-step clocks.”
It is implied that you refer to BCs as well, but it is worth clarifying this explicitly.

3.       I am a bit confused about the usage this draft makes of the terms ‘Discovery’ (clause 17.5 in 1588) and ‘negotiation’ (clause 16.1 in 1588) – probably worth clarification.

a.       There is no explicit requirement to refrain from using unicast negotiation, but the requirement is implicitly stated in Section 6.1: “All Sync messages MUST be sent as multicast messages to the PTP event message multicast address.”

b.      Section 13 says: “the Enterprise profile will not interoperate with clocks operating in the Telecom Profile for Frequency Synchronization[G8265.1], because the Enterprise Profile forbids Unicast Discovery with message negotiation”.
I searched ITU-T G.8265.1, and did not find the word ‘discovery’, although unicast negotiation is indeed used.

c.       Section 3 should probably define ‘negotiation’ and explain the difference from ‘discovery’.

4.       General comment: you may want to discuss the fact that in IP networks Sync messages and Delay_Req messages exchanged between a master and a slave do not necessarily traverse the same physical path. Thus, wherever possible, the network should be traffic engineered so that the forward and reverse routes traverse the same physical path.

5.       General comment: You may want to discuss NAT scenarios. When a path between a master and a slave traverses address translations, it means that multiple clocks may appear to have the same IP address.
Thus, I believe this document should require clock to identify the peer clock based on its Clock Identity, and not based on its IP address. I think this issue is not discussed in detail in IEEE 1588, but is certainly relevant in enterprise networks.

6.       Question [I had a similar comment about the MPLS draft]: should we define the term “PTP port” in the context of this profile? For a router, a PTP port is a router interface, whereas for a switch it is a physical port. I wonder whether this is clear to the reader, or needs to be clarified.

Minor comments:

1.       s/Precise Time Protocol /Precision Time Protocol/

2.       s/The profile used/The profile uses/

3.       Semantic comment: In Section 3, definition of Best Master Clock Algorithm, it is implied that the algorithm elects the grandmaster. This is not necessarily accurate for BCs, so it is probably more accurate to state that BMCA elects a master.
The same issue applies to the second paragraph of section 1.

4.       Section 5: “If a network contains both IPv4 and IPv6, then they SHALL be treated as separate PTP systems.” – does that mean different domains? Please clarify.

5.       Section 5: I suggest to clarify that PTP-over-IPv4 and PTP-over-IPv6 SHALL comply to Annex D and Annex E of 1588, respectively.

6.       Section 10: using multiple masters mitigates not only a rouge master attack, but also man-in-the-middle attacks such as delay attacks, packet interception / manipulation attacks. Assuming the path to each master is different, a man-in-the-middle attacker is limited only to the path she attacks.

7.       Section 14 Security Considerations:
There should be a short discussion about the Rouge master attack (Section 10), and a cross reference to Section 10.

8.       Section 15 IANA Considerations: this section should probably include the <Organization SubType> values and < Delay Request/Response Mode> values from section 9, since these are specific values to the Enterprise profile, and are defined by the IETF.

Thanks,
Tal.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Arnold
Sent: Monday, February 25, 2013 11:52 PM
To: [email-masked]
Subject: [TICTOC] PTP Enterprise Profile draft

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

//Doug

---

From: John Fletcher <[email-masked]>
Date: Wed, 27 Feb 2013 14:23:43 +0000

Some comments on draft-ietf-tictoc-PTPenterpriseprofile-02

General
In many places the terms "Slave Clock" and "Master Clock" are used.  A clock is not a slave or master.  Slave and Master are two of the several possible states that a Port may be in.
You do not specify that Announce messages shall be sent multicast in all modes.

Title and Abstract:
"Precise Time Protocol" should be "Precision Time Protocol"

Abstract:
"The profile uses ... and allows ..."

Introduction:
Re. BMCA - More correct to which Port shall be the active sending time source.  Master not Grandmaster.

Technical Terms:
Acceptable Master List - should be "Acceptable Master Table"
Best Master Clock Algorithm - "... properties each Master Capable Clock sends in its Announce Message" - Announce messages are only sent by Ports in Master state; they are not sent by other Master-capable Ports.
Ordinary Clock - The definition is different from that in 1588-2008.  The key point is that it has only one port.  It may be slave-only.
Rogue Master - should be "A PTP clock operating with a Port in Master state even though the port should not be in Master state according to the Best Master Clock Algorithm"
Slave Only Clock - should be "An Ordinary Clock whose Port cannot enter the Master state"
Unicast Discovery - You are mixing up "Unicast message negotiation" (1588-2008 clause 16.1) with "Unicast discovery" (1588-2008 clause 17.5)

Network Topology
"... treated as separate PTP systems" should be "... treated as separate PTP communication paths".  See 1588-2008 clause 6.7.1.5

Default Message Rates
"Announce Timeout" should be "Announce Receipt Timeout".
Given that Announce Interval is fixed, the Announce Receipt Timeout should be uniform throughout a domain.  See 1588-2008 clause 7.7.3.1

Requirements for Slave Clocks (ports in Slave state)
Remember that the BMCA is for each port to decide what state it should be in (Master, Slave, Passive etc.).  It is not about a Slave deciding which Master to synchronize to.  Application of BMCA when using Alternate Master Table is already specified in 1588-2008 clause 17.6.2

Management Messages
Why forbid multicast messages?  Some Management Messages are intended for all Ports.

Forbidden PTP Options
Why forbid Alternate Timescales?  Transmission of "local wall clock time", for example, may be a useful feature in the Enterprise environment.

Regards,
John Fletcher

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Fri, 1 Mar 2013 01:52:04 +0000

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 <[email-masked]>
Date:  Monday, February 25, 2013 10:52 PM
To:  "[email-masked]" <[email-masked]>
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