A method and device for managing link state in an MRP ring network

Abstract

A method and device for managing link state in an MRP ring network, the method comprising: in an open loop state, in response to receiving a first MRP link state packet from any one of two ring ports of an MRM, starting a time window with the time of the receiving as the starting point; within the time window, in response to receiving a first MRP link state packet from the other of the two ring ports, and the link states indicated by the first MRP link state packets received by each of the two ring ports being different, determining the ring port receiving the first MRP link state packet first as a priority port, and determining the ring port receiving the first MRP link state packet later as a sub-priority port; before determining that the forwarding path is in a stable state, processing each MRP link state packet received from the priority port in turn, and not processing each MRP link state packet received from the sub-priority port, effectively inhibiting the occurrence of ring network oscillation.

Description

Technical Field

[0001] This article relates to network communication technology, and in particular to a method and apparatus for managing link status in an MRP ring network. Background Technology

[0002] An MRP ring network consists of a Media Redundancy Manager (MRM) and multiple Media Redundancy Clients (MRCs). MRCs detect ring network port failures by sending MRP_Linkdown messages and detect port recovery by sending MRP_Linkup messages, notifying the MRM of the port status changes. Upon receiving an MRP_Linkdown message, the MRM activates its state machine to set the ring to an open-loop state and sends an MRP_TopologyChange message to notify all MRCs of the topology change occurring in the MRP ring network. Upon receiving an MRP_Linkup message, the MRM activates its state machine to set the ring to a closed-loop state and sends an MRP_TopologyChange message to notify all MRCs of the topology change occurring in the MRP ring network.

[0003] In current technology, to achieve rapid failover, the MRM immediately processes MRP_LinkDown and MRP_Linkup messages. However, in practical applications, this processing method may cause ring oscillations, leading to problems such as unstable ring network forwarding, data packet loss, and excessive device resource consumption. Summary of the Invention

[0004] This application provides a method and apparatus for managing link states in an MRP ring network.

[0005] A method for managing link states in an MRP ring network, applied to an MRM, the method comprising: When the MRP ring network is currently in an open-loop state, in response to receiving the first MRP link status message from either of the two ring ports of the MRM, a time window is started with the time of receiving the first MRP link status message as the starting point. Within the time window, in response to receiving the first MRP link status message from the other of the two ring ports, and the link status indicated by the first MRP link status messages received by the two ring ports is different, the ring port that receives the first MRP link status message first is determined as the priority port, and the ring port that receives the first MRP link status message later is determined as the second priority port; the MRC that receives its first MRP link status message through the priority port is determined as the near-end MRC, and the MRC that receives its first MRP link status message through the second priority port is determined as the far-end MRC; Before determining that the forwarding path from the priority port, through the near-end MRC to the far-end MRC is in a stable state, each MRP link state message received from the priority port is processed sequentially to manage the loop state, and each MRP link state message received from the second priority port is not processed.

[0006] A link state management device in an MRP ring network includes a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described above.

[0007] In this embodiment of the application, when the MRP ring network is currently in an open-loop state, a time window is initiated starting from the moment the first message is received, establishing a unified time reference for determining the timing association of messages between the two ports. Within the time window, the first messages of the two ports are associated based on "different sources and opposite content," providing an operable technical definition for timing conflicts. Priority ports and secondary priority ports are divided based on the "first-come, first-served" timing principle, and the near-end MRC and far-end MRC are determined accordingly, establishing an objective and repeatable role division rule. Before it is determined that the forwarding path from the priority port, through the near-end MRC to the far-end MRC is in a stable state, a differentiated processing strategy is used to process the messages received by the two ring ports, managing the ring network state with a single information source, shielding the interference of out-of-order messages on decision-making, and effectively suppressing the occurrence of ring network oscillations.

[0008] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0009] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0010] Figure 1This is a schematic diagram of the topology of an MRP ring network provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the link state management method in an MRP ring network provided in this embodiment of the application. Detailed Implementation

[0011] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0012] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0013] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0014] Figure 1 This is a schematic diagram of the topology of an MRP ring network provided in an embodiment of this application. Figure 1As shown, this MRP ring network includes a Media Redundancy Management Unit (MRM) and multiple Media Redundancy Client Units (MRCs). To meet the requirements of the ring network topology, the total number of ring network nodes N is an integer greater than or equal to 3. For ease of description, the figure shows 15 MRCs (MRC-1 to MRC-15), but in actual applications, the number of MRCs can be configured as needed.

[0015] The MRM has two ring ports for accessing the ring network, denoted as the first ring port (P1) and the second ring port (P2). P1 is directly connected to MRC-1, and P2 is directly connected to MRC-15. The MRCs are connected in series to form a closed ring topology. Specifically, MRC-1 connects to MRC-2, MRC-2 connects to MRC-3, ..., and MRC-14 connects to MRC-15, thus forming a complete physical ring network, with a total number of ring network nodes N = 16 (MRM + 15 MRCs).

[0016] This ring network is deployed in the automotive welding workshop, connecting the welding robot control units at each workstation. Among them, MRC-5 and MRC-6 are located at two adjacent welding workstations, and the connecting network cable between them is susceptible to poor physical contact because it is in an area where the robot arm moves frequently.

[0017] When the ring network is operating normally, all links are connected. At this time, the MRM controls the MRP ring network into a closed-loop state. In the closed-loop state, the MRM logically blocks the data forwarding function of one of the ring ports (e.g., P2), allowing user data to be transmitted in a single direction within the ring network (e.g., starting from P1, sequentially through MRC-1, MRC-2, ..., MRC-15, and returning to P2). However, port P2 does not forward data, thus avoiding the formation of a broadcast loop. Simultaneously, the MRM periodically sends MRP_Test messages through the blocked port to monitor the ring network's connectivity.

[0018] When a link in a ring network fails, for example Figure 1 When the link between MRC-5 and MRC-6 is broken, the faulty MRCs (MRC-5 and MRC-6) generate MRP_Linkdown messages and send them to the MRM in two directions along the ring network. Specifically, the message generated by MRC-5 is sent to the P1 port of the MRM along the directions of MRC-4, MRC-3, MRC-2, and MRC-1; the message generated by MRC-6 is sent to the P2 port of the MRM along the directions of MRC-7, MRC-8, ..., MRC-15.

[0019] After receiving an MRP_Linkdown message from one or two ring ports, the MRM immediately starts its state machine, unblocks the blocked port (P2), and switches the port to forwarding state. At this time, the MRP ring network is controlled by the MRM to be in an open-loop state.

[0020] In open-loop mode, both ring ports P1 and P2 of the MRM are in forwarding mode. Data can be transmitted in both directions, bypassing the faulty link, thus ensuring uninterrupted communication for all MRCs on the ring network. Specifically, data sent from port P1 is transmitted along the MRC-1 direction, reaching MRC-1 to MRC-5; data sent from port P2 is transmitted along the MRC-15 direction, reaching MRC-15 to MRC-6. Nodes on both sides of the faulty link are covered by data paths in both directions, demonstrating the redundancy capability of the ring network.

[0021] In the above open-loop state, if physical layer jitter occurs on the faulty link (between MRC-5 and MRC-6), that is, the link alternately "recovers" and "disconnects" in a short period of time, MRC-5 and MRC-6 will alternately generate MRP_Linkup messages and MRP_Linkdown messages, which will be sent to MRM in two directions along the ring network respectively.

[0022] Because the two MRCs generate messages at slightly different times, and the number of hops in the transmission paths differs in the two directions (4 hops to MRC-5 in the P1 direction, and 9 hops to MRC-6 in the P2 direction), the timing of messages arriving at the two ring ports of the MRM may be disordered. For example, the MRM might first receive an MRP_Linkup message indicating "recovery" from MRC-5 at port P1, then receive an MRP_Linkdown message indicating "failure" from MRC-6 at port P2, and subsequently receive more interleaved messages from both ports. This timing conflict of interleaved messages between the two ports will cause the MRM state machine to repeatedly switch between "closed loop" and "open loop," causing ring network oscillations, which in turn leads to problems such as production scheduling data packet loss and excessive CPU resource consumption of the MRM equipment, affecting the stable operation of the welding production line.

[0023] This solution is proposed to address the technical problem of ring network oscillation caused by dual-port message timing conflicts due to link jitter in the open-loop state.

[0024] In the following text, MRP_Linkup and MRP_Linkdown messages will be collectively referred to as MRP link-state messages.

[0025] See Figure 2This embodiment provides a method for managing link states in an MRP ring network, eliminating the possibility of state machine flipping triggered by alternating dual-port packets at the source, while maintaining the ability to respond to real faults.

