R-GOOSE and R-SV: Routable GOOSE and Sampled Values

Classic GOOSE is fast because it’s simple. An IED drops an Ethernet frame on the LAN, every subscriber on the same Layer 2 network picks it up, and nothing in between has to think. Sampled values work the same way.

That simplicity has a hard limit: the first router. GOOSE and SV have no IP header. A router has nothing to route. So the moment a protection scheme needs to reach another substation, a control centre or a remote PMU data concentrator, plain GOOSE stops.

R-GOOSE and R-SV fix that. They carry the same GOOSE and SV messages inside UDP/IP, with a session header for security, so they can cross routed networks. This article walks through what goes on the wire, how the security works, where the specification lives today, and what to check when you design one.

For the Layer 2 versions, see the GOOSE guide and sampled values explained.

Where R-GOOSE and R-SV are defined

The names came first in IEC TR 61850-90-5, published in 2012. It was written for synchrophasor transport: getting PMU data and wide-area control signals across utility WANs using IEC 61850 instead of IEEE C37.118.

That technical report defined the routable profiles, the session protocol and the security fields. It was a technical report, though, not a standard, and it had gaps and errors.

In February 2020, the IEC 61850 Edition 2 Amendment 1 documents brought the routable profiles into the main standard, updated from the report and with several of its problems fixed. Security comes from the IEC 62351 series, with group key management in IEC 62351-9. The 2012 report is now considered deprecated.

What this means for you:

• A device claiming “IEC 61850-90-5” support was built to the 2012 report.
• A device claiming R-GOOSE per IEC 61850 Ed2 Amendment 1 (Ed 2.1) was built to the 2020 text.
• The two are close in structure but not guaranteed to work together. Ask the vendor which text they implement, and test the pair before you design on it.

The wire details below come from the 2012 report, because it’s the published document that lays them out field by field. The 2020 amendment keeps the same idea: a common session header for R-GOOSE and R-SV carrying length, numbering, version, key timing, key ID and a message authentication code.

The stack in one picture

Plain GOOSE and SV sit straight on Ethernet. The routable versions add four layers between the payload and the wire:

Layer	Plain GOOSE / SV	R-GOOSE / R-SV
Application	GOOSE APDU / SV APDU	Same GOOSE APDU / SV APDU
Session	—	Routable session header with security fields
Transport	—	OSI connectionless transport carried over UDP
Network	—	IPv4 (IPv6 optional), multicast or unicast
Link	Ethernet, EtherType 0x88B8 (GOOSE) or 0x88BA (SV)	Ethernet carrying IP

The point is reuse. The GOOSE and SV messages themselves barely change. What changes is the envelope around them.

UDP destination port 102 is used, the same port number as MMS uses over TCP. They don’t clash at the protocol level because one is UDP and the other is TCP. Firewall rules still need to say which one you mean.

Subscribers that join multicast groups need IGMPv3, so routers know which multicast streams to forward where.

The session header, field by field

Every R-GOOSE or R-SV packet starts with a session protocol data unit (SPDU). Here’s what the 2012 report puts in it.

Session identifier

The first byte says what’s inside:

Value	Payload
0xA0	Tunnelled GOOSE or SV Ethernet frames
0xA1	GOOSE APDUs (native R-GOOSE)
0xA2	SV APDUs (native R-SV)
0xA3	Management APDUs

The value 0x40 is reserved for the OSI connectionless session and isn’t used.

Common header

After the identifier and its length comes the common header:

Field	Size	What it does
SPDU length	4 octets	Total length of the session unit
SPDU number	4 octets	Counter per destination, starting at 0, wrapping after 4 294 967 295. Lets the subscriber spot lost, duplicate or out-of-order packets.
Version	2 octets	Session protocol version, 1 in the 2012 report
TimeofCurrentKey	4 octets	When the current key was first used, in seconds since 1 January 1970 UTC
TimetoNextKey	2 octets	Minutes until the next key goes live. A negative value means no new key is scheduled.
Security algorithms	2 octets	First octet: encryption. Second octet: signature algorithm.
Key ID	4 octets	Which key the key server assigned for this data set

