The move from synchronous to asynchronous networks means network architects must find a new way to provide timing. Often, reality dictates the need for more than one way...
By JIM THEODORAS
Timing is becoming a more crucial part of today's network requirements, and yet never before has there been more confusion on how to implement this critical capability.
As networks migrated from synchronous to asynchronous, timing somehow got left behind. Now network architects are scrambling to bring back functionality that was once taken for granted. The options available to them:
- Legacy synchronous connections
- Network time provided by packet infrastructures
- U.S. Global Positioning System (GPS) antennas and source clocks
- IEEE 1588 "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems"
- ITU-T Synchronous Ethernet (SyncE).
How does a network operator choose, and which option is most appropriate for a specific network type?
Making do
Throughout synchronous networking's history, timing was largely underappreciated. Network architects understood it to be a critical enabling capability for certain services. But timing essentially came for free, as an inherent capability of the large public networks that were built to carry voice traffic. Consequently, some people took it for granted.
The voice network's synchronous nature can be traced back to the speed of a motor shaft, as telephone calls were switched with motors and electrical contacts. The characteristics of these mechanical phone switches eventually dictated the specifications of T- and E-carrier electronic equivalents, where a DS0 was a single voice circuit (set of contacts) in TDM.
Once networks began their migration from TDM to asynchronous packet transmission, timing requirements caught the attention of network architects. Those first packet networks carried no timing information whatsoever. With timing no longer a given capability, network architects were forced to scramble to recover the functionality.
Until recently, network operators largely have continued to rely on legacy connections for timing-usually an existing T1 or DS0/DS3. Once packet data demands outstripped the capacity (or tolerable price per bit) of these legacy networks, operators simply rolled out additional asynchronous packet links in parallel with the existing synchronous links. Just enough synchronous paths were maintained for their inherent timing capability. The newly installed asynchronous packet paths assumed the burden of the rapidly growing traffic load.
This strategy has sufficed over the last decade, but no more. The tremendous growth in mobile packet data, driven by applications such as video calling and social networking via smartphones, has magnified the problems inherent in this timing approach. Running and maintaining two separate networks is both difficult and highly inefficient. In many carrier infrastructures, the only traffic still running over the synchronous gear is the timing. Furthermore, keeping legacy gear running is much more expensive than newer packet equivalents, compounded by the problem of legacy equipment being "end-of-life-d" by its original vendors, if they can even be found anymore.
It is clear that a more efficient and longer-term solution is needed today.
A menu of options
Fortunately, thought leaders in the networking industry began working years ago on a number of options for transporting timing on asynchronous "packetized" networks.
Network time: Packet networks actually did and still do have a timing function-network time, based upon Network Time Protocol (NTP), one of the oldest Internet protocols. NTP has been continuously updated over the years, and the latest version, NTPv4, can maintain time to within 10 ms over the public Internet.
NTP has its shortcomings, though. First, the timing locked loops that are necessary to maintain sync are run in higher application layers of the network stack. Second, the network timing can be only as accurate as the source clock, and the network clock being used typically has gone through many strata before reaching the application needing the clock.
Nevertheless, NTP is in use today and has proven sufficient for most generic applications.
GPS: Many of today's applications need better accuracy than NTP can deliver. A second option is putting an accurate source clock at each node of the network. This distributed-timing strategy normally relies on GPS-based master clocks (though there are some cases of terrestrial radio signals being used). GPS-based master clocks can be found at most cell tower sites today.
So… problem solved, right? Wrong. As applications have advanced, they have required better and better accuracy. GPS-a timing source based upon a constellation of moving satellites-may not be able to keep up with the greater accuracy needs. Plus, newer wireless protocols like 4G Long-Term Evolution (LTE) need information beyond what GPS provides (phase, in addition to frequency or time of day, for example). And there is some reluctance among network operators outside the United States to base their entire network function on something that has an on/off switch controlled and maintained by the U.S. Department of Defense.
Precision Time Protocol: IEEE 1588 appeared in 2002 and was updated in 2008, addressing NTP's shortcomings and defining the Precision Time Protocol (PTP). While NTP works by synchronizing clocks across layers of clock strata within a network, PTP attempts to expedite the transport of timing information by using a messaging protocol.
In a packet network, timing information, like other data, arrives asynchronously; PTP was designed to maintain accuracy as a timing message traverses routers on its way to its intended destination. In PTP, each node in the network has a timing message function: ordinary clock, boundary clock, end-to-end transparent clock, or peer-to-peer transparent clock. Like NTP, PTP messaging runs in higher software application layers; however, some functions such as time stamping can run directly in hardware.
As is the case with NTP, proponents of PTP continue to refine the functionality, and accuracies have improved. Like GPS, PTP has a critical shortcoming in that it fails to transport phase information. This is where the next option comes in.
SyncE: SyncE, a product of ITU-T G.8261, seeks to imbue Ethernet with some of the same qualities that SONET/SDH has offered-such as preservation of both frequency and phase information.
In a traditional Ethernet link, packets are clocked into and out of a buffer with two separate clocks. For example, in many Ethernet optical modules, such as X2, a free-running crystal oscillator is used, and there is no relation whatsoever between incoming and outgoing clock domains. With SyncE, a phase locked loop is implemented in Layer 1 hardware (rather than in higher software application layers). This keeps the incoming and outgoing packet streams in sync, and a messaging protocol is embedded into the packets.
In an end-to-end, SyncE-based infrastructure, then, clock frequency and phase are highly accurate. The shortcoming of SyncE, of course, is that it demands that every link in a transport path be compatible with the protocol, and this is seldom the case.
The hybrid reality
So, with such an array of options, which timing scheme is best for a given network? The reality today is that most networks are a strategic mix of all of the available timing techniques.
Let's look at one example of a mobile backhaul network. The primary link between towers and mobile network is packet backhaul. PTP would be used for primary clock information. Where possible, SyncE might be used to deliver phase information for LTE antennas; where SyncE is not possible, a legacy, synchronous T1 circuit would be maintained. GPS antennas might provide a second reference to validate the quality of the primary clock, as well as a backup if SyncE or the T1 is lost. NTP could be used by software at higher application layers-and made more accurate with a feed from the GPS source.
This sort of hybrid scenario maximizes efficiency and minimizes costs, while providing the highest possible level of accuracy. These latest timing protocols enable unprecedented accuracy to be supplied and maintained across long-haul transport networks.
A network architect must be prepared to leverage each of the timing options available, wherever each option's unique combination of pros and cons is most appropriate, with an eye on the application demands and existing architecture.
JIM THEODORAS is senior director of technical marketing, ADVA Optical Networking, and president of the Ethernet Alliance.