One-way frame delay measurements are becoming increasing important for metro networks, especially for applications such as mobile backhaul. These one-way frame delay measurements require accurate time of day (ToD) at each end of the measurement. Today, IEEE 1588v2 PTP provides an efficient and economical means of distributing ToD. However, 1588v2 assumes physical symmetry in the packet network that delivers the timing packet. My paper published at Ethernet Academy explores this topic in detail, and this blog provides a brief synopsis of the paper.
The Key to Measuring One-Way Frame Delay is Time of Day (ToD)
A measurement of One-Way Frame Delay requires that the two endpoints be synchronized with respect to ToD. There are two basic ways to achieve ToD synchronization: Out-of-band (such as GPS) or inband (such as NTP or PTP).
The out-of-band methods provide some independence from the data network, but they add cost and complexity. In contrast, the inband methods have little cost impact. However, these methods do have some limits:
These limitations can be overcome by careful selection of equipment, engineering of the network, and the use of symmetric media.
The Impact of Asymmetry
When the link delays are not symmetric, then the asymmetry will introduce ToD bias:
Any One-Way Frame Delay measurements will include this ToD bias, because they are based on the ToD values at end.
The Utility of One-Way Frame Delay
It is a fact that One-Way Frame Delay cannot detect differences in the physical data path when a packet timing protocol is used and the path is shared. So, what is the value of One-Way Frame Delay?
The answer lies in the difference in the treatment of the timing packets versus the 1DM measurement packets.
Key Takeaways for Using One-Way Frame Delay and Packet Timing in the Metro Edge
Takeaway #1: Physical Asymmetry in the Access Link Can’t Be Detected Using One-Way Frame Delay.
As described above, packet-based timing protocols assume symmetry in the physical data path. Because they assume symmetry, they can’t detect asymmetry, and any asymmetry in the physical data path will introduce a bias error in the slave clock. This is the nature of the packet timing protocols, and can’t be overcome by any particular equipment or implementation of the timing. This limitation applies to part of the path shared by clock messages and measurement messages.
Takeaway #2: Symmetry in the Access Link Must be Designed For and Built In
If you need symmetry in the path it must designed in. Above all, this means using media with symmetric behavior, such as the following:
Media with asymmetric properties will introduce ToD bias that is not detectable using One-Way Frame Delay. While the bias may not be material in all cases, it should be considered during network design. Examples of asymmetric media include:
The asymmetry can be verified using an external test set with an external timing source such as GPS, but not by equipment that relies on timing packets for synchronization.
Takeaway #3: The Clock Master Should be as Possible to the UNI
The issues identified in the paper affect the part of the path shared by clock messages and measurement messages. This is why we don’t use a single timing source in the network and distribute the timing packets from there. As noted in ,
Since centrally served NTP timing packets experience the same network delays as the payload data, they are fundamentally unsuitable as a one-way delay measurement reference.
The solution is to distribute accurate sources of time throughout the network and get it as close to the client as possible.
By pushing the clock source out as far as possible you can minimize the part of the network to which these limitations applied.
For accurate and economical One-Way Frame Delay, the network must be built with minimal asymmetry. This includes both the physical path as well as the media itself. Doing so will enable One-Way Frame Delay measurements that can support the SLAs needed for modern services.
 Wikipedia, “Network Time Protocol”
 IEEE 1588v2, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” July 2008
 Symmetricom, “Accurately Measuring One-Way Delay in Packet-Based Networks”
About the Author
Prayson Pate is Chief Technologist and co-founder at Overture. Prayson is a technology evangelist with a proven track record leading teams and delivering products. Since 1983 he has been building Carrier Ethernet and telecom products for service providers and network operators around the world – both as an individual developer and as a leader of development teams. Prayson spends much of his time driving adoption of Overture’s new Ensemble Open Service Architecture, which includes aspects of automation, virtualization, SDN and NFV. He has a BSEE from Duke, an MSECE from NC State and is the holder of nine US patents.
Follow Prayson on twitter: @praysonpate
Contact Overture to learn how you can increase profitability by transforming service delivery.
Copyright © 2016 | All Rights Reserved | Overture Networks