The ordinary and boundary clocks configured for the delay request-response mechanism use the following event messages to generate and communicate timing information:

• Sync

• Delay_Req

• Follow_Up

• Delay_Resp

These messages are sent in the following sequence:

1. The time source sends a Sync message to the time recipient and notes the time (t1) at which it was sent.

2. The time recipient receives the Sync message and notes the time of reception (t2).

3. The time source conveys to the time recipient the timestamp t1 by embedding the timestamp t1 in a Follow_Up message.

4. The time recipient sends a Delay_Req message to the time source and notes the time (t3) at which it was sent.

5. The time source receives the Delay_Req message and notes the time of reception (t4).

6. The time source conveys to the time recipient the timestamp t4 by embedding it in a Delay_Resp message.

After this sequence, the time recipient possesses all four timestamps. These timestamps can be used to compute the offset of the time recipient clock relative to the time source, and the mean propagation time of messages between the two clocks.

The offset calculation is based on the assumption that the time for the message to propagate from time source to time recipient is the same as the time required from time recipient to time source. This assumption is not always valid on an Ethernet network due to asymmetrical packet delay times.

When the network includes multiple levels of boundary clocks in the hierarchy, with non-PTP enabled devices between them, synchronization accuracy decreases.

The round-trip time is assumed to be equal to mean_path_delay/2, however this is not always valid for Ethernet networks. To improve accuracy, the resident time of each intermediary clock is added to the offset in the end-to-end transparent clock. Resident time, however, does not take into consideration the link delay between peers, which is handled by peer-to-peer transparent clocks.

Peer-to-peer transparent clocks measure the link delay between two clock ports implementing the peer delay mechanism. The link delay is used to correct timing information in Sync and Follow_Up messages.

Peer-to-peer transparent clocks use the following event messages:

• Pdelay_Req

• Pdelay_Resp

• Pdelay_Resp_Follow_Up

These messages are sent in the following sequence:

1. Port 1 generates timestamp t1 for a Pdelay_Req message.

2. Port 2 receives and generates timestamp t2 for this message.

3. Port 2 returns and generates timestamp t3 for a Pdelay_Resp message.

   To minimize errors due to any frequency offset between the two ports, Port 2 returns the Pdelay_Resp message as quickly as possible after the receipt of the Pdelay_Req message.

4. Port 2 returns timestamps t2 and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages respectively.

5. Port 1 generates timestamp t4 after receiving the Pdelay_Resp message. Port 1 then uses the four timestamps (t1, t2, t3, and t4) to calculate the mean link delay.

In an ideal PTP network, the time source and time recipient clocks operate at the same frequency. However, drift can occur on the network. Drift is the frequency difference between the time source and time recipient clocks. You can compensate for drift by using the time stamp information in the device hardware and follow-up messages (intercepted by the switch) to adjust the frequency of the local clock to match the frequency of the time source clock.

The grandmaster clock is a network device physically attached to the server time source. All clocks are synchronized to the grandmaster clock.

Within a PTP domain, the grandmaster clock is the primary source of time for clock synchronization using PTP. The grandmaster clock usually has a very precise time source, such as a GPS or atomic clock. When the network does not require any external time reference and only needs to be synchronized internally, the grandmaster clock can free run.

An ordinary clock is a 1588 clock with a single PTP port that can operate in one of the following modes:

• Server mode—Distributes timing information over the network to one or more client clocks, thus allowing the client to synchronize its clock to the server.

• Client mode—Synchronizes its clock to a server clock. You can enable the client mode on up to two interfaces simultaneously in order to connect to two different server clocks.

Ordinary clocks are the most common clock type on a PTP network because they are used as end nodes on a network that is connected to devices requiring synchronization.

A boundary clock in a PTP network operates in place of a standard network switch or router. Boundary clocks have more than one PTP port, and each port provides access to a separate PTP communication path. Boundary clocks provide an interface between PTP domains. They intercept and process all PTP messages, and pass all other network traffic. The boundary clock uses the BMCA to select the best clock seen by any port. The selected port is then set to non-master mode. The master port synchronizes the clocks connected downstream, while the non-master port synchronizes with the upstream master clock.

The role of transparent clocks in a PTP network is to update the time-interval field that is part of the PTP event message. This update compensates for switch delay and has an accuracy of within one picosecond.

There are two types of transparent clocks:

End-to-end (E2E) transparent clocks measure the PTP event message transit time (also known as resident time ) for SYNC and DELAY_REQUEST messages. This measured transit time is added to a data field (correction field) in the corresponding messages:

