PTP is a time synchronization protocol for nodes distributed across a network. Its hardware timestamp feature provides greater accuracy than other time synchronization protocols such as the Network Time Protocol (NTP).

A PTP system can consist of a combination of PTP and non-PTP devices. PTP devices include ordinary clocks, boundary clocks, and transparent clocks. Non-PTP devices include ordinary network switches, routers, and other infrastructure devices.

PTP is a distributed protocol that specifies how real-time PTP clocks in the system synchronize with each other. These clocks are organized into a master-slave synchronization hierarchy with the grandmaster clock, which is the clock at the top of the hierarchy, determining the reference time for the entire system. Synchronization is achieved by exchanging PTP timing messages, with the members using the timing information to adjust their clocks to the time of their master in the hierarchy. PTP operates within a logical scope called a PTP domain.

PTP is not supported on Cisco Nexus 3100 switches from release 6.0(2)U3(1) through release 7.0(3)I2(4). However PTP is supported on Cisco Nexus 3100 switches from release 7.0(3)I4(1) and higher.

The following clocks are common PTP devices:

Ordinary clock

Communicates with the network based on a single physical port, similar to an end host. An ordinary clock can function as a grandmaster clock.

Boundary clock

Typically has several physical ports, with each port behaving like a port of an ordinary clock. However, each port shares the local clock, and the clock data sets are common to all ports. Each port decides its individual state, either master (synchronizing other ports connected to it) or slave (synchronizing to a downstream port), based on the best clock available to it through all of the other ports on the boundary clock. Messages that are related to synchronization and establishing the master-slave hierarchy terminate in the protocol engine of a boundary clock and are not forwarded.

Transparent clock

Forwards all PTP messages like an ordinary switch or router but measures the residence time of a packet in the switch (the time that the packet takes to traverse the transparent clock) and in some cases the link delay of the ingress port for the packet. The ports have no state because the transparent clock does not need to synchronize to the grandmaster clock.

There are two kinds of transparent clocks:

End-to-end transparent clock

Measures the residence time of a PTP message and accumulates the times in the correction field of the PTP message or an associated follow-up message.

Peer-to-peer transparent clock

Measures the residence time of a PTP message and computes the link delay between each port and a similarly equipped port on another node that shares the link. For a packet, this incoming link delay is added to the residence time in the correction field of the PTP message or an associated follow-up message.

Note	PTP operates only in boundary clock mode. We recommend that you deploy a Grand Master Clock (10 MHz) upstream. The servers contain clocks that require synchronization and are connected to the switch. End-to-end transparent clock and peer-to-peer transparent clock modes are not supported.

The PTP process consists of two phases: establishing the master-slave hierarchy and synchronizing the clocks.

Within a PTP domain, each port of an ordinary or boundary clock follows this process to determine its state:

• Examines the contents of all received announce messages (issued by ports in the master state)

• Compares the data sets of the foreign master (in the announce message) and the local clock for priority, clock class, accuracy, and so on

• Determines its own state as either master or slave

After the master-slave hierarchy has been established, the clocks are synchronized as follows:

• The master sends a synchronization message to the slave and notes the time it was sent.

• The slave receives the synchronization message and notes the time that it was received. For every synchronization message, there is a follow-up message. The number of sync messages should be equal to the number of follow-up messages.

• The slave sends a delay-request message to the master and notes the time it was sent.

• The master receives the delay-request message and notes the time it was received.

• The master sends a delay-response message to the slave. The number of delay request messages should be equal to the number of delay response messages.

• The slave uses these timestamps to adjust its clock to the time of its master.

Stateful restarts are not supported for PTP.

• For Cisco Nexus 3000 and 3100 Series switches, PTP clock correction is expected to be in the 3-digit range, from 100 to 999 nanoseconds.

• PTP operates only in boundary clock mode. End-to-end transparent clock and peer-to-peer transparent clock modes are not supported.

• PTP supports transport over User Datagram Protocol (UDP). Transport over Ethernet is not supported.

• PTP supports only multicast communication. Negotiated unicast communication is not supported.

• PTP is limited to a single domain per network.

• PTP management command is supported.

• PTP is supported with sync interval -2 only on Cisco Nexus 36180YC-R switches and Cisco Nexus 3636C-R line cards. Higher sync intervals are not supported.

• PTP-capable ports do not identify PTP packets and do not time-stamp or redirect those packets unless you enable PTP on those ports.

• 1 packet per second (1 pps) input is not supported.

• PTP over IPv6 is not supported.

• Cisco Nexus switches should be synchronized from the neighboring master using a synchronization log interval that ranges from –2 to –5.

• One-step PTP is not supported on Cisco Nexus 3000 and 3500 series platform switches.

PTP supports Mixed mode for delivering PTP messages, which is detected automatically by Cisco Nexus device, based on the type of delay_req message received from connected client and no configuration is required. In this mode when slave sends delay_req in unicast message, master also replies with unicast delay_resp message.

The timestamp tagging feature provides precision time information to track in real time when packets arrive at remote devices. Packets are truncated and timestamped using PTP with nanosecond accuracy. Using the TAP aggregation functionality on the switch, along with the Cisco Nexus Data Broker, you can copy the network traffic using SPAN, filter and timestamp the traffic, and send it for recording and analysis.

If you configure ttag on an interface, all incoming traffic will be tagged. If you configure ttag-strip on an interface all outgoing traffic with ttag will be removed.