IEEE-1588 PTP protocol evolution

IEEE 1588 is the standard specification for the Precision Time Protocol (PTP) with the version 2 being the commonly deployed implementation. The IEEE-1588 PTP protocol evolution over more than a decade from v1 to v2 to v2.1

IEEE-1588 PTP protocol evolution

The first version (v1) specification released in 2002. This standard is known as IEEE1588-2002. There are some audio devices that conform to older v1 specification but as such v2 is not backward compatible to support that.

A major update (also not backward compatible) was made in 2008 calling it a version 2.0 and remains the most widely deployed implementation in the networks that require synchronization. This standard is known as IEEE1588-2008

A recent update as new as 2019 bumps up the version to 2.1 indicating that it is compatible with v2 however comes with newer features. This standard is known as IEEE1588-2019

PTP v1 vs v2

The major improvement / update in 2008 (v2) was the introduction of:

  • Transparent Clock
  • Two-step mode
  • Peer-Delay mechanism
  • IPv6 support
  • Unicast support
  • Increased message rate

PTP v2 vs v2.1

The improvements / updates in 2019 (v2.1) was the introduction of:

  • Special ports that inherently support timing (eg. WiFi 802.11, EPON etc)
  • Multi-domain interactions
  • Acceptable Master Table based on port-Identity
  • Updates to clock Identity
  • Dataset updates for Transparent clock
  • Not compatible for 2002 standard
  • Holdover-Upgradable capability
  • Domain subparts with sdoId
  • Calculation of MeanPathDelay in multiple domains

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

What is PTP (Precision Time) – An Online Training

Get a deep-dive as well as extent of the Precision Time Protocol (PTP) with the online training. It includes the time/clock concepts, software, hardware and various use-cases as well as different Network architectures in small and large deployments.

What is PTP (Precision Time) – An Online Training

This is a paid training with premium content being added continuously. To support this effort, a nominal charge gives you access to this constantly-updated material for a limited duration. Please use the below course-contents and the form to enquire further.

There are some example links that you can browse as you make your request. Each 1-to-1 session is customized to your background and existing knowledge so that you can come up to speed on PTP as soon as possible.

PTP Course Contents:

  • Fundamentals of PTP
    • IEEE 1588v2 Precision Time Protocol concepts
    • Master, Slave and Intermediate nodes
    • Timestamping and PTP Event Packets
    • PTP General and Management packets
    • Evolution of PTP protocol
  • The Best Master Clock Algorithm (BMCA)
  • Clock synchronization concepts
  • Comparison – SyncE, NTP, PTP
  • Types of clocks:
  • Clock Modes
    • End-To-End Delay Mechanism
    • Peer-To-Peer Delay Mechanism
    • Clock Steps (1-step and 2-step)
  • Transport Modes
    • Ethernet and IP transports (v4 and v6)
    • Unicast and Multicast transports (and Hybrid)
  • QoS considerations for PTP
  • Multicast consideration for PTP
  • Detailed Protocol Functionality
    • Control Packet Exchange
    • Mandatory Correction Field updates
    • Configuration and Wireshark logs
  • Testing 1588 PTP
  • Multi-hop Network Topologies
    • Full-Path PTP Network
    • Partial PTP Network
    • Packet Delay Variation (PDV) considerations
  • IEEE 1588 (Default) and other profiles
    • Broadcast (SMPTE/AES/R16)
    • Power Profile
    • Telecom
    • Other user-case and verticals (like Industrial)
  • Interactions of NTP and PTP
  • PTP software stacks and drivers

RSVP

Show your interest or send your requirements and we shall get back:

You shall receive confirmation mail of your request and we shall discuss all the things you require to be covered in the training for a fully customized and efficient experience. A calendar will be shared for selecting your comfortable timing over the week and the length of the training will vary based on the contents to be covered.

AVB Endpoints vs Network Nodes

Today we see what are the differences between an AVB endpoint (which are the AVB talkers and AVB listeners) versus an AVB compliant Network node (which connects those end-points to each other in an AVB network).

AVB is an Ethernet based Layer-2 Audio-Video bridging technology (from a Network perspective), however, any vanilla (or even high-end) Ethernet switch cannot be used to connect AVB devices, as it will not be able to provide the required Quality-of-Service though the network or be able to guarantee reservations required by AVB to operate. Let us first see how an AVB enabled Ethernet-switch is different

