Architecting the Metro Edge for Accurate One-Way Frame Delay Measurements

Sep 16, 2013 by Prayson Pate

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:

  • The accuracy is lower than may be achieved with GPS.
  • The packet-based methods assume physical symmetry for calculating the ToD offset of the slave with respect to the master.  If there is asymmetry in the path, it will introduce an offset error in the ToD.

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:

  • “The NTP synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.” [1]
  • “Like all message-based time transfer protocols, PTP time accuracy is degraded by asymmetry in the paths taken by event messages … Specifically the time offset error is 1/2 of the asymmetry.” [2]

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.

  • The timing packets are forwarded at a high priority, and their timestamps are adjusted by boundary clock devices to minimize jitter.  They should experience minimal delay variation due to queuing.
  • In contrast, the One-Way Frame Delay packets are given the same CoS marking and treatment as the data stream that they are measuring.  They will experience the same delay variation and loss as the user packets they simulate.  As such, they can provide an accurate measurement of the delay and delay variation experienced by the user traffic of interest.

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:

  • TDM/PDH: T1/E1, DS3/E1, Linear SONET/SDH
  • EoC: G.SHDSL
  • Fiber: 100BASE-FX, 1000BASE-SX, 1000BASE-LX, etc.

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:

  • ADSL
  • VDSL/VDSL2
  • GPON

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 [3],

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.

Conclusion

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.

 

References

[1] Wikipedia, “Network Time Protocol

[2] IEEE 1588v2, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” July 2008.

[3] 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
 

Comments

Join the discussion! ... ...

Join the discussion! ... ... See the "Carrier Ethernet" group at LinkedIn.

http://www.linkedin.com/groups/How-does-architecture-metro-edge-77819.S....

Post new comment

The content of this field is kept private and will not be shown publicly.
By submitting this form, you accept the Mollom privacy policy.
To prevent automated spam submissions leave this field empty.