• The measured transit time of a SYNC message is added to the correction field of the corresponding SYNC or the FOLLOW_UP message.

• The measured transit time of a DELAY_REQUEST message is added to the correction field of the corresponding DELAY_RESPONSE message.

The time recipient uses this information when determining the offset between the time recipient’s and the time source's time. E2E transparent clocks do not provide correction for the propagation delay of the link itself.

Peer-to-peer (P2P) transparent clocks measure PTP event message transit time in the same way E2E transparent clocks do, as described above. In addition, P2P transparent clocks measure the upstream link delay. The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P transparent clock and the P2P transparent clock under consideration.

These two times (message transit time and upstream link delay time) are both added to the correction field of the PTP event message, and the correction field of the message received by the time recipient contains the sum of all link delays. In theory, this is the total end-to-end delay (from time source to time recipient) of the SYNC packet.

The following figure illustrates PTP clocks in a time source-time recipient hierarchy within a PTP network.

The default PTP profile mode on the router is Default Profile mode. In this mode:

• IR8340 supports ordinary clock (OC)- slave, boundary clock (BC), and transparent clock (TC) on default profile.

• IR8340 doesn’t support OC-master.

• All PTP profiles over bundles or port-channels are not supported on IR8340.

The IEEE Power Profile defines specific or allowed values for PTP networks used in power substations. The defined values include the optimum physical layer, the higher level protocol for PTP messages, and the preferred best master clock algorithm. The Power Profile values ensure consistent and reliable network time distribution within substations, between substations, and across wide geographic areas.

The router is optimized for PTP in these ways:

• Hardware—The router uses FPGA and PHY for the PTP function. The PHY time stamps the Fast Ethernet and Gigabit Ethernet ports.

• Software—In Power Profile mode, the router uses the configuration values defined in the IEEE 1588 Power Profile standard.

The following table lists the configuration values defined by the IEEE 1588 Power Profile and the values that the router uses for each PTP profile mode.

The IEEE 802.1AS standard "Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks" specifies the protocol and procedures used to ensure that synchronization requirements are met for time-sensitive applications across bridged and virtual bridged local area networks.

802.1AS specifies the use of IEEE 1588 (PTP) specifications where applicable in the context of IEEE Std 802.1D -2004 and IEEE Std 802.1Q -2005.1. The 802.1AS standard is one of three 802.1 AVB draft standards. 802.1AS over Ethernet (802.3) qualifies as a Profile of IEEE 1588-2008. It simplifies IEEE 1588 and defines synchronization over different types of media.

Note	802.1 AS can be configured with domain 0 only on IR8340 platform.

Key characteristics of 802.1AS are:

• For Ethernet full-duplex links, it uses the peer delay mechanism.

• All devices in the domain need to be 802.1AS capable.

• Transportation of 802.1AS packets is L2 multicast only, with no VLAN tag.

• It requires two-step processing (use of Follow_Up and Pdelay_Resp_Follow_Up messages to communicate timestamps).

• There is only a single active grandmaster in a time-aware network. That is, there is only a single 802.1AS domain.

• The BMCA (Best Master Clock Algorithm) is same as that used in IEEE 1588 with the following exceptions:

  • Announce messages received on a time recipient port that were not sent by the receiving time-aware system are used immediately; that is, there is no foreign-time source qualification.

  • A port that the BMCA determines should be a time source port enters the time source state immediately; that is, there is no pre-time source state.

  • The uncalibrated state is not needed and therefore not used.

  • All time-aware systems are required to participate in best master selection (even if the system is not grandmaster capable).

802.1AS is used in the Time Sensitive Network (TSN) feature. However, as a precise timing distribution mechanism, 802.1AS runs by itself without TSN configuration or inputs. The 802.1AS feature software implementation is based on the existing time stamping functionality of FPGA and has no new requirement on hardware beyond other PTP profiles.

The end-to-end time-synchronization performance of 802.1AS is as follows:

• Any two time-aware systems separated by six or fewer time-aware systems (that is, seven or fewer hops) will be synchronized to within 1 μs peak-to-peak of each other during steady-state operation.

• Performance beyond 7 hops is not defined.

The clock manager is the component in the Cisco NTP to PTP software architecture that keeps track of the various time services and selects the clock that actively provides time. The clock manager notifies the time services of important changes, such as state changes, leap seconds, or daylight saving time.