Normal Ethernet Switch AVB enabled Ethernet Switch
Provides Ethernet Switching capability
Can have 2 or more ports with different port-speeds
Provides MAC learning, switching, filtering etc
Supports VLANs, priorities & Multicast capability
Basically provides Ethernet Layer-2 connectivity
It needs to provide all the features
that a normal Ethernet Switch provides
N/A Needs to provide stream delivery guarantee
Has to synchronise and transfer clock
Support Stream Reservation protocol
Deliver Audio/Video payload without drops
Keep the latency within required margin
Communicate with other AVB nodes

As we see above, an AVB-enabled network gear is specialized in the way it operates and communicates with its peers. Now lets us see, how an AVB end-point is different from an AVB switch itself.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

PTP Master Clocks and GMs

PTP (Precision Time Protocol) Networks are Timing/Clock hierarchies that can support multiple Master(s) and Grand-Master(s) as the source of accurate time. Each clock-node "advertises' its capability (like clock accuracy, its source of time, it own variance etc) into the network.

These PTP networks could be Ethernet, or use IP/UDP as transport protocols or even MPLS. There are implementations and design considerations to support IEEE 1588 on Wireless links too. And then, we have DeviceNet, ControlNet and ProfiNet etc that support PTP.

As we have seen in previous articles, the PTP messages themselves could be transported in a Multicast mode or use Unicast communication, and the recent standard also supports Mixed mode (Unicast+Multicast)

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Hardware Time-stamping in PTP 1588

The Hardware that supports PTP event-message time-stamping makes the synchronization much more accurate. As you can see in the figure below, the same timestamps can be gotten from various layers:

  1. Software
  2. Kernel
  3. Driver
  4. MAC
  5. PHY

The lower (nearer) we go to the physical-layer, the more accurate and exact time we can use to find when a particular PTP packet was received from or transmitted to the line/wire.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

PTP Transparent clocks 1-step 2-step

Why Transparent Clock

Transparent clocks are used in PTP topologies in order to improve the accuracy of the end-station synchronization. The reason is that time-unaware devices introduce varying amount of path-delay between the clock-source (master) and end-station (slave). Unless the master and slave are directly connected, or all the devices in between then are time-aware the inaccuracy increases due to varying amounts of queue-delays and path-delays of different nodes and links.

How Transparent Clocks work

Transparent clocks are much simpler that full-featured Boundary clocks because the aim of a transparent clock is to make itself invisible (of sorts) from their own effect on transport of time across the PTP topology. They do this by timestamping PTP packets as they ingress (with a timestamp T1) and at egress (with a timestamp T2) and putting this delta-difference (T2 - T1) as a correction-field (CF) in the PTP packets. Such a device (called an End-to-End or E2E TC) removes its internal delay (and thus delay-variation) by informing the end-station about its own CF.

Working of a PTP Transparent Clock

Types of Transparent clocks

There are 2 types of Transparent clock:

  • The ones that measure their own delay (E2E)
  • The ones that also measure the link-delay (P2P)

The additional logic in the latter TC is that, it uses PDelay_Req and PDelay_Response packets with its peer-device to calculate the link-delay and adds that to the residence time (T2-T1) calculation ie.

Correction Field = Link Delay + Residence time

There is another way to classify Transparent clocks:

  • The ones that use 1-step clock
  • The ones that use 2-step clock

The difference in the latter is that they use a Follow-up message to convey the Correction-Field as they cannot update the delta (residence time) on the fly.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

IEEE 1588 PTP Clock Modes and Transports

IEEE-1588 PTPv2 has various clock-modes that can work with different Transport-layer technologies like Ethernet, IPv4, IPv6 as well as MPLS, DeviceNet, ControlNet, etc. Here we look at the various scenarios and cases on how PTP can serve different network use-cases with its different configuration combinations.

Ethernet Mode

S. No. Transport Clock Mode Delay Mechanism Clock Steps
1 Ethernet Boundary End-to-End 1
2 Ethernet Boundary E2E 2
3 Ethernet Boundary Peer-to-Peer 1
4 Ethernet Boundary P2P 2
5 Ethernet Transparent E2E 1
6 Ethernet Transparent E2E 2 (2-step)
7 Ethernet Transparent P2P 1
8 Ethernet Transparent P2P 2
Table 1: IEEE-1588 Clock Modes with Ethernet Transport

