1. MRP functional description

MRP is Media Redundancy Protocol as described in IEC 62439-2.

The Microchip HW Engine supports the following roles: Media Redundancy Manager(MRM), Media Redundancy Client(MRC), Media Redundancy Auto-Manager(MRA), Media Redundancy Interconnection Manager(MIM) and Media Redundancy Interconnection Client(MIC). In a MRP ring, each node needs to support MRP and in a ring can be only one MRM and multiple MRC. It is possible to have multiple instances of MRP on a single node. But a port can be part of only one MRP instance. In an Interconnect MRP ring, there are only 4 nodes where one node is MIM and the other 3 nodes are MIC.

The MRM is responsible for detecting when there is a loop in the ring. It is sending the frame MRP_Test to detect the loops. It would send MRP_Test on both ports in the ring and if the frame is received at the other end, then the ring is closed. Meaning that there is a loop. In this case, it sets the port state to BLOCKED, not allowing traffic to pass through except MRP frames. In case it stops receiving MRP_Test frames from itself, then the MRM will detect that the ring is open, therefor it would notify the other nodes of this change and will set the state of the port to be FORWARDING.

The MRC is responsible for forwarding MRP_Test frames between the ring ports (and not to flood on other ports) and to listen when there is a change in the network to clear the FDB.

Similar with the MRP ring, in the interconnect ring, MIM sends MRP_InTest frames on all 3 ports and expects to receive at least on one port the MRP_InTest frames. The MIM can operate in a different mode where it sends CFM frames on the interconnect port.

The MIM is responsible for forwarding MRP_Test frames between ring ports and MRP_InTest frames between all ports.

The MIC is responsible for forwarding MRP_InTest frames on all ports.

2. Introduction

To be able to configure the switch, the following user space application is required: https://github.com/microchip-ung/mrp

The model of this application is a server that implements the MRP state machine which talks with the kernel via netlink interface and a client which talks only to the server to apply different configurations.

This is an example of topology. .MRP Topology mrp topology

3. Usage

3.1. Server

Before doing any configuration it is required to start the server which needs to run background because the user will use mrp application to talk with it.

mrp_server &

3.2. Bridge

After that is possible to create the bridge and assign the front ports to it

ip link set dev eth0 up
ip link set dev eth1 up
ip link set dev eth2 up
ip link set dev eth3 up
ip link add name br0 type bridge
ip link set dev eth0 master br0
ip link set dev eth1 master br0
ip link set dev eth2 master br0
ip link set dev eth3 master br0

The bridge is not set up yet because that could cause loops in the network.

Once all MRP instances are created the bridge can be set up to forward also non MRP traffic.

ip link set dev br0 up

3.3. Client

3.3.1. Add MRM/MRC

Now we can create MRP instances using this command:

mrp addmrp bridge br0 ring_nr 1 pport eth0 sport eth1 ring_role mrm

Where:

  • bridge represents the bridge on which to create the MRP instance.

  • ring_nr represents the ring id of which this MRP instance is part of. This id needs to be unique on each bridge. It is used to differentiate MRP instances.

  • pport represents the primary port

  • sport represents the secondary port

  • ring_role represents the role of the node. This can be mrm,mrc,mra, mim,mic

It is possible to create multiple MRP instances:

mrp addmrp bridge br0 ring_nr 2 pport eth2 sport eth3 ring_role mrm

Where:

  • ring_nr needs to be unique

  • pport and sport can be part of an existing ring.

3.3.2. Get status

To see the current status of MRP instances it is possible to use this command:

mrp getmrp
bridge: br0 ring_nr: 1 pport: eth0 sport: eth1 ring_role: MRM ring_state: CHK_RO
bridge: br0 ring_nr: 2 pport: eth2 sport: eth3 ring_role: MRM ring_state: CHK_RC

Where:

  • bridge represents the bridge on which the MRP instance exists

  • pport and sport represents the MRP ports of the instance

  • ring_role represents the role

  • ring_state represents the state of the state machine. In this case first MRP instance is in open state CHK_RO and the second is in closed state CHK_RC.

3.3.3. Delete MRP

To delete an MRP instance:

mrp delmrp bridge br0 ring_nr 1

Where:

  • bridge represents the bridge on which MRP instance exists

  • ring_nr represents the ring id of MRP instance

3.3.4. Add MIM/MIC

It possible for a node to have also the interconnect role. But this role can be set on only when the MRP instance is created. The interconnect mode has two modes of operating:

  • RC_MODE - where it is using MRP_InTest frames to detect if the ring is open/closed

  • LC_MODE - where it is using CFM frames on the interconnect ports to detect if the links go down

By default MRP instance with interconnect role will use RC_MODE

mrp addmrp bridge br0 ring_nr 3 pport eth0 ssport eth1 ring_role mrc in_role mim in_id 1 iport eth3

Where:

  • in_role represents the interconnect role. This can be mim or mic.

  • id_id represents the id of the interconnect node. This id needs to be the same wit the other nodes in the interconnect ring.

  • iport represents the interconnect port.

To create MRP instance with interconnect role that use LC_MODE the following command can be used:

mrp addmrp bridge br0 ring_nr 3 pport eth0 ssport eth1 ring_role mrc in_role mim
in_id 1 iport eth3 in_mode lc cfm_instance 1 cfm_level 7 cfm_mepid 2
cfm_peer_mepid 1 cfm_dmac 00:00:00:00:00:02 cfm_maid ABCD

Where:

  • in_mode represents the operation mode. This can be lc or rc.

  • cfm_instance represents the id of the cfm instance

  • cfm_level represents MEG level

  • cfm_mepid represents the MEP id of the MEP

  • cfm_peer_mepid represents the MRP id of the peer MEP

  • cfm_dmac represents the MAC address of the MEP

  • cfm_maid represents the MAID domain name

More information about CFM can be found here: https://github.com/microchip-ung/cfm