The SPDU number matters on a WAN. On a LAN, GOOSE frames arrive in order. Across a routed network, packets can take different paths, arrive late or arrive twice. The subscriber uses this counter to catch that.

Payload

After the header comes a length field and the payload. The payload can hold one or several PDUs, each tagged:

Tag	Content
0x81	GOOSE APDU
0x82	SV APDU
0x83	Tunnelled Ethernet frame
0x84	Management APDU

Each payload entry also carries a simulation flag and the APPID, the same identifiers you know from Layer 2 GOOSE and SV.

Signature

Last comes the signature, tagged 0x85. It’s a message authentication code calculated over the whole session unit, minus the signature itself. 100 octets are reserved for it.

Native vs tunnelled

The report gives two ways to carry GOOSE and SV over IP.

Native (0xA1, 0xA2). The publishing IED builds the GOOSE or SV APDU and puts it straight into the session payload. The IED itself speaks R-GOOSE or R-SV. This is the clean way, and it’s what “R-GOOSE support” on a datasheet usually means.

Tunnelled (0xA0). A gateway takes a normal Layer 2 GOOSE or SV frame and wraps it. The tunnelled payload keeps the original destination MAC address, the VLAN tag and priority, and the original EtherType PDU. At the far end, another gateway rebuilds the Ethernet frame and sends it on the local LAN. Neither IED knows the WAN exists.

Tunnelling is useful when the IEDs only speak Layer 2 GOOSE, which is the case for many existing relays. Only GOOSE and SV can go through the tunnel. GSE management frames can’t.

The trade-off: every tunnel end is another device in the protection path, adding delay and a failure point. Make sure the gateways are in the scheme’s timing budget and its supervision.

R-SV and synchrophasors

The report was written mainly for synchrophasors, and that shows in the SV changes.

A wide-area stream needs an absolute timestamp. Layer 2 SV in a substation only needs a sample counter, because everything shares one clock. Across a WAN, the receiver needs to know exactly when each value was measured.

The report handles this two ways:

• The refresh time, sample counter and sample rate together give the measurement time. So R-SV for synchrophasors must carry all three.
• A new optional timestamp field covers devices higher up the chain, like phasor data gateways, where a sample counter makes no sense.

It also recommends the SV identifier format C37-118-<StationName>-<IDCode>, so C37.118 station and ID information can travel in R-SV.

Security: signing, encryption and keys

This is the part that makes R-GOOSE different from “GOOSE over a VPN.”

Signing

Each packet carries a message authentication code. The report allows these options:

Value	Algorithm	Length
0	None	—
1	HMAC-SHA256	80 bits
2	HMAC-SHA256	128 bits
3	HMAC-SHA256	256 bits
4	AES-GMAC	64 bits
5	AES-GMAC	128 bits

“None” is for testing only, and only allowed when encryption is in use. Never run a live scheme with it.

Shorter codes mean smaller packets and slightly less processing. Longer codes are harder to forge. The choice is a policy decision for the utility, not a technical default.

Encryption

Encryption is optional. The report lists none, AES-128-GCM and AES-256-GCM.

A common choice for protection is signed but not encrypted. A trip signal usually doesn’t need to be secret, but it absolutely needs to be genuine. Encryption adds processing time at both ends. Decide based on what the data reveals and what the scheme can afford in delay.

Key management

Publisher and subscribers share a group key per data set. They don’t make it up themselves. A Key Distribution Center (KDC) hands it out using GDOI (Group Domain of Interpretation), a group key protocol from the IETF. In the current standards, this is specified in IEC 62351-9.

The flow:

1. Each IED authenticates to the KDC.
2. The KDC gives it the key and key ID for each data set it publishes or subscribes to.
3. The publisher signs every packet with the current key and puts the key ID in the header.
4. Before the key expires, the publisher counts down TimetoNextKey. Subscribers fetch the next key in time.
5. When the new key goes live, TimeofCurrentKey updates and everyone switches.

