Compare industrial ring recovery protocols

What you should be able to do

Compare the roles and evidence needed for MRP, DLR and REP, and distinguish network recovery measurements from the service interruption experienced by an application.

Why a ring needs coordination

Connecting devices in a physical Ethernet ring does not by itself establish a safe, resilient forwarding topology. A compatible protocol and correct configuration must control loops and handle the intended failure cases. The glass links provide the physical paths; they do not select a recovery protocol.

Three protocol families

MRP means Media Redundancy Protocol. The documented ring uses a Media Redundancy Manager and Media Redundancy Clients. In a healthy ring, the manager blocks a ring port for normal traffic to prevent a forwarding loop; behavior changes when the ring fails [1]. Manager capability and client capability are distinct support questions.

DLR means Device Level Ring. An active ring supervisor manages the ring and blocks ordinary traffic on one ring port in normal operation while protocol traffic performs its required functions [2]. Confirm which devices can supervise and which can participate as ring nodes. Do not assume that two Ethernet ports alone establish DLR capability.

REP means Resilient Ethernet Protocol. Cisco documents it as a proprietary protocol using segments, edge roles and an alternate port to control loops and respond to failures [3]. Traffic and VLAN arrangements affect the detailed configuration. It is not simply another name for MRP or DLR.

Original classroom topology

Imagine four nodes A, B, C and D connected around a ring: A–B–C–D–A. With a suitable configured protocol, a single failed B–C link leaves a physical path B–A–D–C. Whether the required service recovers within its limit still depends on the system. If A–B and C–D both fail, the remaining physical connections are A–D and B–C. The ring is split into two groups. A recovery protocol cannot create a missing physical path. If node B loses power, devices served only by B may remain unavailable even if communications among surviving ring nodes recover. Keep node survival separate from path recovery.

Compare equivalent evidence

For every candidate, record the exact product identifiers, software releases, supported roles, topology restrictions, ring size, interface requirements and application needs. Then identify what a published recovery claim actually covers: failure type, detection method, node count, load and measurement endpoints. Do not treat a nominal protocol figure from one test as a guarantee for an unrelated plant application. Restoration after a repaired link may also affect forwarding and should be included in the approved verification plan.

Original timing exercise

The fictional application requirement allows no more than 100 ms of interruption for the defined single-link failure. One test record reports a 60 ms protocol recovery event, while the application monitor records a 140 ms gap. The application result exceeds the requirement by 140 − 100 = 40 ms. It fails the stated exercise criterion even though the protocol figure is shorter. A second fictional test records a 90 ms application gap. That is 10 ms below the limit in that particular test. It is favorable evidence for the stated conditions, not proof of all failure cases or zero packet loss. These numbers are original classroom inputs. They are not MRP, DLR or REP performance specifications.

Original compatibility exercise

A procurement sheet describes every candidate as “industrial Ethernet with two fiber ports.” One supports only a client role in the desired protocol; another supports the required management role; a third does not list that protocol for its supplied release. The optical ports do not resolve those differences. Mark the client-only unit as unable to fill the required management role based on the supplied packet. Record the unsupported or undocumented release as unresolved until exact support evidence is obtained. Do not mix protocols on the same ring ports by assumption.

Worked through

1. Required service and allowable interruption.
2. Physical ring drawing and shared power/path dependencies.
3. Exact devices, releases, roles and configuration references.
4. Failure cases: identified link, node or supply event.
5. Measurement endpoints, clocks, traffic and definition of interruption.
6. Recovery results, packet/application behavior and unresolved anomalies.
7. Restoration results after the approved repair step.
8. Authorized test owner, change window and rollback procedure. This worksheet is preparation for a controlled test. It does not authorize unplugging live production fibers or interrupting equipment.

Practice questions

1. What is the MRP manager role called?
2. What manages a DLR ring?
3. Which compared protocol uses REP segments and alternate roles?
4. Does a ring-shaped fiber route establish protocol compatibility?
5. In the four-node example, what remains after B–C fails?
6. Does a 60 ms protocol event override a 140 ms application gap?
7. Why test restoration as well as failure?

Answers

Where beginners go wrong

Sources