Five Minute Facts About Packet Timing
By Doug Arnold.
I recently got back from the ISPCS Plugfest. If you don’t know what this is, 33 organizations came together for three days in Lemgo, Germany to test interoperability of their IEEE 1588 enabled equipment. The annual event is part of the International Symposium on Precision Clock Synchronization for Measurement, Control and Communications. A mouthful to be sure, but that is what it takes to describe an event which brings together academia with companies from the power utility industry, the telecommunications industry, the industrial automation sector, the silicon industry, and several other industries. The ISPCS is an IEEE sponsored conference which is known for bringing together everyone who has an interest in network timing.
The Plugfest and conference were hosted by the Ostwestfalen-Lippe University of Applied Sciences. With a lot of help from University staff and students we set up the best ISPCS Plugfest room yet, which featured 5 video screens to show Wireshark traces and 1PPS measurement results. Some photos from the room are shown below.
The Plugfest room
Whiteboards with constantly updated diagrams helped us keep track of the tests. That’s my colleague Heiko Gerstung from the Meinberg Headquarters next to the whiteboard
Part of the Power Profile test network
Besides the Power Profile we also ran tests in the default profile, the Telecom Profile (G.8265), and the Enterprise Profile (under construction in the IETF). Tests included basic interoperability, rogue masters, leap seconds, network congestion, injection of alternative profiles. A lot of bugs were identified, even in equipment which has been out for several years. That tends to happen when you bring equipment from all these different industries.
A couple of issues stood out because several participants demonstrated them. One is the implementation of VLAN tags on Power Profile packets. In fact this has been an issue at every ISPCS Plugfest since we started testing the Power Profile three years ago (Yes, I know the standard wasn’t out yet).
Another common problem was observed when we tested PTP over IPv6. There are a number of multicast addresses for PTP depending on the scope of the network. It seems that every vendor picked their favorite and hard coded it. And of course we each picked a different one. Sorry folks, we are not getting off that easy. We are going to have code them all. See the list bellow:
- FF01::181, interface local
- FF02::181, link local
- FF04::181, admin local
- FF05::181, site local
- FF08::181, organization local
- FF0E::181, global local
This is the standard approach for IPv6 multicast addresses.
On a more optimistic note several new technologies were demonstrated successfully across several organizations:
- Synchronous Ethernet
- Enterprise Profile
- A combined HSR/PRP Power Profile network.
For more on the HSR/PRP result see the posting from one of the participants.
If you missed the excitement, mark your calendars for next fall. The fun will continue in Austin Texas.
Hello.
What product of Meinberg with PRP was tested in Lemgo?
When it will be available to sale?
At this time Meinberg does not support PRP directly. However, our Grandmaster clocks are capable of Layer 2, bare Ethernet PTP operation. They can be plugged into a PRP switch which is capable of converting standard Ethernet to PRP. In addition we have products available which have multiple PTP Grandmaster ports These can be connected to different switches to create a level of network redundancy.