IEEE 1588 PTP on Spectrum Switches Running Onyx

Version 5

    IEEE 1588 Precision Time Protocol (PTP) is supported on Spectrum switches as of Onyx release 3.6.6000.

    When enabled, the Onyx powered switch operates as an IPv4 end-to-end IEEE 1588-2008 (PTP version 2) 2-step Boundary Clock.

     

    Enabling PTP

    The following command globally enables the PTP protocol on the switch:

    protocol ptp

     

    Routed Interface

    Prerequisite: IP address bound to the interface. PTP messages are sourced using the primary address of the interface

    The following command enables PTP on a specific interface:

    interface ethernet x/y

    ptp enable

     

    VLAN Interface

    Prerequisite: IP address bound to the VLAN interface. PTP messages are sourced using the primary address of the interface.

    The following command enables PTP on a specific VLAN:

    interface vlan #

    ptp enable

     

    The following command enables the VLAN that requires PTP support per port.

    interface ethernet x/y

    ptp enable

     

    Note: This tiered model allows to retain full control over the configuration granularity as to which VLANs and ports part of a VLAN are PTP enabled. A port may be part of multiple VLANs but only those that are specifically enabled and mapped to a PTP enabled VLAN will have a PTP port state enabled.

     

    By enabling PTP on an interface, all incoming PTP messages are timestamped and trapped to the PTP engine and therefore not treated as regular multicast packets.

     

    Message Rates

    Default PTP message rates values and ranges as defined in the SMPTE ST 2059-2:2015 PTP Profile used in the Broadcast Media segment. These message rate values and domain ID can be changed to support those used by other PTP profiles such as AES67, AESr16, IEEE 1588-2008 Annex J.

    Message RateRangeDefault

    Announce Interval

    -3 (0.125s), 1 (2s)-2 (0.25s)
    Announce Receipt Timeout Interval2, 103
    Sync Interval (logSyncInt)-7, -1-3
    Follow_upN/ASame rate as logSyncInt
    Delay_Request Interval

    logSyncInt, logSyncInt +5

    logSyncInt

    Domain ID0, 127127

     

    PTP Port State

    An understanding of the different PTP port states will help identify issues and troubleshoot what their root cause may be.

    Port StateDefinition

    Initializing

    Port initializes its data sets, hardware, and communication facilities

    Faulty

    Fault state of the protocol, no PTP messages except management

    Disabled

    No messages on its communication path

    Listening

    Waiting for the announceReceiptTimeout to expire or to receive an Announce message from a master

    Pre_Master

    Behaves as a master except no messages are sent, only management

    Master

    Port is behaves as master

    Passive

    No messages sent except signaling or management messages

    Uncalibrated

    Transient state to allow initialization of synchronization servos, updating of data sets when a new master port has been selected

    Slave

    Synchronized to the selected master port

     

    Troubleshooting

    When in need of troubleshooting the PTP infrastructure, there are a series of parameters you may want to check.

     

    Domain ID

    All PTP nodes should be part of the same domain ID. PTP nodes shall ignore messages that are not for the Domain ID they are part of.

     

    Message Rates

    All PTP message rates should be configured to the same values for all the devices (Boundary Clocks, PTP Grand Master, PTP Slaves, etc). In the case of a rate mismatch and/or timeout values, devices with a higher message rate may consider that those with a lower message rate are timing out which would impact the PTP port state.

     

    Communication Mode

    As of Onyx release 3.6.8008, the default communication mode for the Delay Request messages between a PTP port in Slave state and a Master is using "Mixed Mode", sometimes also known as "Hybrid". Thereby, a Master must respond to the unicast Delay Request message issued by a PTP Slave port with a Unicast Delay Response. This significantly reduces the processing load on PTP Slave ports that are in the same broadcast domain since the messages are not sent using multicast to the 224.0.1.129 group that all PTP nodes are mandated to listen to for receiving their PTP messages.

     

    If there is a requirement to run all PTP messages from a PTP Slave port as multicast, the following command allows you to revert from mixed mode to multicast for any PTP port in Slave state.

    ptp message-format multicast

     

    Clock Step

    While Masters may send using either the 1-step clock mechanism (sync message) or 2-step clock mechanism (sync and follow_up messages), all PTP ports in Slave state MUST be able to work with both modes as defined in the IEEE 1588-2008 standard. Some PTP implementations are known to have issues in this area, hence verification may be required.

     

    Clock Characteristics

    During the election of the Master, Best Master Clock Algorithm (BMCA) follows a number of rules to determine which clock will serve as the Master. The following order is used to select the clock:

    1. Priority 1:  The smaller the number the higher the priority. This is user settable in many implementations and serves to build a static hierarchy amongst Master clocks. Beware that this overrides clock class and accuracy.
    2. Clock Class:  The clock is given a class based on the reference clock it is locked to. For example, a class of 6 is considered synchronized to a primary reference time source such as GPS. A value of 248 is the default for devices that are most likely freerunning from their internal oscillator.
    3. Accuracy:  This refers to the value derived from the estimated accuracy based on the timesource attribute, the elapsed time since the last synchronization to the time source and the holdover specifications of the clock.
    4. Variance:  The variability of the clock based on the Allan deviation.
    5. Priority 2:  The smaller the number, the higher the priority. This is user settable in many implementations.
    6. Source PTP Port:  The MAC address-based selection is used as a tiebreaker when all other properties are equal.
    7. Steps Removed:  If there are multiple paths to the same Master across one of more Boundary Clocks, the one with the lowest Steps Removed count is preferred.

     

    Securing the PTP Infrastructure

    In Onyx 3.6.8100, 2 new commands related to securing the PTP infrastructure were introduced.

     

    Acceptable Master Table (AMT)

    AMT is an optional feature of the IEEE 1588 standard whereby you can configure a slave port to refuse to synchronize to clocks which are not part of the acceptable master table whitelist. In Onyx, this list is built against the Clock ID of the candidate masters. This option helps with reducing the risk of slaving from misconfigured or rogue Masters wherever they may be in the PTP domain. Therefore this command is global to the switch and not on a per port basis.

     

    The following command enables AMT for all ports on the switch:

    ptp amt <clock-id>

     

    Forced Master Role

    Forcing the PTP port state to Master for specific ports and/or VLANs provides a mechanism to prevent a Boundary Clock PTP port from changing state to anything but Master. This provides a means to help with reducing the risk of slaving from misconfigured or rogue Masters from directly connected PTP ports.

     

    The following command enables Forced-Master on a specific interface or VLAN:

    ptp enabled <forced-master>

     

    Both of these security features provide a logging capability to track if any PTP nodes don't comply with the AMT whitelist or were advertising themselves as a Master when directly connected to the switch on a "forced-master" port and/or VLAN.