The PTP communication in Ethernet mode using the specific Multicast MAC address(es). These come in two varieties, the general Multicast address (01-1B-19-00-00-00) and the reserved Multicast address (01-80-C2-00-00-0E). While the former is used to deliver General (Announce etc) and event (Sync, Delay_Req etc) messages, the latter is specifically used for peer-delay (Pdelay_Req etc) messages.

1588 Sync and Delay Req

Let us look at the PTP messages and then map them to each of the modes and transports tabulated above.

S. No. Message Type Destination MAC Timestamps
1 Sync Event 01-1B-19-00-00-00 T1, T2
2 Follow_Up General 01-1B-19-00-00-00 T2'
3 Delay_Req Event 01-1B-19-00-00-00 * T3
4 Delay_Resp General 01-1B-19-00-00-00 * T4
5 PDelay_Req Event 01-80-C2-00-00-0E T1, T2
6 PDelay_Resp Event 01-80-C2-00-00-0E T3, T4
7 #P_Follow_Up General 01-80-C2-00-00-0E T3'
8 Announce General 01-1B-19-00-00-00 NA
9 Management General 01-1B-19-00-00-00 NA
10 Signaling General 01-1B-19-00-00-00 NA
Table 2: PTP Message Types and Destination

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AVB – Traffic Classes

The traffic in an AVB Network is classified into Class-A, Class-B, Control Traffic, and the rest as Best-Effort. These streams are identified by, unique (application generated) Stream-ID, destination Multicast MAC address, and classified based on VLAN ID and priority. Each stream defines the worst-case packet-size, frequency of such packets so that the intermediate nodes know the amount of bandwidth to be reserved to deliver them to the listener(s).

Needless to say, the Audio/Video streams are mapped to the highest priority traffic classes A/B, which are:

  • Class-A streams: Produce frame(s) at 8 KHz (or 125 micro-seconds) and support an end-to-end latency of 2 milliseconds.
  • Class-B streams: Produce frame(s) at 4 KHz (or 250 micro-seconds) and support an end-to-end latency of 50 milliseconds.

This is followed (in priority) by Control Traffic. The control-plane traffic is important for all the state-machines and signaling, however, are not as much latency-bounded as the AV streams. The control traffic is also mostly event-based, majorly non-periodic and much smaller in volume when compared to the AV and other data-traffic. This includes PTP control frames, MSRP BPDUs and other protocol exchange like IGMP and multicast etc.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AVB – Multicast Streams

The Audio Video Bridging (AVB) supports unicast, as well as multicast AV streams. Without going too much into the obvious benefits of multicasting, the AVB uses MAAP (MAC Address Acquisition Protocol) or configured multicast MACs for these types of AV streams. Each multicast stream goes to a unique MCast address.

Furthermore, the AVB multicast is selective in the sense that the streams will be delivered to only those ports where the listeners have requested them and are ready to receive them. On top of this, the MSRP ensures that each node has enough resources to participate in the delivery over the Multicast tree. If no multicast listeners have requested, the talker itself will stay silent.

Multicasting

An AVB Multicast is a Layer-2 (Ethernet based) Multicast, not a Layer-3 (IP based multicast). While it is possible that Multicast IP gets mapped to a Multicast Destination MAC Address, however, the underlying data-flow (for the Audio Video streams) is going to use the Ethernet Muitlcast Destination MAC address to replicate the traffic to the individual ports of an AVB enabled bridge/switch.

Information Flow

The Talkers and Listeners discover and enumerate with the help of AVDECC protocol, while the MAC addresses are assigned by configuration or use MAAP to allocate. Furthermore, the AVTP is used to transfer the AV data payload from the multicast talkers to the listeners. This happens only after the MSRP has ascertained the availability of resources like bandwidth, memory etc for loss-less and low-latency delivery of the AV essence.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AVB – Audio Video Streams

An AVB (Audio Video Bridging) Network consists of AVB-enabled bridges that use the VLAN based priority to classify the incoming streams into traffic classes. Traffic from non-AVB devices or different-domain is considered out of the AVB boundary and treated best-effort.

Talker(s) can create one or more streams and Listener(s) can subscribe to one or more streams. While the intermediate networking devices to monitor the (requested) stream bandwidths and allocate resources to allow/deliver them within the required constraints of bandwidth and latency.

In an AVB N/w, the AV streams are initiated only after:

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

You cannot copy content of this page
%d bloggers like this: