At present, the latest in-vehicle network widely uses Ethernet as the backbone network, and in order to enhance the reliability of the network, a ring network topology is usually adopted, allowing data to be transmitted through multiple paths. However, the introduction of ring topologies can lead to the formation of loops, which in turn introduce potential risks such as broadcast storms. In order to circumvent these problems, we usually need to use technologies such as STP RSTP to prevent loop formation and achieve seamless handover when a communication link failure is detected, so as to reduce the adverse impact of the fault on network communication. However, the convergence speed of technologies such as STP and RSTP during link handover is usually more than 1 second, which is far from meeting the requirements of in-vehicle network communication. In contrast, ERP technology provides a faster fault detection and handover solution for Ethernet rings, ensuring that the network can be restored to normal faster times in the event of a failure, and therefore has the potential for a wide range of applications in in-vehicle networks.
ERPS stands for Ethernet Ring Protection Switching, which is a Layer 2 destructive protocol standard defined by ITU-T, and the standard number is ITU-T G8032 y1344, hence the name g8032, which defines Ring Auto Protecting Switching (R-APS) packets and the protection switching mechanism. The ERP includes V1 and V2, of which V2 adds features such as child rings, and V2 is fully compatible with V1.
The ring network topology introduced in the Ethernet switching network to perform link backup and improve network reliability will cause loops on the network, which may cause phenomena such as broadcast storms and unstable MAC address tables, which will affect the quality of user communication and even lead to communication interruption. In order to solve the loop problem, a series of ring network protocols have been introduced, including RRPP, STP RSTP MSTP, SEP, ERPS, etc., among which ERPS is designed to provide fast fault detection and switchover to ensure that the network can quickly transmit data from the standby path in the event of a failure, reducing the time of network interruption, so as to effectively ensure the quality of user communication.
Compared with other Layer 2 loop protocols such as STP RSTP MSTP, RRPP, and SEP, ERP technology has the following advantages:
Fast convergence speedERPS absorbs the advantages of ring network protection technologies such as STP, RSTP, MSTP, etc., optimizes the detection mechanism, and the convergence speed is faster, which can reach the MS level.
High compatibility ERPS is a standard Layer 2 loop protocol published by ITU-T, which can be interoperable if the manufacturer's equipment in the ring network supports the protocol.
Basic ERP conceptsThe basic principle of ERP is to eliminate the loop by blocking some ports in the loop, and to ensure that the network can continue to operate quickly and efficiently in the event of a failure by quickly detecting faults in the loop, selecting a backup path, and resuming data transmission as soon as possible after the switchover. The following introduces some basic concepts involved in ERP based on the single-loop structure in Figure 1.
Figure 1Schematic diagram of a single loop of ERPS.
Ethernet Ring ERPS is also the basic unit of the ERP protocol, which consists of a set of interconnected switching devices configured with the same control VLAN. For multi-ring structures, there is a primary ring and at least one child ring.
The Layer 2 switch device that joins the ERPS ring is called a node, and each node cannot have more than two ports to join the same ERPS ring, and the switch A switch D in Figure 1 is the four nodes in the ERPS ring.
In the non-fault state, a ring protection link (RPL) prevents the formation of a loop by blocking the ports at both ends of the link, which are the RPL owner port and the RPL neighbour port.
There are three types of port roles specified in the ERPS protocol: RPL owner port, RPL neighbour port, and common port. The RPL Neighbour port type is supported only in ERPS V2 and not in V1.
The RPL Owner port is a port at one end of the RPL link, which is specified by the user configuration, and has only one RPL Owner port for an ERPS ring. The RPL Owner port is blocked in a non-fault state to prevent loops from the link. A node that contains an RPL owner port is also called an RPL owner node.
The RPL Neighbour port is the port at the other end of the RPL link, and the RPL Neighbour port is the node port that is directly connected to the RPL owner port. In the non-fault state, the RPL Neighbour port is blocked to prevent loops. When a non-RPL link on the ERPS ring network fails, both the RPL Owner port and the RPL Neighbour port are opened. A node that contains an RPL Neighbour port is also called an RPL Neighbour node.
Normal ports are common ports in the ERPS ring, except for RPL Owner and RPL Neighbour. A common port is responsible for monitoring the status of the links it is directly connected to and notifying other nodes in the ring network of changes in the link status in a timely manner.
ERP protocol packetsThe ERPS protocol uses the R-APS PDU in the format shown in Figure 2, which is one of the OAM message definitions, as shown in IUT-T GDefinition of 8013 Y1731. The target MAC address of the R-APS PDU is 0x01-0x19-0xa7-0x00-0x00-[Ring ID], where the default value of the Ring ID is 0x01.
Figure 2R-APS PDU format.
mel: identifies the level of the maintenance instance. version: the version of the ERP protocol, the 0x00 is V1 and the 0x01 is V2. opcode: takes a fixed value 0x28 indicates that this is an r-aps pdu. flags: takes a fixed value 0x00, this field is ignored when received. TLV offset: takes a fixed value 0x20 indicates that the TLV in the PDU is offset by 32 bytes from this field. R-APS specific information: Important information about carrying the ERP ring, which will be described in more detail later. optional tlv: The user can customize the additional information that needs to be carried, if there is no additional information to carry, this field is not available. end tlv: takes a fixed value 0x00. Figure 3 shows the definition of R-APS specific information in ERPS V2.
Figure 3r-aps specific information format.
request state: Identifies whether the information is a request or a current state. 
Table 1Table of the values of request status.
sub-code: If the request status parameter is set to 1110, this field is 0000 to indicate a request for an FDB entry to be refreshed. If the request status parameter is set to another value, this field is reserved and will be ignored during receiving. status: Contains specific status information. RB (RPL Blocked): For RPL Owner nodes, a value of 1 indicates that the RPL link is blocked, and a value of 0 indicates that the RPL link is unblocked. This value is 0 in the R-APS PDUs sent by the non-RPL Owner node. dnf(do not flush): A value of 1 indicates that the receiver should switch between FDB tables and a value of 0 indicates that the receiver does not switch between FDB tables. BPR (Blocked Port Reference): indicates that the first port of the ERPS ring is blocked if the value is 0 and the second port of the ERPS ring is blocked if the value of 1 indicates that the second port of the ERPS ring is blocked. Node ID: indicates the MAC address of the node that sends this message, which is an information field and does not affect the protection switchover process of the ERPS ring. reserved 2: reservedERPS single-loop link failover processAs mentioned above, the ERPS ring is to eliminate the loop by blocking the RPL Owner and RPL Neighbour ports, and when a loop ** fault is detected, the data transmission path is quickly switched by updating the FDB table and port status to ensure data transmission.
Non-fault stateAs shown in Figure 4, the RPL owner and RPL neighbour ports are blocked in the non-fault state to prevent loops from forming, and the RPL owner node sends NRRB R-APS packets to other nodes in the ERPS ring (that is, the request state value is 0000 and the RB bit value of the Status field is 1, indicating that the RPL link is blocked), indicating that there is no fault in the current ERPS ring.
Figure 4The ERP single-loop is not faulty.
Link failureAs shown in Figure 5, when the link between switch C and switch D is faulty (that is, a link down is detected), the protection switchover mechanism is started to block the ports at both ends of the faulty link and flush the FDB table of the device. Switch C and Switch D then send SF R-APS packets to other nodes in the ERPS ring. After Switch A and Switch B receive the SF R-APS packet, open the RPL owner port and RPL Neighbour port respectively and refresh the FDB table to ensure smooth communication.
Figure 5The fault status of the ERP single-loop link.
Link fault removalAs shown in Figure 6, after the link between Switch C and Switch D is removed (that is, the link is re-linked up), the failback mode is started, first Switch C and Switch D stop sending SF R-APS packets and send NR R-APS packets to indicate fault removal When Switch C and Switch D receive the NRRB R-APS packet, they open the port that was blocked in the fault state, stop sending NR R-APS packets, and refresh the FDB table.
Figure 6The status of the single-loop link fault removal of the ERPS.
ERP is one of the Ethernet ring network technologies, which mainly blocks some ports to avoid the risk of broadcast storms caused by loops. At the same time, the rapid switching of communication links is realized through mechanisms such as fast fault detection, which can meet the application requirements of scenarios such as vehicle networks. One of the ring network redundancy technologies that have emerged in recent years is IEEE 802 in TSN1 CB protocol, Polelink has also accumulated rich experience in the test development and test implementation of CB protocol, and looks forward to sharing it with you in the future.
Referencesitu-t g.8032/y.1344 ethernet ring protection switchingitu-t g.8013/y.1731 operation, administration and maintenance (oam) functions and mechanisms for ethernet-based networks