[0026] The core of this method lies in proposing a timing conflict determination and dynamic recovery control mechanism. This mechanism uses the reception time of the first arriving message as the time reference and the time window T as the decision boundary, solving the aforementioned problem through the coordinated operation of three technical aspects: First, within the time window, the association of the first message received by each of the two ring ports is determined. When the link states indicated by the first messages received by the two ring ports are different, it is determined that a timing conflict has occurred. Second, based on the objective timing principle of "first come, first served", the port that receives the message first is determined as the priority port and the near-end MRC is determined accordingly, and the port that receives the message later is determined as the second priority port and the far-end MRC is determined accordingly, thus establishing a clear role division. Third, before confirming that the forwarding path from the priority port through the near-end MRC to the far-end MRC is in a stable state, each MRP link state message received by the priority port is processed sequentially, while each MRP link state message received by the second priority port is not processed. This achieves state machine driven by a single source, shielding out-of-order messages from interfering with decision-making.

[0027] See Figure 2 The method includes steps 10 to 30.

[0028] Step 10: When the MRP ring network is currently in an open-loop state, in response to receiving the first MRP link status message from either of the two ring ports, a time window is started with the time when the first MRP link status message is received as the starting point.

[0029] The function of this step is to establish a unified time reference and judgment boundary for subsequent determination of whether the two port messages constitute a timing conflict.

[0030] Specifically, this step is performed on the premise that the MRP ring network is currently in an open-loop state. In the aforementioned automotive welding workshop ring network, when the link between MRC-5 and MRC-6 fails for the first time, the MRM has already switched the ring network to an open-loop state according to the standard MRP protocol, and both ring ports P1 and P2 are in forwarding state.

[0031] When the faulty link experiences physical layer jitter, assuming the link recovers instantaneously at a certain moment, MRC-5 detects the port status changing to Link Up and generates an MRP_Linkup message (denoted as message A), which is sent from its ring port and forwarded to the MRM's P1 port via MRC-4, MRC-3, MRC-2, and MRC-1. MRC-6 also detects the recovery and generates an MRP_Linkup message (denoted as message B), which is forwarded to the MRM's P2 port via MRC-7 to MRC-15. Because the transmission path in the P1 direction is shorter (4 hops), the P1 port receives message A first at time t0. The MRM immediately starts its time window, using time t0 as the starting point.

[0032] It should be noted that the limitation of "any ring port" indicates that the first message may originate from either port P1 or port P2, depending on the actual transmission delay of the message in both directions. This method is symmetrically applicable to both scenarios.

[0033] This step establishes a unified reference benchmark for the arrival timing of messages from both ports by starting a time window with the first message reception time as the starting point. This time window defines the effective time range for "association determination," providing a clear time benchmark for subsequent timing association determination of dual-port messages. This makes it possible to distinguish between the two scenarios of "normal recovery" and "timing conflict," thus providing a judgment boundary for accurately identifying timing conflicts in step 20.

[0034] Step 20: Within the time window, in response to receiving the first MRP link status message from the other of the two ring ports, and the link status indicated by the first MRP link status messages received by the two ring ports is different, the ring port that receives the first MRP link status message first is determined as the priority port, and the ring port that receives the first MRP link status message later is determined as the second priority port; the MRC that receives its first MRP link status message through the priority port is determined as the near-end MRC, and the MRC that receives its first MRP link status message through the second priority port is determined as the far-end MRC.

[0035] This step involves determining the content association of the first message received by each of the two ports, within a time window constraint. When the determination condition is met, a timing conflict is confirmed, and port roles and MRC roles are immediately assigned, providing a clear execution target for subsequent differentiated processing.

[0036] Continuing the example above, the MRM starts a time window after receiving message A (MRP_Linkup) from port P1 at time t0. Subsequently, suppose that at some point within the time window, the MRM receives message C from MRC-6 via port P2. Because the link between MRC-5 and MRC-6 briefly recovers and then disconnects again, MRC-6 detects a port failure and generates an MRP_Linkdown message (denoted as message C), which is transmitted to the MRM via port P2. The MRM performs three association checks on this message: Decision 1 (Source Determination): Message C originates from port P2, which is different from the source port P1 of the first message A. If port P2 does not receive any messages within the time window, it is determined to be a normal one-sided recovery, and subsequent processing is not triggered.

[0037] Decision 2 (Content Determination): Message C is MRP_Linkdown (indicating link failure), while message A received by port P1 is MRP_Linkup (indicating link recovery). The link states indicated by the two messages are different. If the first message on both ports indicates "recovery" or both indicate "failure," then there is no timing conflict.

[0038] Decision 3 (Window Decision): The arrival time of message C falls within the time window. If the message arrives after the time window has ended, it is considered a normal sequential recovery and is not associated with the other messages.

[0039] If all three conditions are met, MRM determines that a timing conflict has occurred.

[0040] Based on the determination of timing conflicts, MRM execution roles are divided as follows: Port roles: Port P1, which receives packet A first within the time window, is designated as the priority port, and Port P2, which receives packet C later, is designated as the second priority port. This division is based solely on the order in which packets arrive within the time window.

[0041] MRC Role: The MRC that receives its first MRP link state message via the priority port P1 (i.e., the sender of message A, MRC-5) is identified as the near-end MRC; the MRC that receives its first MRP link state message via the second-priority port P2 (i.e., the sender of message C, MRC-6) is identified as the far-end MRC.

[0042] The terms "near end" and "far end" here do not refer to absolute physical distance, but are a distinction based on the objective timing fact of "whose message arrives at the MRM first in this timing conflict event".

[0043] This step introduces a clear method for determining "timing conflicts," which consists of three verifiable technical conditions: different sources, opposite content, and arrival within the window. This clarifies which is the trusted source (preferred port / near-end MRC) and which is the target of the block (second-preferred port / remote MRC). This provides a direct and clear basis for step 30 to determine "who to process and who not to process" and "which forwarding path to use."

[0044] Step 30: Before determining that the forwarding path from the priority port, through the near-end MRC to the far-end MRC is in a stable state, process each MRP link state message received from the priority port sequentially to manage the loop state, and do not process each MRP link state message received from the second priority port.

[0045] The function of this step is to establish a single, reliable source of information by differentially processing the packets on both ports before confirming that the jittered link has truly returned to stability, thereby blocking the interference of out-of-order packets on loop state management.

[0046] Continuing with the example above, after P1 is determined to be the priority port (near-end MRC is MRC-5) and P2 is determined to be the second priority port (far-end MRC is MRC-6), the MRM executes the following differential processing strategy: 1. For priority port P1, process each received link-state message in sequence: The MRM processes each MRP link status message received from the P1 port in chronological order of arrival and adjusts the loop status accordingly, without omitting or skipping any message.

[0047] For example, within the time window, the MRM first processes message A (MRP_Linkup) received from port P1, adjusting the loop state towards closed-loop. Suppose that subsequently, during the jitter reduction period, port P1 receives messages D (MRP_Linkdown) and E (MRP_Linkup) from the MRC-5 direction. The MRM processes these two messages sequentially: first, message D, adjusting the loop state back towards open-loop; then message E, adjusting it again towards closed-loop.

[0048] The processing mechanism for priority ports ensures that all link status changes in the direction of priority ports (including real new faults occurring in MRC-5 itself or its upstream links) can be promptly detected and responded to by the MRM, and the ring network's redundancy protection capability in this direction is not lost due to anti-jitter operation.

[0049] 2. For the second-highest priority port P2, do not process every received link-state message: For each MRP link status message received from the P2 port, the MRM does not trigger a state machine switch or update the ring network forwarding state, regardless of whether the message content is Linkup or Linkdown.

[0050] For example, if message C (MRP_Linkdown) is received by port P2 within the time window, it will not be processed; if port P2 subsequently receives messages F (MRP_Linkup) and G (MRP_Linkdown) from the MRC-6 direction during the jitter period, these two messages will also not be processed.

[0051] Regarding the processing mechanism for the second-priority port, since all packets from the second-priority port direction may carry unreliable state information during timing conflicts, they are not used as the basis for loop state management decisions until the remote path is confirmed to be stable, thereby cutting off the path for out-of-order packets to interfere with the state machine.

[0052] 3. Termination conditions for shielding: Determining that the forwarding path from the priority port, through the near-end MRC to the far-end MRC, is in a stable state is an objective condition for terminating the blocking of P2 interface packets.

[0053] In this example, the forwarding path specifically refers to the end-to-end forwarding path: P1 → MRC-1 → MRC-2 → MRC-3 → MRC-4 → MRC-5 → MRC-6.

[0054] The connectivity of this path depends on the status of each physical link along it. The link between MRC-5 and MRC-6, which previously experienced jitter, is a key focus of detection, but not the sole determinant of path connectivity. If the path is unobstructed (i.e., all links are functioning normally, especially the link between MRC-5 and MRC-6, which has stabilized), the path is considered stable, the MRM resumes normal processing of P2 interface packets, and the ring network reverts to standard MRP protocol operation. If jitter persists between MRC-5 and MRC-6, the path cannot maintain continuous connectivity. Even if other links along the path (such as those between P1 and MRC-5) are functioning normally, the repeated connectivity issues in the MRC-5 to MRC-6 segment cause the entire forwarding path to exhibit an unstable, intermittent connectivity state. In this case, the MRM maintains processing of P1 interface packets but not P2 interface packets until the forwarding path is confirmed to be stable.

