The GSE/SMV over UDP/IP SCL definitions contain the following issues:
1) VLAN-PRIORITY and VLAN-ID are defined only for the publisher LAN. There is no definition of VLAN priority and VLAN-ID for the subsriber side. It is not explicitly specified but due to the lack of definition it is assumed that R-GOOSE/R-SV packets are always sent without VLAN tag at the subscriber side. This is a disadvantage.
2) The GOOSE/SV address parameters are defined with per stream granularity, not considering the IP address and VLAN information configured at the publisher's sending interface. This may violate the general rule of IP communication that IP packets sent by hosts contain
the address information of the sending IP interface. Edge routers may drop multicast packets in case of IP address mismatch as result of the RPF (reverse path forwarding) check.
Please find the details in the attached problem statement document.
Proposal
The proposed solution is contained in the attached solution proposal document.
Discussion
Created
Status
I agree, and the "local issue" is addressed in the proposed solution.
The proposal suggests using the VLAN information from the subscriber’s IP interface to regenerate VLAN tags at the edge router of the subscriber’s LAN. This is accomplished by having the subscriber send IGMPv3 Membership Reports either untagged or VLAN-tagged, depending on the VLAN configuration of its IP interface. The edge router’s LAN-side interface must be configured accordingly to interpret these tags.
This approach enables R-GOOSE and R-SV packets to be transmitted with distinct VLAN information for each subscriber LAN, or even per individual subscriber or IP interface. Importantly, this method does not require any modifications or extensions to the SCL.
07 Nov 25
Triage
I understand the original issue is "How do I re-generate the VLAN tagging information within the destination LAN because UDP/IP mechanism will not transmit the VLAN information from the source LAN". If so then this would be a local issue with the network engineer.
For example, the destination LAN might require a different priority than that present in the source LAN.
Furthermore, note that each subscriber LAN might require different "re-generated" VLAN/PRI parameters. This is the reason it must be left as a "local issue" (because SCL cannot encode unique information for every subscriber.
06 Nov 25
Triage
VLAN tagging of frames by transmitting IEDs offers significant benefits for stream-level traffic segregation, prioritization, path management, and supervision within the LAN. This capability is especially relevant in light of recent advancements in automated substation LAN management, as outlined in IEC TR 61850-90-22.
To the best of my knowledge, priority tagging was introduced to decouple IED engineering from network management. As already mentioned in my previous comment, the known drawback is that all streams lacking a VLAN tag are mapped to a single VLAN — the Port VLAN — limiting granularity in traffic handling.
06 Nov 25
Triage
A receiver cannot rely on the fact that a VLAN tag is even delivered to him, so it must not work depending on that.
VLANs are a thing of the network, not of the connected IEDs.
Tagging packets already at the sender is an uncommon practice, limited to some specific cases (e.g. servers serving clients residing in different VLANs, and then this is handled at the network port configuration, not at the application configuration).
What we did with GOOSE etc. in IEC 61850 is not a foreseen use of VLANs and in hindsight, we probably should have stayed away from it. The intention back then was to benefit from the priority tagging. Segregating traffic into different VLANs was not the goal. Looking at the actual benefits from the priority tagging (especially when using higher link speeds), it was not worth it.
06 Nov 25
Triage
In my understanding, we need to distinguish between the transmission of Layer 2 (L2) and Layer 3 (L3) multicast frames/packets with VLAN tags over a LAN, and the potential for receivers to ignore these VLAN tags.
By default, L2 and L3 multicast frames/packets are broadcast (flooded) across the entire LAN unless specific measures are taken. VLANs help limit the broadcast domain and, through appropriate switch configuration, enable a 1:n communication path from the sender to the receivers in the LAN.
For L2 GOOSE and SV frames, the publisher IED can define the VLAN tag. Alternatively, VLAN tagging can be applied by the connected switch using Port VLAN configuration. However, this method is not selective, as it maps all ingress untagged or priority-tagged frames the Port VLAN. The subscriber IED, located within the same substation LAN, is generally not involved in VLAN handling and may ignore the VLAN tag of received multicast frames.
In contrast, R-GOOSE and R-SV packets are usually exchanged between publisher and subscriber IEDs located in different substation LANs, interconnected via a WAN. The VLAN tag of R-GOOSE/R-SV packets is typically lost when traversing the IP WAN and must be re-established in the subscriber LAN. This can be achieved using a Port VLAN on the switch connected to the edge router. However, this approach is also non-selective, as it maps all traffic from the edge router to the same VLAN.
The proposed solution introduces a more selective VLAN handling mechanism, where the subscriber IED determines the VLAN to be used on the path between the edge router and itself. Unlike the L2 case, this cannot be managed by the publisher IED, as it is typically not present in the subscriber LAN.
06 Nov 25
Triage
There shall be no VLAN definitions for the subscriber side.
Depending on how the network handles the VLAN tags, the subscriber even may not even receive VLAN tagged packets.
The subscriber must be agnostic to VLANs, i.e. it must accept the packets with or without VLAN tags and if they are present, not check the VLAN tags.
We had this topic more than 20 years ago with GOOSE and we decided that GOOSE subscribers must me "VLAN agnostic".