The 2012 report describes the subscriber pulling keys from the KDC. Key management under IEC 62351-9 goes further:

• IEDs prove their identity with X.509 certificates. Certificate enrolment and revocation checks (for example SCEP and OCSP) are part of the picture.
• The KDC can push or pull keys, and delivers the current and the next key together. A 24-hour rotation is typical.
• Key delivery assurance lets the KDC confirm every subscriber has the new key before the publisher switches to it. That closes the gap where a subscriber missed the update and starts rejecting good packets.

The network underneath

R-GOOSE and R-SV only work if the network does its part.

Multicast routing. Most schemes publish to an IP multicast group. Subscribers join with IGMPv3. Every router on the path needs multicast routing turned on and configured. In many utility WANs it isn’t, by default. That’s usually the first thing that breaks.

Unicast. Point-to-point schemes can use unicast instead. Simpler to route, but one copy per subscriber. Management APDUs are always unicast.

Priority. Inside the substation, VLAN priority still applies. Across the WAN, the IP header carries the class of service. Map GOOSE priority to the right DSCP class, and check every hop honours it. One router that ignores DSCP puts your trip signal in the same queue as a file transfer.

Path and delay. Packets can take different routes. Use the SPDU number to detect loss and reordering. Measure end-to-end delay on the real network, under load. Wide-area remedial action schemes can need end-to-end performance in the tens of milliseconds, so every hop counts.

Packet size. R-SV packets can carry several ASDUs. Keep them under the path MTU so they don’t fragment. A fragmented sampled value packet is late, or gone.

Segmentation. R-GOOSE leaves the substation. Treat that WAN path as a conduit between security zones: firewall rules for UDP 102 to known addresses only, and no general routing between substation and corporate networks. See network segmentation with IEC 62443.

Where it’s used

Typical applications:

• Transfer trip between substations, including replacing grounding switches on feeders with tapped transformers
• Remedial action schemes and system integrity protection across a region
• Synchrophasor delivery from PMUs to phasor data concentrators
• Broken conductor detection, where frequent updates from several points need to reach one decision point
• Load shedding across many sites from one controller

The common thread: one event, many receivers, spread over a large area, with a deadline.

What breaks on site

1. Multicast not routed. The publisher sends, the subscriber listens, nothing arrives. Check IGMP joins and multicast routing on every hop.
2. Key server unreachable. Subscribers can’t get the current key, so they can’t verify packets and reject them. Decide what each IED does when keys aren’t available, and test it. A scheme that fails silently is worse than one that alarms.
3. Clocks wrong. Key timing runs on UTC seconds. An IED with a wrong clock may think a key isn’t valid yet, or has expired. Synchronise every device. See PTP on PRP/HSR networks.
4. Edition mismatch. One device built to the 2012 report, the other to the 2020 amendment. Confirm both ends before commissioning.
5. DSCP stripped. A carrier or firewall resets the class of service. Delay jumps under load.
6. Firewall confusion on port 102. The rule allows TCP 102 for MMS and blocks UDP 102, or the other way round.
7. Tunnelling gateways left out of supervision. The gateway fails, the far end sees nothing, and no alarm raises because nobody monitors the tunnel.
8. Test settings left on. Signature “None” or the simulation flag set in a live scheme.

Engineering checklist

• Confirm which text each device implements: TR 61850-90-5 (2012) or IEC 61850 Ed2 Amendment 1 (2020).
• Choose native or tunnelled per scheme, and put any gateways in the timing budget.
• Pick the signature algorithm and decide on encryption as a written policy.
• Design the KDC: where it sits, how it’s made redundant, key lifetimes, what IEDs do without keys.
• Plan multicast groups, IGMPv3 and routing on every hop.
• Map priorities to DSCP and confirm every hop keeps them.
• Size packets under the path MTU.
• Synchronise all clocks.
• Write firewall rules for UDP 102, key management traffic and nothing else.
• Test end to end under load, with a WAN link failed, and with the KDC down.

FAQ