[0055] The reason for using the entire forwarding path (rather than just the segment from MRC-5 to MRC-6) as the judgment object is that the MRM is located at one end of the ring network, and its awareness of the remote link status can only be indirectly achieved through end-to-end probing. If a probe packet sent from the priority port P1 reaches the remote MRC-6 via the near-end MRC-5 within a reasonable time and receives a response, it indicates that the entire path is connected, and it can be inferred that the segment from MRC-5 to MRC-6 has also returned to stability. This indirect judgment method is technically feasible and reliable.

[0056] In related technologies, the MRM performs the same processing logic on MRP link status messages received by both ring ports; that is, any port receiving a state change message triggers the state machine to run. When link jitter causes timing conflicts, the Linkup and Linkdown messages received alternately by the two ports will alternately drive the state machine to switch in opposite directions, which is the direct technical cause of ring network oscillation.

[0057] The difference between this step and related technologies lies in two aspects: First, the processing strategy is differentiated. There is a clear contrast between "processing each packet from the priority port sequentially" and "not processing each packet from the second-priority port." In related technologies, packets from both ports are treated equally, while this method establishes an asymmetric processing relationship. This asymmetric processing eliminates oscillations at the driver source level. The essence of oscillation is that the state machine is alternately driven by two instructions in opposite directions. This scheme, however, retains only the priority port as the driver source during debouncing, and the state machine no longer flips due to packets from the second-priority port.

[0058] Second, the objectification of the blocking termination condition. In related technologies, if a fixed duration of blocking is used, the termination of the blocking is determined only by the preset duration and is unrelated to the actual state of the link. This method binds the termination of the blocking to the objective condition that "the forwarding path from the priority port, through the near-end MRC to the far-end MRC is in a stable state," thus providing a practical physical basis for the decision on the timing of recovery.

[0059] Through this step, the MRM ensures that during timing conflict handling, there is only one trusted packet source on the priority port. The state machine is driven solely by packets from that direction, eliminating the possibility of alternating packet flips on both ports. Simultaneously, processing each packet from the priority port sequentially guarantees the ring network's ability to respond to real faults in that direction, while not processing packets from the secondary priority port ensures that out-of-order packets are completely blocked. The masking termination condition is linked to the confirmation of forwarding path stability, providing an objective basis for recovery timing.

[0060] Using the above method, this embodiment establishes a unified time reference for determining the timing association of dual-port packets by starting a time window with the first packet reception time when the MRP ring network is currently in an open-loop state. Within the time window, the first packets of the two ports are associated based on "different sources and opposite content", providing an operable technical definition for timing conflicts. Priority ports and secondary priority ports are divided based on the "first-come, first-served" timing principle, and the near-end MRC and far-end MRC are determined accordingly, establishing an objective and repeatable role division rule. Before determining that the forwarding path from the priority port through the near-end MRC to the far-end MRC is in a stable state, a differentiated processing strategy is used to process the packets received by the two ring ports, managing the ring network state with a single source, shielding the interference of out-of-order packets on decision-making, and effectively suppressing the occurrence of ring network oscillations.

[0061] In one specific embodiment, a specific implementation method is given for step 30 to determine whether the forwarding path from the priority port, through the near-end MRC to the far-end MRC is in a stable state.

[0062] The following explanation uses the aforementioned MRP ring network in the automotive welding workshop as an example. This ring network consists of one MRM and 15 MRCs, with a total of N=16 nodes. The MRM's P1 port is designated as the priority port (MRC-5 for the near-end MRC), and its P2 port as the secondary priority port (MRC-6 for the far-end MRC). The link between MRC-5 and MRC-6 is the previously faulty link that experienced jitter. While performing differentiated processing, the MRM needs to determine whether the forwarding path from the priority port P1, through the near-end MRC-5 to the far-end MRC-6 (i.e., P1→MRC-1→MRC-2→MRC-3→MRC-4→MRC-5→MRC-6) is stable, in order to decide when to terminate the blocking of packets from the secondary priority port P2.

[0063] If the link is restored too early, it may still be jittering, and out-of-order packets from the second-priority port will again interfere with the state machine, causing repeated oscillations. If the link is restored too late, real fault packets in the second-priority port direction cannot be processed in a timely manner, affecting the ring network's response speed to real faults in that direction. Therefore, determining whether the jitter in the MRC-5 to MRC-6 link has ended is a pressing technical problem that needs to be solved.

[0064] In practical applications, link jitter manifests in two different physical forms: transient disturbances and persistent oscillations. Transient disturbances refer to a link that disconnects / recovers once or a few times within a very short period and then stabilizes on its own; its duration is short and its impact on the network is limited. Persistent oscillations, on the other hand, refer to a link that repeatedly disconnects / recovers over a longer period; its duration is longer and its impact on the network is sustained. These two forms require different recovery strategies: for transient disturbances, dual-port processing should be restored quickly to avoid unnecessary processing delays; for persistent oscillations, shielding should be appropriately extended to allow the link to fully stabilize, avoiding premature recovery that could lead to repeated oscillations.

[0065] The specific implementation of this embodiment includes steps 31 to 34.

[0066] Step 31: Detect whether the forwarding path has been restored within the first time period.

[0067] After determining the timing conflict and performing differentiated processing, the MRM checks within a first duration whether the forwarding path from the priority port P1, through the near-end MRC-5 to the far-end MRC-6, has regained connectivity. This first duration is determined based on the duration of a single link jitter event, and its purpose is to provide a reasonable observation window for possible link self-recovery. In a specific implementation, the MRM can start a timer with a duration of the first duration and perform the detection during the timer's countdown.

[0068] In this embodiment, the restoration of forwarding path connectivity means that all links along the entire forwarding path from the priority port through the near-end MRC to the far-end MRC are in a normal connection state, and packets can be forwarded hop by hop from the priority port to the far-end MRC along this path.

[0069] During the first duration, the MRM continues to implement the differentiated processing strategy, that is, it processes the packets of the priority port P1 in sequence, and does not process the packets of the second priority port P2.

[0070] Step 32: If the forwarding path is detected to have regained connectivity within the first time period, it is determined in advance that the forwarding path is in a stable state.

[0071] If, at any point within the first time period, the MRM detects that the forwarding path has been restored to connectivity, it can determine that the forwarding path is in a stable state without waiting for the first time period to expire. This determination means that the previously occurring link jitter was a transient disturbance, and the link has recovered on its own and is in a normal connectivity state.

[0072] Based on this determination, the MRM terminates its differentiated processing strategy for the second-priority port P2 and resumes normal processing of MRP link-state messages received from the first ring port P1 and the second ring port P2. At this point, the ring network returns to the normal operating state of the standard MRP protocol.

[0073] Step 33: If the forwarding path has not been restored by the end of the first time period, continue to wait for the preset second time period.

[0074] If the MRM still does not detect the restoration of the forwarding path by the end of the first time period, it indicates that the link may be in a state of continuous oscillation, that is, the link between MRC-5 and MRC-6 is still in the process of repeatedly disconnecting and restoring, and has not yet stabilized on its own.

[0075] At this point, the MRM does not immediately resume dual-port processing, but continues to maintain the state of not processing P2 packets on the secondary priority port, and continues to wait for a preset second duration. This second duration is determined based on the duration of the continuous link oscillation, and the second duration is longer than the first duration.

[0076] Continuous oscillations, compared to transient disturbances, last much longer and may take hundreds of milliseconds or even longer to stabilize on their own, or require manual intervention to fully recover. Therefore, the second duration is set to a relatively long value, such as 200ms, to ensure that shielding is maintained during continuous oscillations and to avoid premature recovery leading to repeated state machine flips. In specific implementations, this waiting process can be achieved by the MRM starting a timer with the second duration. The MRM starts this timer after determining that the path has not been restored by the end of the first duration. It maintains shielding of the second-priority port until the timer expires, after which it determines that the path is in a stable state and resumes normal dual-port processing. This second-duration timer is independent of the aforementioned first-duration timer and probe response timer, corresponding to different timing phases in the scheme.

[0077] Step 34: After the second duration expires, confirm that the forwarding path is in a stable state.

[0078] After waiting for the second timeout to expire, regardless of the actual connectivity status of the forwarding path at this time, the MRM determines that the forwarding path is in a stable state and resumes normal processing of packets on both ring ports.

[0079] The aforementioned timeout forced recovery mechanism ensures that differentiated processing will not continue indefinitely due to prolonged link instability. Even if the link does experience a prolonged physical failure, the MRM will resume normal dual-port processing after the second timeout period expires, relinquishing subsequent fault assessment to the standard MRP protocol. If the link remains faulty, the corresponding MRC will regenerate an MRP_Linkdown message, and the MRM will respond normally according to the standard protocol.

