GOOSE getting lost?

How many times have you heard people say "my GOOSE got lost (somewhere in the Substation LAN)".

The good news is that they are all still there but may go hiding because of the way the switches are configured so what GOOSE goes into a switch may not necessarily come out looking like the same GOOSE or not at all.  This all depends on lots of settings - both of the IED itself, its GOOSE message and the switch ingress and egress ports for that message.

As a first reference, IEC 61850-90-4 provides some good information and examples of "lost GOOSE".

It is then important to understand is that Substation Automation System LAN is configured to operate differently to "normal" industrial Ethernet. 

1. Message from IED sent with or without VLAN and Priority Tags

Industrial Ethernet has generally assumed that IEDs send untagged frames i.e. there is no VLAN ID (VID) or Priority tag (PCP) field in the frame at all – refer http://en.wikipedia.org/wiki/IEEE_802.1Q .  Consequently the switch can use EDGE port configuration for connecting all the devices to the switch.

Consequently the switch can decide to add or remove these tags at different ingress and egress ports through the progression from one switch ingress port internally to another egress port, or from one switch egress port to another switch ingress port, to suit the way we need the switches to manage the signals from end to end. 

However in an SAS, we decide to use the capabilities of Ethernet tags far more prescriptively all the way from the source IED to the destination IED - yes we are taking total control of the message rather than leaving it to "normal" Ethernet approach.  Hence this is why you need specialist IT nerds who understand us "control freak" substation nerds requirements, or substation nerds who truly understand enough of the Ethernet technology (which is way more than an IP address)

So in an SAS, we will configure (some) messages from the IED as

1. Untagged (no VID and no PCP field in the frame – arguably “standard” industrial Ethernet practice),
2. Tagged messages (has 1<=VID<=4094 and 0<=PCP<=7) or
3. Priority Tagged (VID=0 and 0<=PCP<=7).

Then comes the tricky stuff of the switch configuration.

The switch port may be an EDGE port or a TRUNK port so depending on subsequent combinations of further settings the message may or may not get into the port and out another port.

The switch port has a default Port VLAN Id (PVID) and a default Port Priority (PPCP) setting.

2. Ingress control

Message type

The port can also be set for Ingress filtering to

1. “Admit all”  (VLAN Unaware) or
2.  "Admit Tagged only” or
3.  “Admit Untagged or Priority Tagged Only”

Since we usually set GOOSE with both VID and PCP as a Tagged message would probably not get into a port configured as 3) so GOOSE may be totally blocked and not appear on any egress ports at all.

Switch enforced forced tagging

Now, the whole thing is that switches don’t like seeing frames where there is no VID setting (none or VID = 0) so, internally, it turns the message into a fully Tagged message so that it can work out what to do with it as an egress message.

1. if it is only Priority Tagged on ingress, the switch will “internally” force the message VID = PVID i..e it changes the VLAN of the message from a value of VID=0 (no particular VLAN) to match the switch port setting PVID. 
2. If it is an Untagged message, the switch will internally force the message VID = PVID and PCP = PPCP i.e. it adds the extra tags to the message according to the ingress port defaults.

3. Egress Control

The question then is how does the switch Egress the message out the other ports?

MAC Address learning vs Multicast

First is that the egress port will have first learned where all the destination MAC Addresses are in respect to the different ports so that traffic flow is optimised. So if the message is directed to a specific individual MAC address, the egress message will only go out the port where it knows will eventually lead to reaching the destination in the shortest time.  This is a process called MAC Address Learning and is important for client-server type communications such as SCADA-to-IED communication.

On the other hand, Multicast messages (such as GOOSE) are intended to go every where on the network and so in principle we expect them to egress out all ports of the switches.  As Multicast the receiving IEDs may or may not subscribe to that message and act accordingly to the configuration of the receiving IED (refer GOOSE is not a command). 
The other form of message is the Broadcast (rarely used) where the message would also go out all ports but all IEDs must receive it.

However although the multicast message has the possibility of egressing on all ports, it might not, and the tags (VID, PCP) might be changed or even dropped completely from the message.

Multicast Filtering

As we know, according to the recommendations (i.e. you might choose differently) of IEC 61850-8-1 Ed2 Table B.1, GOOSE can be set to the Multicast MAC addresses in the range
01-0C-CD-01-00-00 through to 01-0C-CD-01-1-FF
i.e. there are 512 possible GOOSE MAC Addresses
Also Sampled Values are published to 01-0C-CD-04-00-00 through to 01-0C-CD-04-1-FF as another 512 addresses
So we can configure the port to only egress messages intended for certain Multicast MAC addresses - therefore some ports will not egress the multicast GOOSE/SV messages - they will "disappear" from that part of the network completely.

VLAN Control

Next is that if the egress port has a PVID matching the VID of the internal message, the message will be allowed out that port – that it is the VLAN process so again, the message will "disappear" from that part of the network completely..

EDGE or TRUNK tag dropping

If it is an egress EDGE Port, it will strip out the Tags – i.e. it will send the message as an Untagged message … arguably not a problem even for GOOSE because the message has got to where we intended but it will look different to what was sent as a Tagged or Priority Tagged message by the publishing IED. 
It may be a problem if the subscribing IED is looking for a message WITH the VLAN tag still in it.

If it is an egress TRUNK port,then if the port is configured as

1. Forward Tagged, it will retain the VID and PCP tags of the internal frame (note: which may or may not be the same as the received tags on the ingress port)
2. Forward Untagged, then either: 
   1. if the internal frame has VID not the same as the PVID, then it will forward the frame unchanged from the internal frame as a fully Tagged frame, or
   2. if the internal frame VID = PVID, then it will strip both VID and PCP tags and send as an Untagged frame (the implication is that since the next receiving switch knows the PVID of the switch from which the message egressed, then obviously the VID must have been the value of the egress port PVID – totally logical!)

TRUNK ports, then can handle sending messages to more than one VLAN.  So the egress ports can be set with a Port VLAN Member Set (or the inverse is that it is configured with Forbidden VLANs).  The PVMS identifiers all the VID that will be allowed to egress that port. 
As a result we would generally use TRUNK ports for switch-to-switch connections to allow multiple VLANS to flow around the network. 

However, since we usually have IEDs in an SAS that are subscribing to messages on multiple VLANs, our SAS tend therefore to connect IEDs to TRUNK ports.  Here again you can see the difference between SAS Ethernet usage and “normal” industrial Ethernet where end devices are connected to EDGE ports.

Easy!!

Extra Notes: