YOUR NETWORK. OPTIMIZED.

Best Practices for IEEE 1588/ PTP Network Deployment

WHITE PAPER

Best Practices for IEEE 1588/PTP Network Deployment

IEEE 1588-2008 means that precise timing and synchronization over Ethernet is now a reality but the solution is only as good as the sum of its parts.

Abstract
With the recent ratification of the IEEE 1588-2008 protocol specification also known as Precision Time Protocol (PTP) Version 2 distribution of precise time and frequency over Ethernet network infrastructures enters a new phase. By replacing costly TDM backhaul lines with Ethernet, service providers can reduce recurring backhaul line costs by up to 90% while simultaneously boosting network capacity for bandwidth hungry applications like text messaging, music downloads and video streaming. Until now, many network service providers have been reluctant to transition from TDM to Ethernet backhaul due to Ethernets inherent lack of an adequate timing and synchronization mechanism. However, with the advent of IEEE 1588-2008, providing precise timing and synchronization over Ethernet is no longer an issue. IEEE 1588-2008 has now been adapted to meet the more sophisticated synchronization requirements of telecommunications applications. It captures those requirements by providing a set of added capabilities and protocol extensions that allow service providers to fine tune their packet-based networks for the stringent timing and synchronization requirements of telecom-oriented applications. Some of these capabilities, like frequency synchronization and multicast support, are explicitly supported within the IEEE 1588-2008 framework while other capabilities, such as support of unicast and telecom profile extensions, provide the higher level of accuracy and performance optimization that telecom requires. As service providers begin to deploy IEEE 1588-2008, they need to understand how these different capabilities, or lack of them, may impact their network performance and service level agreements. Optimal results can be achieved if they can anticipate future requirements and choose a carrier class PTP solution that offers the highest level of resiliency, performance, scalability and management.

Not All Clocks Are Created Equal

PTP employs a client/server architecture to ensure precise timing and synchronization between PTP servers either grandmaster clocks or boundary clocks and PTP clients that are distributed throughout the network. Clients stay synchronized with grandmaster or boundary clocks by continuously exchanging timing packets with them thereby compensating for the delays inherent within any Ethernet, packet-based network. A high level of accuracy is assured by using hardware timestamping to mark each packet. Hardware timestamping mitigates the normal delays that are incurred as packets traverse the network and encounter numerous routers and switches as they travel from their source to their destination. A grandmaster is the highest-ranking clock within its network domain. There may be single or multiple grandmaster clocks within the same network. IEEE 1588 grandmasters can be deployed as either standalone devices or as plug-in modules or blades that can be integrated into an existing synchronous service unit (SSU) or building interface timing server (BITS) shelf. Grandmasters are just as important as their name implies. They are an essential component of any IEEE 1588 solution because they are the primary reference source (PRS) for all other PTP elements within their network domain. Boundary clocks act as intermediaries between a PTP grandmaster and its PTP clients. Boundary clocks typically live at the edge of the network and receive their primary reference from an upstream grandmaster while simultaneously serving as a master to the downstream PTP clients in the network. The boundary clock mitigates the number of network hops and resulting delays that occur in the packet network between the grandmaster and its clients. Some PTP clocks can function as either a grandmaster or boundary clock. The primary advantage of boundary clocks is that they eliminate the need to have a GPS timing source at every server location, which in turn significantly reduces the cost of deploying an end-to-end PTP solution. IEEE 1588-2008 also specifies transparent clocks. A transparent clock maintains its own precise internal clock that forwards timing packets from one network segment to another. It compensates for packet delays by updating the timestamps of each packet that passed through it.

Best Practices for IEEE 1588/PTP Network Deployment

Know Your Telecom Profile