[0080] The improvement in this embodiment lies in the introduction of a time-based hierarchical link state confirmation mechanism. This mechanism combines early detection within a first time period with extended waiting in a second time period, enabling the differentiation and handling of transient disturbances and continuous oscillations. Specific details are as follows: In related technologies, one approach is for the MRM to set a fixed-length masking period after receiving a packet with an uncertain state, during which all port packets are ignored. This approach has significant drawbacks: for transient disturbances, an excessively long masking period delays actual fault recovery; for sustained oscillations, a fixed masking period cannot be dynamically adapted, and the link may still be jittering when the masking period ends. Another approach is for the MRM to process each packet immediately without any waiting or inspection. This approach inevitably leads to repeated state machine flips during link jitter.

[0081] This embodiment achieves the following improvements through a tiered processing mechanism that detects and allows early recovery within the first time period, and extends the waiting time to a second time period if necessary: First, by setting a first duration based on the duration of a single jitter, a reasonable observation window is provided for the link to recover on its own, avoiding premature judgment during the jitter process; Second, by allowing path stability to be determined in advance after path connectivity is restored at any time within the first duration, dual-port processing can be quickly restored without waiting for the first duration to expire in the case of transient disturbances, thus minimizing the fault recovery time. Third, by setting a second duration based on the duration of continuous oscillation, a longer shielding protection period is provided for continuous oscillation scenarios, avoiding repeated oscillations caused by premature recovery. At the same time, the boundedness of recovery is ensured by the forced recovery after timeout.

[0082] Based on the above improvements, this embodiment achieves differentiated processing of link jitter and determines the appropriate timing for restoring dual-port processing accordingly. Specifically: for transient disturbances, the link recovers automatically within the first time period, and the MRM restores dual-port processing as soon as it detects that the forwarding path has regained connectivity, minimizing unnecessary processing delays; for continuous oscillations, if the link has not regained connectivity by the end of the first time period, the MRM continues to maintain differentiated processing until the end of the second time period, providing sufficient stability observation period for the link and avoiding repeated oscillations caused by premature recovery. This management method provides reasonable and controllable exit conditions, giving the decision on the recovery timing an objective basis related to the actual state of the link, thus improving the accuracy of management.

[0083] In one specific embodiment, a detailed implementation method for detecting whether the forwarding path has been restored to connectivity is provided for step 31. This implementation achieves accurate determination of the connectivity status of the forwarding path through an active probing mechanism that sends probe messages and waits for a response for a timer.

[0084] The following explanation uses the aforementioned MRP ring network in the automotive welding workshop as an example. This ring network consists of one MRM and 15 MRCs, with a total of N=16 nodes. The MRM's first ring port P1 is designated as the priority port (the near-end MRC is MRC-5), and the second ring port P2 is designated as the secondary priority port (the far-end MRC is MRC-6). The link between MRC-5 and MRC-6 is the previously faulty link that experienced jitter. After the first duration expires, the MRM needs to check whether the forwarding path from the priority port P1, through the near-end MRC-5, to the far-end MRC-6 has been restored.

[0085] Therefore, after the first timeout period expires, it is necessary to accurately and reliably obtain the connectivity status of the forwarding path from the priority port, through the near-end MRC to the far-end MRC. The detection method used must meet the following requirements: First, the detection target should accurately cover the forwarding path to be judged, rather than other parts of the ring network; second, the detection result should be deterministic, clearly distinguishing between "connected" and "disconnected" states; third, the detection process should not interfere with the normal operation of the MRP standard protocol.

[0086] The specific implementation of this embodiment includes steps 311 to 312.

[0087] Step 311: Start the first duration of timing and send a probe message from the priority port. The destination address of the probe message is the remote MRC.

[0088] This first duration is used to limit the maximum time for waiting for a response message. The specific value of this first duration should be greater than the round-trip time for a probe message to travel from P1 to MRC-6 and return a response message under normal network conditions, while being short enough to ensure detection efficiency; for example, it can be set to 10ms to 20ms. In a practical implementation, this timing process can be achieved by starting a probe-response timer through the MRM, and the duration of this timer is equal to the first duration used to limit the maximum time for waiting for a response message.

[0089] The MRM sends probe messages when starting the timer and determines path connectivity based on whether a response message is received before the timer expires.

[0090] The processing rules for probe packets by each MRC in the ring network are as follows: When an MRC receives a probe packet, it checks the destination address of the packet. If the destination address is not its own MRC, the probe packet is forwarded from another ring port to the next hop MRC according to the ring network forwarding rules; if the destination address is its own MRC (i.e., remote MRC-6), the probe packet is terminated, and the aforementioned response packet is generated and sent from the ring network port that received the probe packet, returning to the MRM via the original path. This processing rule is consistent with the forwarding and termination rules of data packets by MRCs in the standard MRP protocol, making it simple to implement and not interfering with the normal transmission and reception of MRP standard protocol packets (such as MRP_Linkup, MRP_Linkdown, etc.).

[0091] For example, the MRM sends a probe packet from the priority port P1, with the destination address set to the address of the remote MRC-6. After the probe packet is sent from port P1, it is transmitted hop-by-hop along the ring network forwarding path: P1→MRC-1→MRC-2→MRC-3→MRC-4→MRC-5→MRC-6. Each MRC in the ring network processes the probe packet according to the standard ring network forwarding rules. When an MRC detects that the destination address of the probe packet is not itself, it forwards it from the ring port to the next hop MRC.

[0092] The design, with the destination address being the remote MRC-6, ensures that the transmission path of the probe packet completely overlaps with the forwarding path (P1 to MRC-6) to be detected. Whether the probe packet can successfully reach MRC-6 and trigger a response directly reflects the connectivity status of the entire forwarding path, especially the actual status of the jitter link between MRC-5 and MRC-6.

[0093] Step 312: Determine whether the forwarding path has been restored based on whether a response message is received within the time limit.

[0094] In the first scenario, if the MRM receives a response message from the remote MRC-6 with the destination address of the probe message as the MRM from the priority port P1 before the first timeout period ends, it indicates that the probe message successfully traversed the entire forwarding path to reach MRC-6, and the response message from MRC-6 also successfully returned to the MRM along the original path. This means that all links on the forwarding path (especially the jitter link between MRC-5 and MRC-6) are currently connected. The MRM determines that the forwarding path has been restored based on this.

[0095] In the second scenario, if the MRM does not receive a response message from the remote MRC-6 with the destination address of the probe message at the end of the first timeout period, it indicates that the probe message failed to reach MRC-6 within the first timeout period, or that the response message from MRC-6 failed to return to the MRM within the first timeout period. This typically means that the link between MRC-5 and MRC-6 on the forwarding path is currently disconnected or unstable, causing the message to be lost in that segment. Based on this, the MRM determines that the forwarding path has not been restored to connectivity.

[0096] Compared with several detection methods that may be used in related technologies, this embodiment adopts an active detection mechanism that points the destination address to a remote MRC and a timing response judgment mechanism to achieve accurate detection of the connectivity status of a specific forwarding path. Specific details are as follows: One possible approach in related technologies is to indirectly infer the link status by observing whether the port receives MRP standard messages from the remote end. This method is a passive observation, relying on whether the remote MRC happens to be sending messages, and cannot guarantee the timeliness and proactivity of the detection.

[0097] Another possible approach in related technologies is loopback detection using MRP_Test messages. MRP_Test messages are standard protocol messages sent by the MRM from a congested port, looping around the ring once, and then retrieved from another port, with their transmission path covering the entire ring network. When an MRP_Test message is lost, it can only indicate a fault at some point in the ring network, but cannot pinpoint the exact location of the fault to the specific forwarding path of "priority port via near-end MRC to far-end MRC". Furthermore, if other links on the ring network also experience faults, the MRP_Test detection results will be interfered with, making it impossible to distinguish whether the fault originates from the current path or another path.

[0098] This embodiment directly sets the destination address of the probe packet to the remote MRC, ensuring that the probe path precisely overlaps with the forwarding path to be detected. Simultaneously, the reception or non-reception of the response packet directly reflects the connectivity status of that specific path, eliminating interference from the link status of other parts of the ring network and achieving higher detection accuracy. Furthermore, a timing mechanism limits the waiting time, guaranteeing the determinism of the detection results and the efficiency of the detection process.

[0099] It should be noted that detecting whether the forwarding path from the priority port, through the near-end MRC to the far-end MRC, has been restored is not limited to the method described above of sending a dedicated probe packet and waiting for a response packet. Other feasible implementation methods are listed below.

[0100] Method 1: Based on passive observation of the port.

[0101] Instead of actively sending probe messages, the MRM observes whether any MRP standard messages (such as MRP_Linkup or MRP_Linkdown messages) originating from the near-end MRC and sourced from the far-end MRC are received from the priority port during the detection period. If received, it indicates that the forwarding path from the far-end MRC to the MRM is connected. Due to the symmetry of the ring network forwarding path, it can be inferred that the reverse path is also connected, thus confirming that the forwarding path has been restored. If not received, it is determined that the forwarding path has not been restored.

