Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Audio video bridging, auto Ethernet fuel need for precise timing

As applications such as automobile Ethernet and audio video bridging gain traction, the need for new timing protocols beyond NTP takes root.

In the second part of a two-part series, network engineer Andrew Gallo examines IEEE's Precision Timing Protocol and the ITU's Synchronous Ethernet.

Time of day and frequency distribution aren't usually at the forefront of IT managers' agendas. Historically, data networks were non-deterministic. They didn't require precise timing, which is part of the reason why they were so easy and inexpensive to deploy. This has led to IP over Ethernet networks acting as the single, converged infrastructure for a wide variety of needs -- ironically, leading network designers to incorporate some of the features that were left out, specifically timing mechanisms. Ethernet has, therefore, become a victim of its own success. Advances in technology have made the reintroduction of precise frequency distribution desirable and economically feasible.

Ethernet is now carrying traffic -- such as interactive voice and video -- that needs high-precision timing.

One of the key features of IP over Ethernet that made it the winning transport in nearly all environments is that it is inexpensive and easy to deploy -- in part because of its asynchronous operation. But as applications have multiplied and become more complex, Ethernet is now carrying traffic -- such as interactive voice and video -- that needs high-precision timing. And Ethernet is not a technology that was originally designed for tight tolerances.

To compensate, buffering was used to handle the initial convergence of real-time media on IP networks. Jitter buffers are short-duration holding pens that smooth the variations of inter-packet arrival time. Humans can't generally perceive the 20 millisecond to 50 msec latency that buffering introduces, but for some applications, a delay even this short is unacceptable. Among them:

  1. Mobile (cellular) backhaul over Ethernet. Earlier, most mobile traffic was carried over time-division multiplexing (TDM) links, natively providing synchronous operation. A highly accurate and common clock source is critical for mobile operators to ensure proper frequency reference and for events such as a voice call handoff between cell sites.
  2. Interworking of SONET/SDHwith Ethernet. As carriers migrate networks to IP over Ethernet, in order to maintain consistent, network-wide synchronization, IP over Ethernet must maintain synchronization information to prevent creating islands.
  3. Audio video bridging (AVB, IEEE 802.1BA). Broadcast-quality audio and video production and distribution demand very tight timing, especially when mixing signals from different sources or converting between formats. Traditionally, this function has been performed on standalone and proprietary equipment and networks.
  4. Automotive Ethernet, a special application of Ethernet for use in automobiles where quality of service and determinism are critical for safety reasons. Automotive Ethernet appears to be adopting many of the advances of AVB, but may require even more stringent network performance.
  5. Power generation and distribution. The North American power grid operations at 60 cycles per second with little tolerance for variation. Each of the three interconnects (grid divisions) in the United States must maintain this frequency standard, which is to say, all generators must rotate at exactly the same speed. As grid control systems become IT systems, distributing timing information is critical.
  6. Industrial control, where safety dictates the sequence of operations of heavy machinery.
  7. Scientific and laboratory measurements, where determining cause and effect of short-duration and fast-acting events is necessary.

New protocols wait in wings to provide additional control

Enter the IEEE's Precision Timing Protocol (PTP) and the ITU's Synchronous Ethernet. Both of these emerging standards enable much more precise time distribution than can be accomplished with the Network Time Protocol (NTP).

It can be argued, however, that the level of accuracy these protocols offer is not needed for packet switching networks. Not only are they expensive and complex, but Ethernet networks run asynchronously. Unlike TDM technologies that offer guaranteed, lock-step transmission of frames, Ethernet is a probabilistic technology that uses collisions, retransmissions and buffering to mediate contention.

That said, business drivers are leading IT administrators to seriously consider these protocols. Let's examine what they are.

Synchronous Ethernet (SyncE). The ITU's protocol differs from traditional Ethernet in two primary ways. First, the reference clock for each transmitter in a device is not the media access controller's local oscillator (as with standard Ethernet), but a common source shared among all the ports on a node. Second, the clock, or oscillator, is of a much higher quality. Specifically, the oscillators in a SyncE system have a quality of plus or minus 4.6 parts per million, putting it on par with SONET stratum 3 t iming (an order-of-magnitude better than standard Ethernet). The benefit of this approach is that by relying on the incoming line coding, there is no additional overhead imposed on the network (though there are some status messages that are passed among the participating nodes and the Ethernet Synchronization Message Channel to provide interworking with SONET/SDH synchronization status messages). Also, because this approach is similar to the SONET/SDN method of frequency distribution, it is easy for carriers to adapt designs. The primary disadvantage is that each node in the network must be SyncE-capable.

PTP (also referred to by its standard number, 1588). PTP uses IP (either v4 or v6) multicast packets to transmit both timing information and supervisory messages. By contrast, SyncE relies on the line coding of the Ethernet to provide clock synchronization.

(Note: IEEE 1588 is a specific profile within the 802.1AS Timing and Synchronization for Time Sensitive Applications.)

Protocol revision supports another method for synchronization

Version 2 of the 1588 standard supports native Ethernet (non-IP) frames for synchronization. While having all devices in a network PTP-capable will lead to better performance, this isn't strictly necessary. That's because the messages are traveling as network payload in special packets, rather than the line coding. As a result, PTP can thus be implemented in stages. The nodes in a 1588 system run a distributed algorithm called Best Master Clock (BMC) to determine which device will be the master from which all others (slave) devices will derive time. A disadvantage of 1588 is that its messages are traveling as network data. That means it is subject to delay variation (jitter) while being commingled with other data. Because this protocol is implemented in hardware, adjacent to media access controllers, propagation delays and jitter are minimized. Whereas NTP is implemented either in an operating system kernel or application software, PTP is implemented as part of the frame processing function of an Ethernet interface. Accuracy on the order of 1 nanosecond is possible, with some vendors claiming 1 microsecond .

While the drivers for adoption of high-quality timing may not apply in all organizations, especially enterprise IT networks, it is worth keeping abreast of these technologies so that they may be deployed where needed.

About the author:
Andrew Gallo is a Washington, D.C.-based senior information systems engineer and network architect responsible for design and implementation of the enterprise network for a large university.

Next Steps

What you need to know about network timing

This was last published in October 2014

Dig Deeper on Network management and monitoring

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Do you believe you need to convert from NTP to meet your network timing objectives?