Telecom profiles are extensions to the IEEE 1588-2008 protocol specification that define a unique set of capabilities or enhancements that are required to adequately support PTP telecommunications applications such as Ethernet backhaul, synchronization of IP DSLAMs and Passive Optical Networks (PON). These enhancements include: Support for wireless standards: Different wireless standards specify various time and frequency offsets that must be met in order to prevent calls from being dropped as mobile users move from one base station coverage area to another. In particular, ITU-T Recommendation G.8261/Y.1361 (formerly G.pactiming), Timing and Synchronization Aspects in Packet Networks, specifies the upper limits of packet delay variation (PDV) that network equipment at the TDM interfaces. The telecom profile also specifies a maximum error level that can be tolerated in order to meet basic quality of service requirements. For example, GSM and CDMA base stations require a threshold of .05 parts per million (ppm) be maintained by their timing source in order to ensure that calls are not dropped. Unicast in addition to multicast support: When PTP was first introduced, it only specified support for multicast message exchanges between PTP clock sources and clients. However, in the telecom environment, unicast support is required in order to fine-tune and optimize network performance. With multicast, every device in the multicast group must examine every message. This means that each client must listen to every other clients messages to its master saturating client processors with messages they throw away. Since clients should be the lowest-cost elements of the synchronization ecosystem, minimizing the amount of processing power required is a priority

and so too is minimizing the amount of bandwidth consumed. Unicast support helps achieve these objectives. Higher message rates: Based on the first version of the standard, IEEE 1588 masters and clients send message packets every 30 seconds by default. Telecoms much higher timing requirements, however, call for commensurately higher message rates (up to 64 times higher). The required frequency is dependent on several factors, for example, the performance of the client device, the stability of the clients local oscillator, and the amount of noise on the network. A good starting point is 16 messages per second and to adjust from there based on bandwidth availability and timing performance. A grandmaster clock must therefore be able to both sustain high message rates for potentially thousands of clients and also allow operators to adjust those rates as needed. Shorter message formats: The timestamps in the first version of IEEE 1588 were 165 octets and included information about the source and quality of the clock. As the source and quality dont change often, IEEE 1588-2008 separates the message into two components: 1) an announce message with details about the clock, and 2) a smaller 44 octet PDU for synchronization messages. Trimming the message size thus allows the telecom provider to achieve the higher message rates required while minimizing the bandwidth required to do that. Best grandmaster algorithm: It is possible that PTP clients and grandmasters will lose their timing reference due to network outages or other reasons. IEEE 1588-2008 specifies that clients support a best master clock (BMC) algorithm. This enables the device to scan the network and identify the best possible reference available as a replacement taking into account the quality of the timestamps received as measured via special message exchange.

Node B/BTS

Mobile Switching Center

Ethernet Switch

Ethernet

Ethernet

Embedded IEEE 1588 Client

Base Station Controller/ Radio Node Controller

Ethernet Ethernet

Node B/BTS Embedded IEEE 1588 Client

Node B/BTS Embedded IEEE 1588 Client

Ethernet/IP Network
SSU
Integrated IEEE 1588 Management and Performance Metrics

Ethernet

Ethernet

Ethernet Switch
Ethernet Ethernet

Node B/BTS

Boundary clock
T1/E1 sync reference
Ethernet Ethernet Node B/BTS

Grandmaster

FIG 1: Shows a typical grandmaster and boundary clock PTP implementation.

IEEE 1588 Translator

T1/E1 sync reference

Best Practices for IEEE 1588/PTP Network Deployment

Specified transport over more network layer protocols (e.g., UDP/IPv4, UDP/IPv6, Ethernet): IEEE 1588-2008 gives operators the flexibility to specify alternative network layer protocols over which to route synchronization traffic. This allows operators to better manage how they allocate resources according to packet type and network transport availability. IEEE 1588-2008 telecom profiles provide service providers and network equipment manufacturers with the ability to fine-tune timing and synchronization parameters to meet the requirements of their specific applications and are an indispensable component of any comprehensive PTP solution.

dynamic mode, PTP clients initiate requests for resources from the grandmaster or boundary clock and auto-negotiate for allocation of available resources. In order to allow maximum network performance and optimization, PTP clients should support both static and dynamic reservations to ensure optimal network performance and efficient allocation of network resources. IEEE 1588 clients may be implemented in several different ways. The simplest and least intrusive implementation is a PTP translator. A PTP translator is essentially a client-in-a-box. It is a standalone device that has a PTP-over-Ethernet interface for communicating with the PTP grandmaster or boundary clock and multiple T1/E1 interfaces for communicating with legacy TDM-based end-point devices, such as base stations that lack a native PTP client on board. The advantage of implementing a PTP translator solution is that it enables network service providers and equipment vendors to transparently implement Ethernet backhaul at a very low cost without having to make any modifications to existing legacy end point devices. The end point device thinks it is still communicating over a legacy TDM line while the translator transparently performs the TDM-to-Ethernet conversion. Alternatively, native IEEE 1588-2008 clients may also be sourced off-the-shelf from any number of third-party PTP client vendors. By virtue of the fact that PTP is a standard, any PTP compliant third-party client should, in theory, be interoperable with any PTP compliant grandmaster clock. The operative word here is should. There may be instances where a vendor updates their PTP client implementation without completing thorough interoperability testing with the IEEE 1588-2008 grandmaster vendor beforehand which could result in unforeseen interoperability problems, and in extreme cases, a potential disruption of critical services. A third means of implementing PTP clients is to purchase an IEEE 1588-2008 client development tool kit and software licensing rights from an IEEE 1588-2008 client software vendor. In this case, if designed in properly, the service provider or network equipment
Client