[0102] This method does not require sending additional messages, making it simpler to implement. However, it depends on whether the remote MRC sends messages spontaneously, and the timeliness of detection may not be as good as the active detection method.

[0103] Method 2: Proxy detection via near-end MRC.

[0104] Instead of sending probe packets directly from the priority port, the MRM sends a command packet to the near-end MRC (MRC-5) through the priority port, instructing MRC-5 to initiate a link connectivity probe to the far-end MRC (MRC-6) on behalf of the MRM. MRC-5 sends probe packets to MRC-6 and, depending on whether a response is received, reports the probe results back to the MRM. The MRM determines whether the forwarding path has been restored based on the reported results.

[0105] This method moves the probe initiation point from the MRM to the near-end MRC, which is closer to the target link. This shortens the transmission path of probe messages and improves detection speed. Furthermore, since the probe only occurs between MRC-5 and MRC-6, it consumes less bandwidth for other nodes in the ring network.

[0106] The above-mentioned detection methods can determine whether the forwarding path from the priority port, through the near-end MRC to the far-end MRC, has been restored to connectivity. Those skilled in the art can choose the appropriate method to implement this according to the actual application scenario and equipment capabilities.

[0107] In one specific embodiment, a detailed implementation method is provided for step 31 to determine whether a valid response has been received based on the sending of probe messages and the receiving of response messages. This implementation method determines a response as valid only after at least two rounds of probe interactions are completed during the first duration, using a multi-round consistency verification mechanism to avoid incorrect judgments due to a single successful message interaction.

[0108] The following explanation uses the aforementioned MRP ring network in an automotive welding workshop as an example. In a scenario where the link is in a state of continuous oscillation, the link between MRC-5 and MRC-6 may be in an unstable state with intermittent connectivity. In this case, the following situation may occur: a probe packet arrives at MRC-6 within the extremely short time window during which the link recovers, and MRC-6 receives the probe packet and successfully returns a response packet. If the MRM determines that the forwarding path has been restored based solely on this one response, and thus resumes packet processing on the second-priority port, the link is still actually in an unstable state. Subsequent out-of-order packets may still interfere with the state machine again, weakening the debouncing effect.

[0109] Therefore, the technical problem that needs to be solved is: how to improve the reliability of judging the connectivity of the forwarding path based on the probe response, and avoid making wrong recovery decisions due to the accidental success of a single probe in an unstable link state.

[0110] The specific implementation method of this embodiment includes: In step 311, during the first duration of the timer, the probe message is sent at least twice.

[0111] During the first duration of the timer, the MRM is not limited to sending a probe message only once and waiting for a response, but rather sends probe messages at least twice. After each transmission, the MRM waits for a corresponding response message from the remote MRC-6. Each complete transmission and reception process constitutes one round of probe interaction.

[0112] It should be noted that multi-round probe interactions can be performed sequentially, i.e., after sending a probe message and receiving a corresponding response message, a probe message is sent again immediately or after a preset time interval, and the corresponding response is awaited; or they can be performed in parallel, i.e., after sending a probe message, a probe message is sent again without waiting for a response, and then the responses are received separately. As long as at least two independent probe message transmissions and corresponding response message receptions are completed within the first duration, the condition of "at least two" is met.

[0113] In step 312, if at least two response messages corresponding to the probe messages are received, it is determined that the forwarding path has been restored; otherwise, it is determined that the forwarding path has not been restored.

[0114] The MRM determines that a valid response has been received from the remote MRC-6 only after receiving at least two response messages corresponding to each probe message within the first duration of the timeout period. This confirms that the remote MRC-6 has been consistently and stably receiving probe messages and returning response messages during the current detection period, rather than having only a single, accidental successful interaction. Based on this determination of a valid response, the MRM can be certain that the forwarding path is indeed connected, and thus determines that the forwarding path has been restored.

[0115] If the MRM receives fewer than two response messages at the end of the first timeout period (e.g., only one response message or no response messages), the MRM does not consider it a valid response and treats it as a case where the forwarding path has not been restored. In this case, the MRM determines that the forwarding path has not been restored and starts the second timeout period to continue blocking the second-priority port.

[0116] Compared to the method of making a judgment based on a single probe, the improvement of this embodiment lies in the introduction of a multi-round consistency verification mechanism, which uses the consistent results of multiple probe interactions as the basis for judgment, rather than relying on the accidental results of a single interaction.

[0117] The single-probe method has the following limitations: When the link is in a state of continuous oscillation, there is a possibility that the moment of link instantaneous recovery may coincide with the moment of probe packet transmission, resulting in a successful single probe. The "path connection restored" judgment based on this single success does not accurately reflect the true state of the link (for example, the link may disconnect again immediately after this successful interaction). This misjudgment will cause the MRM to prematurely resume processing of packets on the second-priority port, which may then trigger state machine oscillation again.

[0118] This embodiment ensures that the reception of response messages is not an isolated or accidental success, but rather a stable connectivity performance that can be repeated over a certain time span, by requiring at least two rounds of probe interactions to be completed within the first duration. Only when the link remains connected within the time span of at least two rounds of probe interactions can the remote MRC continuously receive probe messages and return responses. This multi-round verification design significantly reduces the risk of misjudgment due to momentary accidental connectivity. At the same time, constraining the time limit of multi-round verification within the first duration ensures that the verification process will not be extended indefinitely, guaranteeing detection efficiency.

[0119] This embodiment utilizes the aforementioned multi-round verification mechanism. The MRM's judgment on restoring connectivity to the forwarding path is based on the consistency verification of multiple probe interactions, rather than relying on the accidental result of a single interaction. This significantly improves the reliability of the detection results, effectively avoiding erroneous recovery decisions caused by the accidental success of a single probe under unstable link conditions, and providing a more reliable triggering condition for initiating the second duration of timing. Simultaneously, the timing of the first duration imposes time constraints on the verification process, ensuring that detection efficiency is not affected.

[0120] It should be noted that the methods for implementing multi-round verification to improve detection reliability are not limited to the aforementioned approach of "completing at least two rounds of detection interaction within the first time period." Other feasible implementation methods are listed below.

[0121] Method 1: Verification based on the number of consecutive successes.

[0122] During the initial timing period, the MRM continuously sends multiple probe messages. It does not preset a fixed threshold for the number of rounds of interaction, but rather dynamically sets it based on the actual application scenario—a higher threshold, such as three or four rounds, is set when there is a history of frequent link oscillations; a lower threshold is set when there is a history of fewer link oscillations. A response is considered valid only when the number of consecutively successfully received response messages reaches the set threshold.

[0123] Method 2: Verification based on success rate.

[0124] MRM sends a predetermined number of probe packets (e.g., five) during the first duration of the timer and counts the percentage of successfully received response packets. When the success rate reaches a preset threshold (e.g., no less than three-fifths, or 60%), a valid response is considered received. This method allows for a certain percentage of packet loss while ensuring the reliability of the overall connectivity assessment, making it suitable for environments with significant network quality fluctuations.

[0125] Method 3: Two rounds of successful verification based on the minimum time interval.

[0126] During the first duration of the MRM, at least two successful probe interactions are required, with the time interval between the two successful interactions not less than a preset minimum time interval (e.g., 5ms). This minimum time interval is greater than the duration of a typical single jitter, ensuring that the two successful interactions span a sufficient time span, rather than being completed consecutively within the same short connectivity window. This approach further reduces the risk of accidental successes by increasing the time span constraint.

[0127] The above methods can improve detection reliability through multiple probe interactions and avoid misjudgment caused by a single accidental success. Those skilled in the art can choose the appropriate method to implement the method based on factors such as the actual network environment, equipment processing capabilities, and reliability requirements.

[0128] In one specific embodiment, a concrete implementation method is provided to distinguish probe and response messages from standard MRP protocol messages. This implementation method carries specific message type information in at least one of the probe and response messages, making the probe interaction process in this scheme independent of and non-interfering with the message interaction defined by the MRP standard protocol.

[0129] The following explanation uses the aforementioned MRP ring network in an automotive welding workshop as an example. The MRM sends probe messages from its priority port P1 to the remote MRC-6, and the MRC-6 returns a response message upon receiving the probe message. Both messages are transmitted within the ring network, coexisting with the MRP_Linkup, MRP_Linkdown, and MRP_Test messages defined in the MRP standard protocol. The technical problem that needs to be solved is how to enable the MRC-6 to identify the probe messages as different from standard MRP protocol messages and process them accordingly, while simultaneously enabling the MRM to distinguish the response message from the standard protocol message.

[0130] In the MRP standard protocol, the behavior of MRC has been clearly standardized: when MRC detects a port state change, it generates an MRP_Linkup or MRP_Linkdown message; when it receives an MRP standard message with its destination address as itself, it terminates and processes it according to the protocol; and when it receives an MRP standard message with its destination address as other than itself, it forwards it from the ring port.

