STP, RSTP, MSTP, and ST 2022-7 in ST 2110 Networks: Which One Do We Use Where?
STP, RSTP, MSTP, and ST 2022-7 in ST 2110 Networks: Which One Do We Use Where?
Summary
This article is written for network engineers, broadcast technicians, and system designers moving from SDI infrastructure to ST 2110/IP-based broadcast architectures. The goal is to remove the confusion that appears when STP/RSTP/MSTP, multicast, and ST 2022-7 are mentioned in the same design conversation.
One of the most common ST 2110 design questions is this:
For the media network, do we use STP, RSTP, MSTP, or ST 2022-7?
The short answer:
STP/RSTP/MSTP solve switch loop problems. ST 2022-7 solves media packet continuity. They are not alternatives operating at the same layer.
For modern ST 2110 media fabrics, the practical approach is usually:
- Do not rely on STP/RSTP/MSTP as the media redundancy mechanism
- Design Network A and Network B as physically separate fabrics
- Prefer a controlled leaf-spine or L3 multicast architecture
- Validate PTP, QoS, IGMP/PIM-SSM, and multicast state separately
- Use SMPTE ST 2022-7 at the receiver for media continuity
In other words, the STP family says “avoid network loops”. ST 2022-7 says “keep the programme alive even if media packets are lost”.
In the SDI world, redundancy was often understood as a primary/backup cable or router crosspoint model. In ST 2110, the same problem is solved with packets, multicast, paths, and receiver merge behavior. That is why “do we have a backup link?” is not enough; what matters is whether the two paths are truly independent and whether the receiver performs ST 2022-7 merge.
1. Do we use STP, RSTP, or MSTP in an ST 2110 media network?
First, let us separate the roles very clearly:
| Protocol / mechanism | What it does | Role in an ST 2110 media fabric |
|---|---|---|
| STP | Prevents Layer 2 loops by blocking selected ports | Not the right primary mechanism for media redundancy |
| RSTP | A faster-converging version of STP | Useful in some enterprise L2 access networks, but not a guarantee for RTP continuity |
| MSTP | Manages multiple spanning tree instances for VLAN groups | Can exist in complex L2 designs, but does not replace ST 2110 A/B media redundancy |
| LACP / LAG | Treats multiple physical links as one logical link | Improves capacity/availability, but it is not ST 2022-7 |
| L3 multicast | Provides controlled media distribution with routed multicast | Common and more deterministic in larger ST 2110 fabrics |
| ST 2022-7 | Receives the same RTP flow over two paths and merges it at the receiver | The main mechanism for media continuity |
What is the difference between LACP and ST 2022-7?
LACP/LAG is especially easy to confuse here because it also uses multiple physical links. But LACP does not create two independent media paths; it creates one logical interface between a device and a switch. It may distribute flows across links using a hash algorithm and keep the logical connection alive after a link failure, but it does not merge two RTP copies at the receiver.
ST 2022-7 is different: the same RTP media flow is carried over two independent networks, such as A and B. The receiver sees both copies at the same time and produces the clean output at packet level.
Short distinction:
LACP strengthens the link; ST 2022-7 protects the programme.
Can we use ST 2022-7 without LACP? Yes. What ST 2022-7 requires is not LACP; it requires truly independent A and B media paths. The sender transmits the same RTP flow over Network A and Network B, while the receiver receives both copies at the same time and performs packet-level merge.
LACP can still be used, but in the right place: for example inside the Network A fabric for uplink capacity or link availability, or similarly inside the Network B fabric. But it is wrong to think of A and B paths as two physical ports inside a single LAG bundle. ST 2022-7 A/B separation means two separate fault domains, not two links inside one logical interface.
The practical rule is:
LACP is not required for ST 2022-7. LACP is an optional capacity tool inside a fabric; ST 2022-7 is the main media redundancy mechanism.
The STP family is not bad. It becomes a problem when it is used in the wrong place with the wrong expectation.
RSTP/MSTP may be used in a management VLAN, a low-criticality control network, or a small access topology. But on the ST 2110 media fabric side, it is not a good design choice to leave programme continuity to STP convergence behavior.
Because ST 2110 media traffic is:
- Real-time
- High-bandwidth
- Mostly multicast
- Sensitive to PTP timing
- Sensitive to packet loss and jitter
That is why media continuity requires a designed A/B fabric plus ST 2022-7, not STP.
2. What do STP, RSTP, and MSTP solve?
The STP family prevents Layer 2 loops in Ethernet networks. If there is a physical loop between switches, broadcast storms and MAC table instability can occur. STP breaks the loop by placing selected ports into a blocking state.
RSTP does this faster. MSTP can manage different spanning tree instances for different VLAN groups.
But all three belong to the same problem family:
Prevent loops in the switch topology.
None of them answers this question:
If an RTP media packet is lost on path A, how does the receiver keep the programme alive?
That is why the difference between STP/RSTP/MSTP and ST 2022-7 is a layer difference.
If this distinction is not made clearly, ST 2110 network design can create a false sense of protection.
3. What is the practical recommendation for an ST 2110 media fabric?
In large and critical ST 2110 systems, the practical recommendation is usually:
- Design two separate media networks: Network A and Network B
- Do not create a Layer 2 loop between A and B
- Separate A and B as physical fault domains
- Use controlled IGMP/PIM-SSM/SDN behavior for multicast distribution
- Design PTP so timing survives either path failure
- Use ST 2022-7 merge at the receiver
In this approach, STP is not the main protection mechanism. In fact, if A and B fabrics are separated correctly, there should be no media-path loop for STP to solve between them.
In short:
In an ST 2110 media network, the STP family exists for loop prevention; ST 2022-7 exists for programme continuity.
4. The problem: what happens when a cable fails in IP?
In the SDI world, redundancy was often considered as physical backup feeds. There might be a primary SDI signal and a backup SDI signal. In the IP world, media is carried as packets. This allows a more granular protection model:
Send the same media packets over two separate networks and let the receiver use the best packet.
In this approach, the sender transmits the same RTP essence over two paths:
- Network A: primary path
- Network B: secondary path
The receiver listens to both flows. If a packet is lost on A, the matching copy from B can be used.
This is why ST 2022-7 is more precise than basic “path failover”. Ideally, the receiver does not wait for an entire path to fail; it can make packet-level decisions.
5. How does ST 2022-7 work?
The basic logic of ST 2022-7 is:
- The sender transmits the same RTP stream through two separate network interfaces or paths
- Flow A and Flow B carry the same media essence
- The receiver receives both flows at the same time
- It aligns packets using RTP sequence numbers and timestamps
- If one packet is lost or late on one path, the packet from the other path can be used
- The output is a single clean media stream
The key point is this: for ST 2022-7 to work, the two paths must carry the same packet stream. The receiver is not looking for a “similar programme”; it expects two copies of the same RTP flow.
6. What ST 2022-7 is not
ST 2022-7 is often confused with other network concepts.
| Concept | What it does | Relationship to ST 2022-7 |
|---|---|---|
| STP / RSTP | Prevents Layer 2 loops and blocks some ports | Does not perform media packet merge |
| LACP / LAG | Treats multiple links as one logical connection | Provides link availability/load sharing; it does not perform RTP packet merge at the receiver |
| ECMP | Can load-balance IP routes | Does not merge two copies of the same flow at the receiver |
| PTP | Provides a common time reference | Helps the system behave correctly, but does not merge packets |
| NMOS | Provides discovery and connection management | Can set up flows, but does not protect media packets |
| Multicast | Distributes RTP flows | It is the transport model, not the protection mechanism |
The shortest distinction:
STP protects the network. ST 2022-7 protects the media.
On the NMOS side, the distinction is this: IS-04 provides device and flow discovery, while IS-05 provides connection management. In other words, an orchestration system can connect the correct A and B flows between sender and receiver, but replacing a lost RTP packet on path A with the matching copy from path B is not an NMOS function. That is done by the ST 2022-7 merge engine in the receiver. For more detail, it is better to refer to the separate AMWA NMOS article.
7. Is there a relationship between STP and ST 2022-7?
There is a relationship, but not in the sense that one replaces the other.
The STP family protects the network topology from loops. ST 2022-7 protects media packets across two independent paths.
The relationship is:
- STP/RSTP/MSTP is only Layer 2 topology loop control
- ST 2022-7 is receiver-side protection of RTP media packets
- STP convergence is not an alternative to ST 2022-7 merge behavior
- If A/B fabrics are separated correctly, STP is not expected to choose between A and B
The design mistake is to treat STP as if it were an A/B media protection mechanism.
So the statement “we have STP, therefore we do not need 2022-7” is wrong. STP solves a network loop problem; ST 2022-7 solves a media flow continuity problem.
8. STP, RSTP, MSTP, and ST 2022-7 comparison
STP and ST 2022-7 are not alternatives.
STP answers this question:
If there is a loop in the Layer 2 network, how will the switch topology protect itself?
ST 2022-7 answers this question:
If a media packet is lost on one path, how will the receiver keep the programme alive?
These are different questions.
| Design topic | STP / RSTP | ST 2022-7 |
|---|---|---|
| Layer | Layer 2 control plane | RTP media plane |
| Goal | Loop prevention | Media continuity |
| Where it works | Switch topology | Receiver merge engine |
| Failover behavior | Port/topology convergence | Packet-level selection |
| Role in broadcast media | Auxiliary / limited | Main redundancy mechanism |
| A/B network approach | Should not be a single looped topology | Requires two independent fabrics |
Most modern ST 2110 facility designs avoid relying on STP for the media fabric. Instead they use explicitly designed leaf-spine, L3 multicast, PIM-SSM/IGMP, QoS, PTP-aware switching, and ST 2022-7 A/B separation.
9. Short note: how PTP relates to ST 2022-7
PTP is not the main topic of this article; PTP and SMPTE ST 2059 are covered in detail in a separate article. Here, we only need the part that affects ST 2022-7 design:
PTP provides the time reference; ST 2022-7 protects the same RTP media packet across A/B paths.
So PTP does not replace ST 2022-7. ST 2022-7 does not replace PTP either. But when A/B media paths are protected, the timing reference must not become a single point of failure. If timing is stable on path A but behaves differently after path B becomes the surviving path, the 2022-7 diagram may look correct while the real system is still unreliable.
For detailed PTP, ST 2059, domain 127, BMCA, and grandmaster architecture, it is better to refer to the dedicated PTP and SMPTE ST 2059 article. In this article, we keep PTP limited to its role in redundancy design.
10. Where does it break in real life?
ST 2022-7 looks simple on paper. In real deployments, small design mistakes can defeat the protection mechanism.
| Problem | Possible cause | Fix |
|---|---|---|
| Programme still fails when path A fails | Path B uses the same physical route | Separate A/B fiber, switch, PSU, linecard, and building paths |
| Receiver does not merge | Flow A and Flow B are not the same essence | Check SDP, SSRC, payload type, RTP timestamp, and format matching |
| Packet loss exists but protection fails | A/B latency difference exceeds receiver buffer limits | Measure path delay and validate receiver buffer capacity |
| Video breaks when timing lock is lost | The timing reference is not as redundant as media A/B | Test whether the timing reference survives A and B failures |
| Multicast joins go to the wrong path | IGMP/PIM/SDN policy issue | Monitor multicast state separately on A and B |
| Maintenance causes outage | “Physically separate” paths share a switch or patch panel | Build a real cable route and fault-domain map |
11. Which device performs ST 2022-7 merge?
ST 2022-7 merge is usually performed by the receiving media device. That may be a gateway, multiviewer input, decoder, production switcher input card, IP receiver module, or the RX side of a modern encoder/decoder platform.
In practice, the important question is not the vendor name but whether the device really supports the required behavior:
- Can it receive A and B RTP flows for the same essence at the same time?
- Can it match the two paths as copies of the same media flow using SDP/flow metadata?
- Can it perform packet merge using RTP sequence numbers and timestamps?
- Does it provide enough buffering for the A/B path latency difference?
- Can it report A path, B path, and merged output separately?
That is why a simple “supports ST 2022-7” statement is not enough during procurement or design. The supported essence types, bitrates, and tolerated latency differences must be tested.
12. Monitoring: A/B paths must be observed separately
Knowing that ST 2022-7 works is not the same as saying “the picture is still visible”. The receiver may output a clean programme while path A has packet loss, path B has multicast join issues, or the merge buffer is close to its limit.
At minimum, these metrics should be monitored separately:
| Metric | Why it matters |
|---|---|
| A path packet loss / sequence gap | Shows the health of the primary path |
| B path packet loss / sequence gap | Shows whether the secondary path is actually ready |
| A/B latency difference | Shows whether the receiver is close to the merge buffer limit |
| Active packet source / merge decision | Shows which path the receiver is using for packets |
| Multicast join state | Confirms that A and B flows are received from the correct network |
| Receiver buffer / underrun event | Shows whether merge works in practice, not just on paper |
This topic is large enough for its own article; for the detailed monitoring side, it is better to link to the ST 2110 monitoring article.
13. Design checklist
Practical checklist for ST 2022-7 design:
- Are Network A and Network B physically separate?
- Do A and B use different switches, PSUs, linecards, and preferably different fiber routes?
- Does the sender really produce two equivalent RTP flows?
- Do Flow A and Flow B share the same essence, format, RTP timestamp, and sequence relationship?
- Does the receiver support ST 2022-7 merge?
- Is the A/B path latency difference within the receiver buffer limit?
- Is the timing reference preserved when either A or B fails?
- Were PTP/ST 2059 details validated with a separate timing synchronization checklist?
- Was multicast join state verified separately on the A and B networks?
- Was a real fiber/switch failure test performed?
- Does the monitoring system show A path, B path, and merged output separately?
The most important item is near the end:
ST 2022-7 design is not validated by a drawing; it is validated by a physical failure test.
14. How does ST 2022-7 affect bandwidth?
ST 2022-7 does not save bandwidth. It sends the same media flow over two separate networks.
Example:
| Flow | Single path | ST 2022-7 total |
|---|---|---|
| 1x 1080i50 ST 2110-20 video | ~1.6 Gbps | ~3.2 Gbps |
| Video + audio + ANC safe budget | ~1.8 Gbps | ~3.6 Gbps |
| 1x UHD/2160p50 ST 2110-20 video | ~12 Gbps | ~24 Gbps |
| 10 programmes | ~18 Gbps | ~36 Gbps |
But the important point is this: A and B networks are separate capacity pools. You should not think “3.6 Gbps goes onto the same link”. In a correct design:
- Network A can carry the full load by itself
- Network B can carry the full load by itself
- If one path fails, the other path can keep the programme alive
That is why ST 2022-7 may look expensive, but it is one of the most critical protection layers for live production continuity.
15. Conclusion
ST 2022-7 is one of the central redundancy standards in the ST 2110 world.
But it must be positioned correctly:
- It is not STP
- It is not PTP
- It is not routing
- It is not NMOS
- It is not LAG
- It is not “redundancy inside one network”
ST 2022-7 is a protection mechanism that merges two copies of the same RTP media flow arriving over two independent network paths at the receiver.
The shortest summary:
STP prevents switch loops. PTP aligns time. NMOS manages connections. ST 2022-7 protects media packets.
If we want real redundancy in ST 2110 systems, we must physically separate the A/B networks, verify that the timing reference does not break, monitor multicast state, and validate ST 2022-7 with real failure tests.