Industrial networking - PRP and protocol maximum latency requirements

[Joachim Stenhjem]

We are designing a new industrial network and are planning to use PRP for redundancy. The network will span between different sites and the two involved WAN links, A and B, will have different latency. By design recommendations, I'm aware of the use identical ring structure, but have not found any statements for maximum acceptable latency between the different A and B routes.

Any knowledge or articles for PRP maximum acceptable latency between the different A and B routes?

[Joseph W. Doherty]

Hmm, PRP redundancy, what's that?  (I think to myself, so, I did some quick research . . .)

I, too, could not easily find any mention of specific acceptable, or not, time deltas between receiving duplicate packets.  From my reading, it seemed to be implied that there are such limits, and also implied, they are often generous.

Since I did not do a deep dive into the underlying specifications supporting PRP, it's possible, the way it works, there are no absolute values regarding time deltas, i.e. it might be left to the individual implementation to use whatever seems reasonable, and/or, such values might be configurable.

This because, basically, PRP generate duplicates, that something on the receiver needs to ignore/drop.  I.e. the receiver's major issue would be how many unique IDs can you "sit on", waiting for the expected dup to release.  How long that takes isn't directly relevant, but the longer your wait, the more such IDs you may need to "sit on".  (I.e. a receiver resource issue.)

There is a small wrinkle to "sitting on" no dup yet IDs, PRP uses a 16-bit sequence number, which if it wraps, can lead to no longer being able to tell, by that value, alone, whether same frames with identical sequence numbers are, in fact, dups.  (Implementation, could, I presume, also use something like a CRC to further identify matching frames, but, I suspect, the specification may not require this.)

You also have a problem if the receiver "times-out", no dup yet IDs, prematurely.

Again, unless the underlying specifications actually provide specific limits, the answer might very well might depend on device's PRP implementation.

With the forgoing in mind, I did read, it's highly suggested that the dual paths are as identical as possible.  This, I presume, is to minimize timing differences and resource capacity issues.

Since timing differences may be important, and you have two WAN links, with QoS, you might be able to make their overall latency similar across either.  For example, you (if equipment supports) might "shape" the lower latency link so that its latency better matches the higher latency link.  (BTW, how much of a time delta are you expecting?)

Further, if the WAN link is being shared with other traffic, QoS might also better guarantee a more consistent link latency for the PRP traffic.

I.e. anything you can do to minimize "differences" between the two alternative paths, appears to be worthwhile.

[Joachim Stenhjem]

Hi, Joseph
Thanks for your reply. As you say, the recommended design is identical nets for A and B. In my case my customer does not have that ability to have identical networks due to geographical locations.
The big question is what is the acceptable delta latency between the two routes.

[Joseph W. Doherty]

"The big question is what is the acceptable delta latency between the two routes."

Understand, and, like you, I could not find a definitive answer.  Personally, I suspect it might be implementation (of PRP) dependent.

Also understand a latency delta, especially when transiting WANs being primary concern, but, again, possibly QoS might be able to minimize such differences by making the "faster" path's latency be similar to the "slower" path's latency.

Beyond that, you either need to just try, to determine what actually happens (far from an ideal approach) or (perhaps better) have the equipment vendors, of the PRP devices, describe any limitations and/or commit to meeting specified allowances.  (One would hope equipment vendor can describe how their equipment will, or will not, perform.)