Ethernet Network - QoS and packet priority

AustralIan

Member
Join Date
Jan 2013
Location
Leipzig, Germany
Posts
1,367
Hi team,

After some info on what people are doing these days for ensuring control related communications are prioritised over less critical network traffic. For example if you have PLC to PLC comms on the same network as SCADA configuration file transfers, what methods do you use to ensure PLC to PLC comms are prioritised over windows file share?
 
I have not had to yet implement QoS on any of our networks yet but I would say the best method would be a decent managed switch with QoS (all managed switches should provide QoS).

Port based QoS is probably the best for controls as everything I have ever worked on uses the same defined ports.
 
For PLC to PLC comms, connect both PLC's to the same (managed) switch.
Traffic between PLC's never leaves the switch, external traffic has very little to no impact on the PLC to PLC comms.
 
Make sure you are using managed switches everywhere you can to cut down of what I call junk traffic for a layman's term. Also nothing wrong with doing Qos for your critical loads.

Another option is to segment critical traffic on it's own VLAN. Only a few years ago for example it was a best practice from AB and other hardware vendors to put SCADA systems and multi client HMI's on a separate network from PLC, I/O and Drive traffic.

In the AB world for example many people would have an ENBT or similar for their HMI and SCADA traffic and another ENBT for PLC, I/O and Drive traffic and the Controllogix Backplane could access both.

The same can be done with VLAN's on managed switches if your Switches have that capability. Just another option for you to consider
 
On the Rockwell's Stratix switches there are macros that prioritize CIP data over all other traffic save PTP. Cisco industrial switches have similar macros for CIP traffic.

QoS for the most part doesn't really kick in until the network sees heavy traffic. A VLAN generally is the best and probably easiest method to isolate traffic.

OG
 
Segmentation: Logical is not Physical

A small but important distinction to be made here is this...

Isolation, or Segmentation of network traffic is not the same thing as prioritizing network traffic (QoS).

While Segmentation, as in IP Subnetting, logical VLANs, physically separate communication modules in a chassis, is indeed important to aid in isolating critical control-related network traffic from unnecessary secondary or tertiary network traffic, it cannot aid in prioritizing critical data packets that must traverse the physical network. This is where Quality of Service (QoS) comes into play.

For instance, using logically segmented VLANs, one node may be connected to a switch in one part of the installation while assigned to VLAN 10. Another node may be connected to another switch in another part of the installation and also assigned to VLAN 10.

These two devices are control critical with regard to each other. Let's say a controller and a remote servo.

Just because they are logically on the same VLAN does not mean they are physically isolated from other traffic on the network. To communicate with each other their data packets will have to traverse the physical network. This may involve several routed hops through other appliances that are also servicing regular non-critical traffic.

In these cases, to ensure that the data packets between these two high priority CIP devices take precedent over the non-critical traffic, QoS is implemented. QoS is basically the management of bandwidth. QoS can be configured in a managed switch as a Data Flow or as a User Prioritized List.

More importantly, many of Rockwell's newer Embedded Ethernet devices that support DLR also support built-in QoS as standard. An example would be a 1756-EN2TR or a 1794-AENTR.

Of course the Stratix switches support QoS, as OG has mentioned, but it is equally important, for added efficiency, that end device connection points can also tag the CIP data packets as priority packets. These devices will automatically mark the header of a CIP data packet with a priority assignment before transmitting them out onto the physical network.

A managed switch, configured for QoS, will then read the CIP packet header and add it into its relevant high priority queue. "Relevant" because it may have to go into one queue, or another, depending on the CIP packet type...

Going one step further, CIP data packets can be prioritized according to their CIP packet type. We may have control-critical CIP Motion, CIP Safety and CIP I/O data packets all needing to be more finely prioritized. This is achieved by the different priority markers assigned to the packet headers by the QoS devices...

CIP Control I/O is marked 'high CIP 1'
CIP Safety is marked 'scheduled CIP 2'
CIP Motion is marked 'urgent CIP 3'

A QoS enabled switch can then quickly determine the relevant high priority queue to place each CIP packet type in.

The network traffic does not have to become heavy before QoS is applied. Once enabled, it is actively prioritizing each and every CIP packet according to its type and irrespective of bandwidth usage. The switch is queuing and forwarding all these CIP packets at their necessary priority level. Even if 100% bandwidth is experienced, the priority for these packets is maintained to ensure they are delivered in as timely a fashion as is possible.

To advance the implementation of QoS in end devices, the ODVA made some enhancements to the specification for an EtherNet/IP product where each product vendor now has the option to mark transmitted data packets, which will notify the switches, or other network infrastructure, of what type CIP data packet it is, and so expedite the process of queuing and forwarding the control-critical CIP packets.

This is how QoS is implemented in a modern Rockwell IACS where CIP traffic is logically traversing the physical network.

Regards,
George
 
Excellent post. :geek:

I am currently at Rockwell in Melbourne doing the IMINS2 course. Just covered QoS yesterday. I don't think I could have posted in anywhere near as much detail though. (y)
 
The above posts have been pretty expansive on methods, but they don't discuss the protocols utilized. The first post said the most important thing, though: you pretty much need managed switches.

