What’s in the 2019 edition of IEEE 1588: Profile isolation

Five Minute Facts About Packet Timing

Next in the series on What is in the 2019 edition of IEEE 1588 is profile isolation.  And while we are looking at that we will take a peak at the PTP common message header, the part of PTP message which has  the same structure regardless of which PTP message type it is part of.

So what is profile isolation?  Here is the problem: If two or more PTP Profiles, which use multicast messages, are in the same network, then the PTP nodes will see PTP messages from profiles which are not of interest.  That could wreak havoc with the Best Master Clock Algorithm, for example.  The current way to solve this is to configure each profile to operate in a different PTP domain.  That works if the network operator has time to pay attention to the PTP domains of profile running on their network.  If you are a network operator, then you are so busy that you barely have five minutes to read this post, so you know that is a dangerous for equipment vendors to assume that you will track PTP profile domain numbers.

If you want to be sure that profiles of PTPv2.1 do not interact you can use the new profile isolation feature.  And when I say “you,” I mean some one who is on a standards committee working on a PTP profile, because that is where it gets done.  The idea is this: A Standards Development Organization, or SDO, can apply for a globally unique number, the SdoId which appears in the common header of all PTP messages.  PTP nodes can then ignore all messages which do not have the SdoID they want.  You get these numbers from the IEEE Registration Authority.  These are the folks which are in charge of parceling out certain globally unique numbers such as Ethernet MAC addresses.  The idea is that each SDO can get a SdoID, then protect its own various profiles from each other using rules on domains.  Before you rush to the Registration Authority to get your number be advised that they will only give you one if they judge that you represent a standards development organization.  So organizations like the IETF, the ITU, and the IEC would be able to get one, but not equipment manufacturers, or network operators. 

Those of you paying close attention might be concerned that we added a field to the PTP common message header, possibly breaking backward compatibility.  Don’t worry, we did indeed add a field, but preserved backward compatibility.  Here is how we did it.  Tables 1 and 2 show the PTP common message header for PTPv2 and PTPv2.1 respectively.

Note that the PTP SdoID is split into a four bit field and an eight bit field.  The four bit field was previouosly the transport specific field which distinguished the IEEE 802.1AS profile from all other PTP profiles.  In the revision we are generalizing that concept to cover profiles from any SDO.  The other part of the SdoId uses a field previously defined as reserved.  Note anything marked “reserved” in IEEE 1588 is place holder reserved for use in a future revision of 1588.  

Not also that we are added a four bit minor version number field.  That will allow PTP nodes to distinguish PTPv2 and PTPv2.1 messages.  If a PTPv2 node which doesn’t know about PTPv2.1 receives a PTPv2.1 message, it will ignore the minor version number, since that was previously a reserved field.

So if you are writing a PTP profile, don’t forget to pick up your SdoID.

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com or visit our website at www.meinbergglobal.com.

By Doug Arnold