Choosing the Right Clients

IEEE 1588 clients are software agents that reside in an end-point network edge device such as a wireless base station, DSLAM, or LTE. Clients continuously exchange synchronization messages with PTP grandmasters or boundary clocks to ensure consistently precise timing and synchronization. These message types include: Signaling Messages Sync Messages Delay Request Messages Delay Response Messages Management Messages Figure 2 illustrates the types of PTP messages that are typically exchanged between the grandmaster clock and its PTP clients. IEEE 1588-2008 also defines the attributes that clients must support to comply with the protocol standard. Support for both multicast and unicast communications, as explained earlier, is one example of a PTP clients attributes. Another is the ability to support both static and dynamic resource reservations. In static reservation mode, the grandmaster interacts with a specified list of statistically allocated clients and controls the allocation of resources to each one. In
Server
IEEE-1588 processor

Master
t1

Network
Sync follow_up

Slave

IEEE-1588 processor

Network protocol stack & OS

t2

Network protocol stack & OS

Sync detector & timestamp generator Physical layer

t3 t4
delay_req. delay_resp.

Sync detector & timestamp generator Physical layer

Ethernet/IP Network
Master clock sends: 1. Sync message 2. Follow_up message 4. Delay_resp. message Slave clock sends: 3. Delay_ req. message

FIG 2: The PTP message exchange.

Best Practices for IEEE 1588/PTP Network Deployment

vendor can port IEEE 1588-2008 client software directly onto its existing hardware platform, such as a legacy base station, without the need for additional software or circuit board upgrades. As is the case with sourcing any third-party client solution, the service provider or network equipment manufacturer must assure continued interoperability and compatibility between the grandmaster and client vendors as they introduce new features and new software releases. In many cases, service providers and network equipment vendors may choose to implement a hybrid client solution, where a mix of

native PTP client devices and translators coexist within the same network infrastructure. Figure 3 illustrates a typical hybrid PTP solution consisting of a combination of native PTP client devices and PTP translators. This type of solution is only possible, however, if all PTP network components from grandmaster to boundary clocks to clients remain in lock step with respect to their release levels and supported feature sets.

Node B/BTS

Ethernet

Ethernet

Mobile Switching Center

Ethernet Switch

Embedded IEEE 1588 Client Node B/BTS

Ethernet

Ethernet

Embedded IEEE 1588 Client

Node B/BTS

Ethernet

Ethernet

Embedded IEEE 1588 Client

Node B/BTS SSU

Integrated IEEE 1588 Management and Performance Metrics Grandmaster

Ethernet

Ethernet

IEEE 1588 Translator

Ethernet

T1/E1 sync reference

Ethernet

Node B/BTS

FIG 3: A hybrid PTP client solution.

IEEE 1588 Translator

T1/E1 sync reference

Best Practices for IEEE 1588/PTP Network Deployment

Managing Your PTP

An obvious consideration when adopting any multi-vendor PTP-based solution is how to manage it. The risk is that network operators could end up with a hodgepodge of IEEE 1588 network elements, each with its own unique management interface for configuration, monitoring and control. A better approach is to have complete end-to-end visibility across all PTP network elements from grandmasters to boundary clocks to remote clients as well as a robust set of network performance metrics and monitoring tools. A unified PTP management approach offers a compelling set of operational advantages including the ability to perform end-to-end

performance analysis and troubleshooting along with the ability to manage all aspects of the PTP network including: Faults and alarms Configuration Accounting Performance metrics Security Inventory management Software downloads Figure 4 illustrates a unified management approach which provides complete end-to-end visibility of all IEEE 1588 network elements under a common network management umbrella.