[0131] The interaction between probe and response messages introduced in this scheme is independent of the standard MRP protocol process described above. Without special distinction, when the MRC receives a probe message, it may fail to recognize the message type and process it according to the default rules (discarding it or forwarding it according to the standard process), leading to probe functionality failure or abnormal standard protocol processing. Similarly, when the MRM receives a response message, if it does not differentiate between them, it may mistakenly treat it as a standard MRP protocol message and process it in the state machine, causing incorrect state transitions.

[0132] Therefore, the technical problem that needs to be solved is: how to effectively distinguish probe messages and response messages from standard MRP protocol messages, and ensure that the probe interaction process runs independently without interfering with the normal processing flow of the standard MRP protocol.

[0133] The specific implementation method of this embodiment is as follows: message type information is carried in at least one of the probe message and the response message.

[0134] In this embodiment, both probe and response messages carry message type information. Specifically, the probe message carries a message type field, which takes a specific value that differs from the message type values ​​in the MRP standard protocol. For example, in the MRP standard protocol, MRP_Test, MRP_Linkup, MRP_Linkdown, and MRP_TopologyChange messages each have corresponding type values. This scheme assigns a type value to the probe message that is different from all of the above type values.

[0135] exist Figure 1In the application scenario shown, when a probe packet arrives at the remote MRC-6 along the forwarding path, the MRC-6 parses the packet's packet type field and identifies that the packet is not a packet type defined by the MRP standard protocol, but rather a private probe packet type defined by this solution. Based on this identification result, the MRC-6 does not process the packet according to the standard MRP protocol (e.g., does not trigger state change reporting), but instead stops forwarding the packet to the next hop in the ring network according to preset private processing rules, and generates a response packet to return to the MRM.

[0136] Similarly, the response message also carries the same message type field as the probe message. When the response message is returned to the MRM, the MRM parses this field to distinguish it from the standard MRP protocol message, recognizing that it is a response to the probe message, rather than a link state change notification from MRC-6. Based on this, the MRM uses the response message for forwarding path connectivity determination, instead of sending it to the standard MRP state machine processing flow.

[0137] Based on the above message type information, each node in the ring network that receives a probe message or response message can clearly distinguish it from a standard MRP protocol message and execute the corresponding processing logic accordingly: For standard MRP protocol messages, each node processes them according to the procedures specified in the MRP standard protocol. Specifically, Linkup / Linkdown messages are used to notify of changes in the MRM port status, MRP_Test messages are used for ring network connectivity detection, and MRP_TopologyChange messages are used to announce topology changes.

[0138] For probe and response messages carrying specific message type information of this scheme, they are processed according to the private processing rules preset in this scheme. After the probe message arrives at the destination MRC, the destination MRC stops forwarding the message to the next hop of the ring network, generates a response message and returns it to the MRM and triggers a response. The response message is used for path connectivity judgment after arriving at the MRM and does not trigger the operation of the MRP state machine.

[0139] This step explicitly carries independent message type information in at least one of the probe and response messages, making the distinction clear and parsable, independent of implicit message characteristics, and without occupying type values ​​already defined in standard protocols. MRC can make an accurate judgment based solely on the message type field, and the processing logic is simple and reliable.

[0140] The improvement of this embodiment lies in achieving differentiation through explicit identification of message type information, rather than relying on implicit or indirect differentiation methods.

[0141] It should be noted that distinguishing probe and response messages from standard MRP protocol messages is not limited to the method described above where both messages carry the information. Distinction can be achieved as long as at least one of the probe and response messages carries message type information for differentiation. Other feasible implementation methods are listed below.

[0142] Method 1: Only detect messages that carry message type information.

[0143] The probe message carries specific message type information. Upon receiving the message, the remote MRC-6 identifies it as a private probe message based on its type information, terminates it according to preset rules, and generates a response message. The response message may not carry this type information and instead uses the standard MRP message format. The MRM identifies it as a response to the probe message, rather than a standard link state change message, based on contextual judgment—that is, the time context of "receiving the message from the remote MRC within the timing period." This method reduces the need for structural modifications to the response message and simplifies implementation.

[0144] Method 2: Only the response message carries message type information.

[0145] Probe messages use the standard MRP message format or a near-standard format, and are identified by the remote MRC-6 based on specific identifiers carried in the message (such as a combination of the MRM identifier and the remote MRC identifier). When generating a response message, MRC-6 carries specific message type information in the response message. Upon receiving the message, the MRM explicitly identifies it as a probe response message based on the type information. The advantage of this method is that probe messages can reuse existing standard protocol message formats, reducing the introduction of new message types.

[0146] Method 3: Implicit differentiation through a combination of MRM identifier and remote MRC identifier.

[0147] Both probe and response messages use the standard MRP message format and do not carry independent message type information. However, they carry a combination of the MRM identifier and the remote MRC identifier in specific fields of the message. When MRC-6 receives a message with its destination address as itself, and that message contains both the MRM identifier and the identifier that the local machine is the remote MRC, MRC-6 recognizes it as a probe message of this scheme and processes it according to preset rules. Similarly, when the MRM receives a response message containing the remote MRC identifier, it distinguishes it from standard messages based on the identifier combination. This method does not require the allocation of new type values ​​and is implemented entirely within the message format framework defined by the standard protocol.

[0148] Method 4: Differentiate by the context of the sending and receiving ports.

[0149] Neither probe nor response messages carry additional type information or identification fields. The MRM sends probe messages from the priority port, and MRC-6 identifies the probe messages according to preset rules (such as destination address matching) and returns a response. The MRM identifies a message as a response message based on the message context: "received within the time limit, from the priority port, and with a source address from the remote MRC." This method is the simplest, without modifying the message structure at all, but it requires a high level of management of the message sending and receiving context.

[0150] All of the above methods aim to distinguish probe messages and response messages from standard MRP protocol messages. Those skilled in the art can choose the appropriate method to implement this based on factors such as actual equipment capabilities and protocol compatibility requirements.

[0151] In one specific embodiment, a method for determining the duration of the time window T in step 10 is provided. This implementation introduces three factors—network size coefficient k, historical jitter average Δt_avg, and base latency T_base—to jointly calculate the duration of T, enabling T to be dynamically adjusted according to the actual size of the ring network and the historical jitter of the links, rather than using a fixed duration value.

[0152] In the process of determining timing conflicts, the duration of the time window T is crucial. If T is too short, it may not cover the normal arrival time of packets from the other port, causing scenarios that should be identified as timing conflicts to be missed. If T is too long, it may include packets that recover normally in sequence within the scope of the judgment, leading to false judgments of timing conflicts. Therefore, the technical problem that needs to be solved is: how to reasonably set the value of the time window T to achieve a reasonable balance between missed judgments and false judgments.

[0153] This embodiment proposes that the duration T is determined by three factors: the network size coefficient k, the historical jitter average Δt_avg, and the base latency T_base. The meanings and functions of each of the three factors are as follows: Base delay T_base: Reflects the physical loopback delay required for a message to complete one cycle in the MRP ring network, providing a minimum delay for T that is related to the physical size of the ring network; Historical jitter mean Δt_avg: reflects the historical fluctuation of link jitter in the ring network, enabling T to be dynamically adjusted based on recent jitter characteristics; Network size coefficient k: T is proportionally amplified based on the total number of nodes in the ring network, so that T can adapt to the transmission delay differences of ring networks of different sizes.

[0154] The three factors jointly constrain the time window T from three dimensions: "physical latency guarantee", "historical jitter learning" and "scale ratio adaptation". This allows the time window T to be dynamically adjusted according to the ring network size and historical jitter, avoiding the problems of "misjudgment due to excessively long window" or "missed judgment due to excessively short window" that may occur in different scenarios with a fixed window.

[0155] Compared to using only a single factor, the three-factor joint calculation introduces corrections from two dimensions: the historical jitter mean and the scale coefficient. A window using only T_base cannot reflect the jitter history of the ring network; for example, the required decision window length differs between a ring network experiencing frequent recent jitter and one that has been stable for a long time. In a frequently jittering environment, the time span of interleaved packet arrivals may be longer, requiring a longer window to cover them; in a long-term stable environment, a shorter window is sufficient for decision-making, and an excessively long window may misjudge normal sequential recovery as timing conflicts. The introduction of Δt_avg compensates for this deficiency, enabling T to adaptively adjust according to the actual jitter situation.

[0156] The introduction of `k` addresses the deficiency of `T_base`, a single loopback delay, in reflecting the difference in transmission delay across different paths between two ports. `T_base` reflects the loopback delay of a complete cycle in the ring network, while timing conflict determination considers the packets received by the two ports in different forwarding directions, where the number of hops can differ significantly. For example, in a ring network within an automotive welding workshop, the path from P1 to MRC-5 requires only 4 hops, while the path from P2 to MRC-6 requires 9 hops, resulting in a significant difference in transmission delay. `k`, through proportional scaling, allows `T` to better cover the interleaved arrival time range of packets between the two ports, avoiding missed detections due to differences in transmission delay between the two directions.