QoS can refer to usage of two different protocols, depending whether you are declaring Your priority at the layer 2 level, in your VLAN, or at the layer 3 level, as the DSCP Tag in the IP packet. See the presentation for Rockwell below for more details. The link came up in Google, no idea where it's actually hosted.

ftp://12.192.249.152/Info/Network%20Seminar%20Documents/CPwE_Design_Considerations_QoS.pptx

From my experience on the Siemens side, Profinet traffic is automatically tagged as high priority (level 6 out of 7) at the VLAN priority level (layer), and then it makes it as VLAN ID 0, to signal a priority only VLAN Tag. this is normally for PLC to IO traffic, but it can also be used for PLC to PLC traffic.
 
mk42 said:
The above posts have been pretty expansive on methods, but...

You make it sound like I forgot something here?...

Expansive?

On the contrary, my one post is far from expansive. It merely brushes the surface of this subject matter, and that is all it was intended to do. It is far from a complete breakdown and explanation of ODVA's implementation of IEEE802.1Q/P QoS protocol, let alone Rockwell's.

I would hope that no one here reads it as being such, especially someone who knows something of the subject, such as yourself?

My main point was that Segmentation, while very important, should not be considered the same as performing QoS.

AustralIan did not specify any particular platform. I just used Rockwell as an example of how ODVA broadly implements QoS. Not only implemented at the switch level, but, importantly, also at the end device. QoS at the switch level is probably more widely heard of than at the end device, such as an embedded port. I felt it worth pointing that out here.

Your linked presentation is an excellent reference point for a further understanding of how QoS is broken down and explained, in more detail.

Something I was certainly not doing above.

Regards,
George
 
You make it sound like I forgot something here?...

Expansive?


Maybe I used the wrong word. I meant expansive as a good thing, saying a bunch of people have posted a bunch of thoughts, and there's been too much discussed for me to try to address all of it. Definitely wasn't trying to say you missed something, just trying to add a dimension to the thread that hadn't been discussed yet.

Maybe I shouldn't have been postng before breakfast. šŸ™ƒ
 
I wasn't having a go at you my friend, not at all. You have added invaluably to the thread, of which I have acknowledged.

I just would not like for anyone here to read my post and think it in any way comprehensive. I think you know my version of "expansive" by now and it is certainly not the above.

Also in the same vein...

Brendan,

Your "...could not have posted...as much detail..." comment, while complimentary in nature, is also a little worrying here, in my estimation. I would hope that if you've just been learning QoS in-depth as recent as this week, you should be able to post "something" in greater detail than I have above.

I do hope you're paying attention in class! šŸ‘ØšŸ»ā€šŸ«

QoS, in today's IACS, is all about extending the original QoS model out from the network infrastructure (switches) to the end devices (ODVA Specification), applying QoS as close to the source as possible. This further assists in ensuring deterministic delivery of critical data by creating what is known as end-to-end QoS. The more end devices that support QoS, the more deterministic the data flows may be.

What are the three basic levels of end-to-end QoS that can be provided across a heterogeneous network?

Of the three levels, which one is most widely implemented in end devices that support QoS?

Those are general questions, not directed at anyone in particular. But if you'd like to answer, Brendan, then feel free to.

Regards,
George
 
I've always quietly admired your posts, particularly the articulation and detail you go into.

My previous reply was punched out on my mobile phone in between modules in the course, so maybe my message lost a little in the excitement of reading one of your posts on a relevant topic I'm currently studying! Perhaps 'excellent detailed summary' would have been more apt?

I am aware that your post merely scratched the surface of QoS though. There is only 30 pages of content on QoS in the material for the IMINS2 course so I still have a lot to learn!

As for your question, this was not covered at all in the course and I have dug through the CPwE to find the relevant information.

The three basic levels of end-to-end QoS would be:

Best-effort service, differentiated service, and guaranteed service.

I think differentiated service would be the most widely implemented, although I believe if configured correctly the Stratix switches can provide guaranteed service for certain types of CIP traffic.

One particular thing I am not clear on is how embedded switch technology supports QoS and IGMP. I was not aware that you could do any QoS or IGMP configuration for these. Do you have any more information on this?

Even the Rockwell Embedded Switch Technology Reference Architectures document does not go into any great detail. It simply states that the QoS and IGMP protocols are supported.
 

Similar Topics

I have inherited a system that uses a Parker ACR9000 motion controller with the Ethernet PowerLink option that it uses to control five Parker...
Replies
5
Views
161
My customer wants me to set up their industrial computer hmi running factory talk view se client in the following way. They want to use a single...
Replies
11
Views
992
Hey Everyone, I need to Interface Ignition SCADA ethernet network to an Allen Bradley SLC5/04 Serial RS232 DF1. Has anyone out there found a low...
Replies
4
Views
932
Hello, folks. Looking for suggestions on network layout. I'm designing 3 stations with 6 pieces of conveyor on each. They are part of the same...
Replies
21
Views
5,684
Hi Rockwell experts. I have a customer who is using two non-Rockwell EtherNet/IP scanners for control of car-body line robots and IOs. Both...
Replies
0
Views
1,292
Back
Top Bottom