The clock manager selects the NTP or manually-set clock first, followed by PTP and the real-time clock if NTP is not active. The following table shows the results of the clock selection process.

In general, the clock manager ensures that the time displayed in the Cisco IOS commands show ptp lan clock and show clock match. The show clock command always follows this priority, but there are two corner cases where the show ptp lan clock time may differ:

• The router is either a TC or a BC, and there is no other active reference on the network. To preserve backwards compatibility, the TC and BC never take their time from the clock manager, only from the network’s PTP GMC. If there is no active PTP GMC, then the time displayed in the show clock and the show ptp lan clock command output may differ.

• The router is a syntonizing TC, a BC with a slave port, or a GMC-BC with slave port, and the time provided by the PTP GMC does not match the time provided by NTP or the user (that is, manually set). In this case, the PTP clock must forward the time from the PTP GMC. If the PTP clock does not follow the PTP GMC, then the PTP network will end up with two different time bases, which would break any control loops or sequence of event applications using PTP.

The following table shows how the Cisco IOS and PTP clocks behave given the various configurations. Most of the time, the two clocks match. Occasionally, the two clocks are different; those configurations are highlighted in the table.

• The Cisco PTP implementation supports only the two-step clock and not the one-step clock.

• Cisco PTP supports multicast PTP messages only.

• The router and the grandmaster clock must be in the same PTP domain.

• When Power Profile mode is enabled, the router drops the PTP announce messages that do not include these two Types, Length, Value (TLV) message extensions: Organization_extension and Alternate_timescale.

  If the grandmaster clock is not compliant with PTP and sends announce messages without these TLVs, configure the router to process the announce message by entering the following command:

  ptp clock boundary domain 1 profile power
  allow-without-tlv
  

• When the router is in Power Profile mode, only the peer_delay mechanism is supported.

  To enable power profile boundary mode and associate interfaces using the clock-port suboption, enter the following command:

  ptp clock boundary domain 1 profile power
  clock-port 1
  transport ethernet multicast interface gi0/1/1
  

• To disable power profile transparent mode, enter the following command, which returns the router to forward mode.

  no ptp clock transparent domain x profile power
  

• To enable the E2E transparent clock, use the following command:

  ptp clock transparent domain x profile default

• In Default Profile mode, only the delay_request mechanism is supported.

  To enable default profile boundary clock mode and interfaces associated with clock-port suboption, enter the following command:

  ptp clock boundary domain 1 profile default
  clock-port 1
  transport ipv4 multicast interface gi0/1/1
  

• The 802.1AS profile does not have a clock mode setting.

• The packet format for PTP messages can be 802.1q tagged packets or untagged packets.

• The router does not support 802.1q QinQ tunneling.

• In Power Profile mode:

  • When the PTP interface is configured as an access port, PTP messages are sent as untagged, Layer 2 packets.

  • When the PTP interface is configured as a trunk port, PTP packets are sent as 802.1q tagged Layer 2 packets over the port native VLAN.

• Time recipient IEDs must support tagged and untagged packets.

• When PTP packets are sent on the native VLAN in E2E Transparent Clock Mode, they are sent as untagged packets. To configure the switch to send them as tagged packets, enter the global vlan dot1q tag native command.

• Sets the PTP VLAN on a trunk port. The range is from 1 to 4094. The default is the native VLAN of the trunk port.

• In boundary mode, only PTP packets in PTP VLAN will be processed, PTP packets from other VLANs will be dropped.

• Before configuring the PTP VLAN on an interface, the PTP VLAN must be created and allowed on the trunk port.

• Most grandmaster clocks use the default VLAN 0. In Power Profile mode, the router default VLAN is VLAN 1 and VLAN 0 is reserved. When you change the default grandmaster clock VLAN, it must be changed to a VLAN other than 0.

• When VLAN is disabled on the grandmaster clock, the PTP interface must be configured as an access port.

• All PHY PTP clocks are synchronized to the grandmaster clock. The router system clock is not synchronized as part of PTP configuration and processes.

• When VLAN is enabled on the grandmaster clock, it must be in the same VLAN as the native VLAN of the PTP port on the router.

• Grandmaster clocks can drop untagged PTP messages when a VLAN is configured on the grandmaster clock. To force the router to send tagged packets to the grandmaster clock, enter the global vlan dot1q tag native command.

• IR8340 does not support PTP over Port Channels.

• The following PTP clock modes only operate on a single VLAN:

  • e2etransparent

  • p2ptransparent

• The NTP to PTP feature supports the Default E2E Profile and Power Profile.