[0157] In this embodiment, the duration of the time window T is determined according to the following calculation expression: T = k × (Δt_avg + T_base); Among them, T, k, Δt_avg, and T_base are all greater than 0.

[0158] In the above calculation expression, the network size coefficient k amplifies the sum of the base delay T_base and the historical jitter mean Δt_avg as a whole, rather than using k to amplify only one of the terms.

[0159] In timing conflict resolution scenarios, the complete time span that the time window needs to cover is the time difference between when one message arrives at the MRM from the near-end MRC and when another message arrives at the MRM from the far-end MRC. This time difference consists of two parts: Physical transmission component: The physical transmission time of a message on the ring network path, reflected by T_base; Jitter fluctuation component: The additional deviation in packet arrival time caused by link jitter, reflected by Δt_avg.

[0160] In real-world networks, as the size of the ring network increases and the number of nodes grows, not only does the physical transmission path lengthen, leading to a greater physical transmission component, but the queuing and processing time fluctuations of packets at the relay MRC also increase due to the increased number of relay nodes. This means that the packet arrival time deviation caused by the same link jitter event is more significant in large ring networks than in small ring networks. In other words, the degree of jitter fluctuation reflected by Δt_avg has different impacts on the actual arrival time difference in ring networks of different sizes; in large ring networks, the same degree of jitter fluctuation results in a larger actual arrival time deviation.

[0161] Therefore, k should not only amplify T_base to accommodate the differences in physical transmission path length, but also simultaneously amplify Δt_avg to accommodate the increased jitter due to the larger scale. By adopting an overall amplification form of k × (Δt_avg + T_base), the adjustment effect of k is made consistent for both time components, ensuring that the time window can adapt to the ring network scale in both dimensions of physical transmission delay and jitter fluctuation.

[0162] Taking an automotive welding workshop ring network as an example, a small ring network (N=6) containing 5 MRCs and a large ring network (N=31) containing 30 MRCs, even if their historical jitter average Δt_avg is numerically the same (e.g., 8ms), the actual impact of link jitter on the time of arrival (TOA) of packets differs between the two ring networks. In the large ring network, packets have more hops and longer transmission paths, leading to a larger TOA deviation for the same level of link jitter. Simply amplifying T_base without amplifying Δt_avg cannot fully reflect the comprehensive impact of increased scale on window time requirements.

[0163] Furthermore, in scenarios with a large Δt_avg, i.e., when the ring network experiences frequent and severe jitter recently, the window extension of k × T_base + Δt_avg is limited by the value of Δt_avg, while Δt_avg is not adjusted by k. For example, when the ring network is large (k is 1.3) and jitter is frequent (Δt_avg is large), this form cannot fully utilize the size coefficient to extend the overall window, which may result in the window length being insufficient to cover the interleaved arrival time span of dual-port packets, leading to missed detections.

[0164] Furthermore, the actual impact of the same jitter event on packet arrival time difference differs across ring networks of different sizes. In large ring networks, due to longer forwarding paths and more relay nodes, the same link jitter will cause packet arrival times to fluctuate over a larger time range. Therefore, adopting an overall amplification form of k × (Δt_avg + T_base) is a reasonable reflection of this actual impact, ensuring that the overall window duration remains positively correlated with the ring network size.

[0165] The calculation method provided in this embodiment amplifies the sum of T_base and Δt_avg, ensuring that the window duration adapts synchronously to the ring network size across both physical transmission latency and jitter fluctuations. Whether for small or large ring networks, T maintains a reasonable coverage range based on node size and jitter history, eliminating blind spots in size adaptation. Furthermore, the linear positive correlation between T and k allows the window duration to smoothly extend with the ring network size, facilitating deployment and parameter tuning in MRP ring networks of different sizes.

[0166] The determination methods for each factor will be described below.

[0167] 1. Determining the base latency T_base: The base delay T_base is a value determined based on the loopback transmission delay of the MRP ring network. Its function is to provide a minimum delay for T that is not less than the physical loopback delay.

[0168] The specific determination method in this embodiment is as follows: The base delay T_base is the loopback transmission delay, determined by the difference between the time the MRM sends the MRP_Test message and the time it receives the MRP_Test message in the closed-loop state of the MRP ring network. The MRP_Test message is a standard protocol message periodically sent by the MRM from the blocked port in the closed-loop state. This message is forwarded once around the ring network and then retrieved from another ring port of the MRM. The difference between the sending time T and the receiving time t2 is the complete time for the message to complete one loopback transmission in the ring network, reflecting the actual transmission delay of the ring network under the current physical topology.

[0169] The advantage of using the loopback delay of the MRP_Test message as the source of T_base is that this delay is measured under the actual operation of the ring network, and includes the transmission delay of each link segment and the forwarding processing delay of each MRC. It can truly reflect the end-to-end physical transmission time of the ring network and ensure that T is not less than the time required for the message to complete a complete transmission on the ring network.

[0170] In the example of the ring network in the automotive welding workshop, the ring network consists of 1 MRM and 15 MRCs (N=16). Under normal operating conditions, the difference between the sending and receiving times of the MRP_Test message recorded by the MRM is approximately 10ms, therefore the value of T_base is approximately 10ms.

[0171] Other alternative implementation methods: Method 1: T_base can also be determined based on the theoretical delay calculation of the ring network. Specifically, the MRM calculates the theoretical time required for a packet to complete one loop transmission in the ring network based on known parameters such as the transmission rate of each link segment, the link length, and the forwarding processing delay of each MRC, and uses this as T_base. This method does not rely on the actual measurement of MRP_Test messages and can obtain T_base even when the network has not yet entered the closed-loop stable operation phase or when the MRP_Test message mechanism is unavailable.

[0172] Method 2: T_base can also use a preset fixed value. For example, based on engineering experience, for ring networks with no more than a certain number of nodes, a minimum protection duration covering most scenarios can be set as T_base and directly configured in the MRM. This method is the simplest to implement, requiring no measurement or calculation, and is suitable for scenarios where latency accuracy requirements are not high.

[0173] 2. Determination of the historical jitter mean Δt_avg: The historical jitter mean Δt_avg is a statistical value determined based on the difference in reception time between the MRP_Linkup and MRP_Linkdown messages in each of the most recent link jitter events. Its function is to enable T to dynamically adjust based on the recent jitter characteristics of the ring network, possessing a certain historical learning capability.

[0174] The specific determination method in this embodiment is as follows: When a link jitter event has occurred in the MRP ring network, the MRM records the reception times of the MRP_Linkup and MRP_Linkdown messages received sequentially during each jitter event and calculates the difference between the two times. The average of the three most recent differences is taken as Δt_avg. If no link jitter event has occurred previously, the initial value of Δt_avg is 0.

[0175] Each jitter event corresponds to the arrival of a pair of MRP_Linkup and MRP_Linkdown messages, including both cases where "Linkup is received first and Linkdown is received later" and cases where "Linkdown is received first and Linkup is received later". Both can be included in the statistics.

[0176] The advantages of incorporating Δt_avg into the T calculation are as follows: This mean is calculated based on jitter data closest to the current moment in the time dimension, which can accurately reflect the actual jitter level of the link in the recent period, rather than being interfered with by jitter information that has already failed in the early period, thus ensuring the timeliness of T adjustment; at the same time, the fixed-number statistical method is simple to calculate and has low storage overhead, making it suitable for efficient implementation on embedded network devices; when there is no historical data, the initial value of Δt_avg is 0, and T is determined only by T_base and k, providing a reasonable conservative default behavior for the scheme.

[0177] Other alternative implementation methods: Method 1: The number of events counted is not limited to 3. You can take the average of the intervals between the most recent 2, 5, or other preset number of events. Alternatively, you can take the average of all jitter event intervals within a sliding time window, provided that the minimum sample size is met.

[0178] Method 2: Δt_avg can also be calculated using a weighted moving average. For example, more recent jitter events can be assigned higher weights, while the weights of earlier events decrease sequentially, making Δt_avg more sensitive to recent trends in jitter intensity. Alternatively, jitter intervals can be calculated separately for different ring port directions or different faulty links, and the larger value or a weighted sum can be used as the final Δt_avg.

[0179] 3. Determining the network size coefficient k: The network size coefficient k is dynamically configured based on the total number of nodes N in the MRP ring network, and its value is positively correlated with the value of N. The function of k is to scale up T proportionally, so that the time can adapt to the differences in transmission delay of messages in both directions in ring networks of different sizes.

[0180] The specific determination method in this embodiment is as follows: The value of k is determined according to the following hierarchical rules: when N ≤ 10, k is 1; when 10 < N ≤ 15, k is 1.1; when N > 15, k is 1.3. The MRM obtains the total number of ring network nodes N through the topology discovery function and dynamically sets the value of k according to the above rules.

