While the IEEE 1588v2 specification can no longer be considered a new standard, its presence is still felt in new application areas. The scope of the standard is expanding into emerging and existing markets such as Smart Grid, telecommunications, industrial manufacturing, audio/video bridging, and data centers, and as a result, many companies are developing products that implement the standard. As implementation of IEEE 1588v2 continues to expand across various industries, the presence of interoperability issues also increases. This scenario has been illustrated in the past by other standards that experienced a similar uptake in broad market adoption.
Observing interoperability problems is a great complement to simple conformance testing as interoperability issues can be easy to spot and can help engineers quickly hone in on the areas of conformance that need to be double checked. This is especially true for technologies where conformance testing is not available, not possible due to technical limitations or time constraints, or where testing is artificially limited by certification requirements that do not require 100 percent compliance to a standard.
Some recent IEEE 1588v2 interoperability testing has helped quickly identify problem areas in devices under development. The scenarios all start with three devices in a small network where M1 represents the best master clock, M2 represents the second best master clock as determined by the best master clock algorithm, and S represents a slave-only device on the network:
- Disconnecting M1 results in the other two products, M2 and S, establishing a new hierarchy with M2 as the new grandmaster. S loses synchronization, falls silent and must be manually reset before synchronization can be re-established.
- In the previous three-clock configuration, when M1 is reconnected it becomes grandmaster again. However, under some conditions M2 does not relinquish its master status, so the network sees Announce and Sync messages from two masters at the same time.
- M1 sends Delay_Resp messages with logMessageInterval equal to -2 ("Respond to my Syncs every 1/4 second."). S treats the negative number as an unsigned byte, misinterpreting the -2 as 254, and so waits 2254 seconds between Delay_Reqs.
- When product M1 is master and has its portDS.logMinDelayReqInterval set to 3 ("Respond to my Syncs every 8 seconds."), product M2 behaves accordingly, sending Delay_Reqs every 8 seconds. If product M2 is adjusted to become a better master than M1 and consequently becomes master, and if its portDS.logMinDelayReqInterval is set to -2 ("Respond to my Syncs every 1/4 second."), then product M1 behaves accordingly. However, if the adjustment is reversed and M1 becomes master again its portDS.logMinDelayReqInterval remains at -2, even if its logSyncInterval is higher, say 0. This results in M1 sending Sync messages once per second and yet inviting slave devices to respond to those Syncs every 1/4 second, which clutters the network with redundant Delay_Reqs.
While all four of these scenarios should be caught by comprehensive conformance testing, they were all easily identified in a multi-vendor interoperability scenario.
For more information on testing the IEEE 1588v2 specification, please visit our IEEE 1588 Consortium page.
Jeff Lapak, Ethernet Manager