Web client

Web client

Web client

Web client

IEEE 1588 Network Management server

FCAPS

TL1 TL1 SSU PTP TimeHub PTP

TCP/IP Network
SNMP

SNMP IEEE 1588 Grandmaster Clock

Node B/BTS

1588 mgmt msg

1588 mgmt msg

1588 mgmt msg

IEEE 1588 Client

IEEE 1588 Translator

IEEE 1588 Translator

IEEE 1588 Translator

IEEE 1588 Translator

IEEE 1588 Translator

IEEE 1588 Translator

FIG 4: Unified PTP element management.

Best Practices for IEEE 1588/PTP Network Deployment

IEEE 1588 Deployment Best Practices

IEEE 1588-2008 sets a new and improved standard for packet-based synchronization. It also challenges telecom vendors and service providers to employ best practices to meet that standard. As a general rule, the best PTP network designs reduce the number of hops between grandmaster clocks and their clients to minimize packet timing deviation delays. Network planners will also want to consider the maximum number of active clients supported per server under various failure conditions such as when the best grandmaster algorithm is invoked. To ensure best network design, network service providers and network equipment manufacturers may also wish to consider several other factors when planning out their PTP deployment: Distributed grandmasters: Where excessive hops cannot be avoided, network planners should consider using boundary clocks and/ ortransparent clocks to mitigate network delays. Using a boundary clock, for example, eliminates the need to install a GPS receiver at every location thereby reducing the extra expense and regulatory headaches associated with GPS installations. Redundancy planning: The IEEE 1588-2008 grandmaster algorithm allows clients to seek out an alternative master if the original master fails or is blocked by network noise. However, in some circumstances, operators may choose to define a different algorithm or to manually configure clients to synchronize to a specific grandmaster. For example, it may be better to have all clients switch to the same alternative master rather than have each client listen to different masters. Adjusting the frequency of timing messages: As previously described, if grandmaster servers allow it, network operators can adjust how often to send timing messages over the network, thereby assuring precise time synchronization with the minimum bandwidth overhead. Different Holdover Options: Holdover defines how a network elements oscillator can maintain its accuracy after losing its primary reference source such as a GPS signal. Holdover can be critical to keeping a remote device, such as as wireless base station, within operational tolerances. For example, PTP clocks with high-quality quartz oscillators, can maintain holdover for 24 hours or more while rubidium oscillators can maintain holdover for a week or more without drifting outside of spec. Best practices dictate that PTP network elements provide both quartz and rubidium oscillator options.

Carrier Class IEEE 1588-2008 Components: The PTP standard specifically calls for a fit for purpose method of timing and synchronization in telecom applications. That implies timing solutions, specifically grandmaster clocks and PTP clients, are also fit for this purpose. It also means providing carrier class hardware, software, and management components that can provide the highest level of performance, reliability and serviceability. These include: Redundant power supplies Redundant clock modules Scalable architecture Downloadable software 24/7 technical support Worldwide onsite service coverage Hardware and software warranties Remote network management and diagnostics Clearly, if service providers and network equipment vendors are to meet the challenge of providing precise timing and synchronization solutions in an Ethernet world, they must go above and beyond the minimum requirements called out by the IEEE 1588-2008 specification. Mere IEEE 1588-2008 compliance alone is not enough. Rather, they must strive to build complete end-to-end PTP solutions that not only provide the highest level of timing and synchronization accuracy but also incorporate the carrier class reliability, resiliency, scalability, and seamless network management that next generation PTP applications will demand.

More Background Reading on PTP

Please refer to these other white papers on IEEE 1588 at www.symmetricom.com. 1. D  eployment of Precision Time Protocol for Synchronization of GSM and UMTS Base Stations, Symmetricom white paper, May 2008 2. A  dvances in Backhaul Synchronization - Maximizing ROI, Symmetricom white paper, May 2008

Copyright 2009 Symmetricom, Inc. All rights reserved. Symmetricom and the Symmetricom logo are registered trademarks of Symmetricom, Inc. All other trademarks are the property of their respective companies. All specifications subject to change without notice. 03-18-09

www.symmetricom.com
7

Phone: +1 408 428 7907; toll-free: +1 888 FOR SYMM | Fax: 408-516-9597 | E-mail: [email protected]