[0181] The advantages of using a hierarchical configuration are: firstly, the impact of the ring network node size on the transmission delay difference is not a strictly linear relationship, and hierarchical configuration can simplify calculations and reduce the processing burden of MRM; secondly, the three value levels (1, 1.1, 1.3) correspond to small, medium and large ring networks respectively, which can cover the actual scale range of most industrial network deployment scenarios.

[0182] In the example of the ring network in the automotive welding workshop, the total number of ring network nodes N=16, which falls into the category of N > 15, so k is taken as 1.3. If the number of ring network nodes is small, such as a ring network consisting of only 5 MRCs (N=6), then k is taken as 1, and T is determined only by T_base and Δt_avg, without any additional amplification.

[0183] Other alternative implementation methods: Method 1: k can also be a function that is continuously related to N, for example, k = 1 + α × (N - N0), where α is a preset scaling factor and N0 is the number of baseline nodes. This method can provide smoother scaling and avoid abrupt window changes caused by hierarchical jumps.

[0184] Method 2: k can also be determined by looking up a table, which stores the k values ​​corresponding to different N values ​​or N value ranges. When N exceeds the preset maximum range, k can be determined by interpolation or taking boundary values ​​to ensure that the value of k is always bounded.

[0185] The determination of each of the above factors aims to achieve a reasonable calculation of T. Those skilled in the art can choose an appropriate method or combination thereof based on factors such as the actual ring network environment, equipment processing capacity, and accuracy requirements.

[0186] The above embodiments are all illustrated using the example of the MRM receiving the MRP_Linkup message first. It should be noted that this solution has symmetrical applicability to the first packet type; the processing logic is completely consistent regardless of whether the first MRP link status message arriving at either of the two ring ports is MRP_Linkup or MRP_Linkdown. The following provides a complete example scenario where an MRP_Linkdown message is received first.

[0187] Taking the aforementioned MRP ring network in the automotive welding workshop as an example, the link between MRC-5 and MRC-6 was previously disconnected due to the network cable being unplugged. The MRM has now controlled the MRP ring network to an open-loop state, with both P1 and P2 in forwarding mode.

[0188] At a certain moment, the link between MRC-5 and MRC-6 is momentarily restored (e.g., the network cable is reinserted and makes good contact). MRC-5 detects that the port status has changed to Link Up, generates an MRP_Linkup message (denoted as message A), and sends it to the MRM's P1 port along the MRC-4, MRC-3, MRC-2, and MRC-1 directions. MRC-6 also detects Link Up, generates an MRP_Linkup message (denoted as message B), and sends it to the MRM's P2 port along the MRC-7 to MRC-15 directions.

[0189] However, before the two Linkup messages reach the MRM, the link between MRC-5 and MRC-6 is broken again due to poor contact. MRC-5 detects that the port status has changed to Link Down again, generates an MRP_Linkdown message (denoted as message C), and sends it in the P1 direction. MRC-6 also detects Link Down again, generates an MRP_Linkdown message (denoted as message D), and sends it in the P2 direction.

[0190] Assuming that due to differences in hop counts and network congestion levels in the two transmission paths, the actual message timing received by the MRM is as follows: At time t0, the MRM receives an MRP_Linkdown message (message D) from the MRC-6 via the P2 port. At time t1, the MRM receives an MRP_Linkup message (message A) from the MRC-5 via the P1 port, which falls within the time window. At time t2, the MRM receives an MRP_Linkdown message (message C) from the MRC-5 via port P1. At time t3, the MRM receives an MRP_Linkup message (message B) from the MRC-6 via port P2. This message is a late message.

[0191] Correspondingly, the implementation process of the solution: In step 10, the MRM receives the first MRP link status message from the P2 port at time t0, namely the MRP_Linkdown message (message D), and immediately starts the time window T with this time as the starting point.

[0192] In step 20, at time T within the time window, the MRM receives an MRP_Linkup message (message A) from port P1. The first message received by port P2 indicates "link failure," while the first message received by port P1 within the time window indicates "link recovery." The link states indicated by the first MRP link status messages received by the two ports are different, and all three conditions are met simultaneously. The MRM determines that a timing conflict has occurred. Based on the timing conflict determination, the MRM performs role allocation: port P2, which receives the message first within the time window, is designated as the priority port, and port P1, which receives the message later, is designated as the second priority port. Accordingly, MRC-6, which receives its first MRP link status message via the priority port P2, is designated as the near-end MRC, and MRC-5, which receives its first MRP link status message via the second-priority port P1, is designated as the far-end MRC.

[0193] In step 30, the MRM processes each MRP link status message received by the priority port P2 sequentially (and manages the loop status accordingly), and does not process each MRP link status message received by the second priority port P1, until it is confirmed that the forwarding path from the priority port P2, through the near-end MRC-6 to the far-end MRC-5 is in a stable state.

[0194] As can be seen from the examples above, regardless of whether the first arriving MRP link-state message is MRP_Linkup (as in the previous example) or MRP_Linkdown (as in this example), this scheme uses the objective timing of "first come, first served" as the sole criterion for classification. The processing logic is completely symmetrical and does not rely on any pre-assumptions about the message type. The classification of port roles and MRC roles depends solely on the order in which the messages arrive, and is unrelated to the message content, ensuring the universality and repeatability of the scheme in all real-world network scenarios.

[0195] In addition, this application embodiment also provides a link state management device in an MRP ring network, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to perform the method described above.

[0196] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A method for managing link states in an MRP ring network, applied to MRM, characterized in that, The method includes: When the MRP ring network is currently in an open-loop state, in response to receiving the first MRP link status message from either of the two ring ports of the MRM, a time window is started with the time of receiving the first MRP link status message as the starting point. Within the time window, in response to receiving the first MRP link status message from the other of the two ring ports, and the link status indicated by the first MRP link status messages received by the two ring ports is different, the ring port that receives the first MRP link status message first is determined as the priority port, and the ring port that receives the first MRP link status message later is determined as the second priority port; the MRC that receives its first MRP link status message through the priority port is determined as the near-end MRC, and the MRC that receives its first MRP link status message through the second priority port is determined as the far-end MRC; Before determining that the forwarding path from the priority port, through the near-end MRC to the far-end MRC is in a stable state, each MRP link state message received from the priority port is processed sequentially to manage the loop state, and each MRP link state message received from the second priority port is not processed.

2. The method according to claim 1, characterized in that, Whether the forwarding path from the priority port, through the near-end MRC to the far-end MRC, is in a stable state is determined by the following methods: Within a preset first time period, it is detected whether the forwarding path has been restored to connectivity, the first time period being determined based on the duration of a single link jitter event; If the forwarding path regains connectivity, then the forwarding path is determined to be in a stable state. If the forwarding path has not been restored to connectivity by the end of the first duration, the forwarding path is determined to be in a stable state after waiting for a preset second duration. The second duration is determined based on the duration of continuous link oscillation and is longer than the first duration.

3. The method according to claim 2, characterized in that, The step of detecting whether the forwarding path has been restored to connectivity within a preset first time period includes: Start timing for the first duration and send a probe message from the priority port, the destination address of the probe message being the remote MRC; If, before the first duration expires, a response message is received from the remote MRC to the probe message with the destination address being the MRM, it is determined that the forwarding path has been restored to connectivity; otherwise, it is determined that the forwarding path has not been restored to connectivity.

4. The method according to claim 3, characterized in that: During the first duration of the timer, the probe message is sent at least twice; If at least two response messages corresponding to the probe messages are received, it is determined that the forwarding path has been restored; otherwise, it is determined that the forwarding path has not been restored.

5. The method according to claim 3, characterized in that, At least one of the probe message and the response message carries message type information to distinguish it from standard MRP protocol messages.

6. The method according to any one of claims 1 to 5, characterized in that, The duration of the time window T is determined based on the following information: The proportionality coefficient k is positively correlated with the total number of nodes N in the MRP ring network. The historical jitter mean Δt_avg is determined according to the difference between the receiving times of the MRP_Linkup message and the MRP_Linkdown message in each link jitter event in the historical link jitter events; The base delay T_base is determined based on the loopback transmission delay of the MRP ring network; Where, T, k, Δt_avg and T_base are all greater than 0, and N is an integer greater than or equal to 3.

7. The method according to claim 6, wherein: T = k × (Δt_avg + T_base).

8. The method according to claim 6, wherein: The loopback transmission delay is determined by the difference between the time when the MRM sends the MRP_Test message and the time when it receives the MRP_Test message in the closed-loop state of the MRP ring network.

9. The method according to claim 6, wherein: When N≤10, k is taken as 1; when 10 < N≤15, k is taken as 1.1; when N>15, k is taken as 1.

3.

10. A link state management device in an MRP ring network, comprising a memory and a processor, characterized in that, A computer program is stored in the memory, and the processor is set to run the computer program to execute the method according to any one of claims 1 to 9.

Images