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:
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.
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
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.
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.
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.
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.
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.
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.
Let us look at the PTP messages and then map them to each of the modes and transports tabulated above.
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.
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.
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.
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.
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: