Message processing method and device

Abstract

The embodiment of the invention provides a message processing method and device, and relates to the technical field of communication, and the method is applied to a first member device in an IRF system, and comprises the steps: obtaining a to-be-processed service message; a first RPR head is packaged for the service message to obtain a first RPR message, and a destination MAC address in the first RPR head points to other member devices except the first member device in the IRF system; and sending the first RPR message through the RPR interface on the first member equipment. According to the scheme, the message processing complexity of the IRF system can be reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, and in particular to a message processing method and device. BACKGROUND

[0002] Intelligent Resilient Framework (IRF) is a software virtualization technology. The core idea of IRF is to connect multiple devices together, and after necessary configuration, virtualize the multiple devices into one device (i.e. IRF system). Using IRF technology can collect hardware resources and software processing capabilities of multiple devices, and realize collaborative work, unified management and uninterrupted maintenance of multiple devices.

[0003] However, when the IRF system processes messages such as cross-frame forwarding and topology discovery, a self-developed IRF protocol needs to be used to implement, which is complex. SUMMARY

[0004] Embodiments of the present application aim to provide a message processing method and device to reduce the complexity of the IRF system in processing messages. The specific technical solutions are as follows:

[0005] In a first aspect, the embodiments of the present application provide a message processing method applied to a first member device in an IRF system, and the method comprises:

[0006] obtaining a service message to be processed;

[0007] encapsulating a first Resilient Packet Ring (RPR) header for the service message to obtain a first RPR message, wherein a destination Media Access Control (MAC) address in the first RPR header points to other member devices in the IRF system except the first member device;

[0008] sending the first RPR message through an RPR interface on the first member device.

[0009] In some embodiments, the service message is a first control message.

[0010] The step of obtaining the service message to be processed comprises:

[0011] generating a first control message to be processed;

[0012] The step of encapsulating the first RPR header for the service message to obtain the first RPR message comprises:

[0013] determining that the destination MAC address corresponding to the first control message is a broadcast MAC address; encapsulating a first RPR header with the destination MAC address being the broadcast MAC address for the first control message to obtain a first RPR message; or

[0014] determining that the destination MAC address corresponding to the first control message is a unicast MAC address of a second member device in the IRF system; encapsulating a first RPR header with the destination MAC address being the unicast MAC address of the second member device for the first control message to obtain a first RPR message.

[0015] In some embodiments, the method further comprises:

[0016] receiving a second RPR message through the RPR interface, the second RPR message carrying a second RPR header and a second control message;

[0017] if the destination MAC address in the second RPR header is a broadcast MAC address, sending the second RPR message through the RPR interface and stripping the second RPR header included in the second RPR message to obtain the second control message;

[0018] processing the second control message.

[0019] In some embodiments, the method further comprises:

[0020] receiving a second RPR message through the RPR interface, the second RPR message carrying a second RPR header and a second control message;

[0021] if the destination MAC address in the second RPR header is a first unicast MAC address, the first unicast MAC address being a unicast MAC address of the first member device, stripping the second RPR header included in the second RPR message to obtain the second control message and processing the second control message;

[0022] if the destination MAC address in the second RPR header is a first unicast MAC address, the first unicast MAC address not being a unicast MAC address of the first member device, sending the second RPR message through the RPR interface.

[0023] In some embodiments, the service message is a first data message, and the first data message is a multicast message.

[0024] The step of obtaining the service message to be processed comprises:

[0025] receiving a first data message sent by a device outside the IRF system;

[0026] The step of encapsulating a first RPR header for the service packet to obtain a first RPR packet comprises:

[0027] According to the packet characteristic of the first data packet, a first multicast group corresponding to the first data packet is determined;

[0028] If the first multicast group includes the RPR interface, a first custom header is encapsulated for the first data packet to obtain a first custom packet, and the first custom header includes an identifier of the first multicast group;

[0029] A first RPR header is encapsulated for the first custom packet to obtain a first RPR packet, and a destination MAC address in the first RPR header is a broadcast MAC address or a first multicast MAC address corresponding to the first multicast group.

[0030] In some embodiments, the method further comprises:

[0031] The third RPR packet is received through the RPR interface, and the third RPR packet includes a third RPR header, a second custom header and a second data packet;

[0032] If the destination MAC address in the third RPR header is the broadcast MAC address, the third RPR packet is sent through the RPR interface, and the third RPR header and the second custom header included in the third RPR packet are stripped to obtain the second data packet;

[0033] A second multicast group corresponding to a multicast group identifier in the second custom header is determined;

[0034] If the second multicast group includes a first multicast interface on the first member device, the second data packet is forwarded through the first multicast interface;

[0035] If the second multicast group does not include the first multicast interface on the first member device, the second data packet is discarded.

[0036] In some embodiments, the method further comprises:

[0037] The third RPR packet is received through the RPR interface, and the third RPR packet includes a third RPR header, a second custom header and a second data packet;

[0038] If the destination MAC address in the third RPR header is a second multicast MAC address, and the second multicast MAC address is a multicast MAC address of the first member device, the third RPR packet is sent through the RPR interface, and the third RPR header and the second custom header of the third RPR packet are stripped to obtain a second data packet; it is determined that the multicast group identifier in the second custom header corresponds to a second multicast group; the second data packet is forwarded through a second multicast interface on the first member device in the second multicast group;

[0039] If the destination MAC address in the third RPR header is a second multicast MAC address, and the second multicast MAC address is not a multicast MAC address of the first member device, the third RPR packet is sent through the RPR interface.

[0040] In some embodiments, the method further comprises:

[0041] According to the packet characteristics of the first data packet, a multicast forwarding table is queried to obtain a target multicast table item identifier, the multicast forwarding table stores a correspondence relationship between packet characteristics and multicast table item identifiers, each bit in the multicast table item identifier corresponds to a member device in the IRF system, and when a bit is a preset value, it indicates that the multicast interface on the corresponding member device belongs to a member interface in the corresponding multicast group.

[0042] When the bit corresponding to the other member device in the target multicast table item identifier is the preset value, the first multicast MAC address corresponding to the target multicast table item identifier is searched from a preset multicast MAC table.

[0043] In some embodiments, the method further comprises:

[0044] If the first multicast group includes a third multicast interface on the first member device, the first data packet is forwarded through the third multicast interface.

[0045] In some embodiments, the service packet is a third data packet, and the third data packet is a unicast packet.

[0046] The step of obtaining the service packet to be processed comprises:

[0047] Receiving a third data packet sent by a device outside the IRF system;

[0048] The step of encapsulating the first RPR header for the service packet to obtain the first RPR packet comprises:

[0049] According to the packet characteristics of the third data packet, a first unicast interface corresponding to the third data packet is determined.

[0050] if the first unicast interface is a unicast interface on a second member device in the IRF system, encapsulating a third custom header into the third data packet to obtain a second custom packet, the third custom header comprising an identifier of the first unicast interface;

[0051] encapsulating a first RPR header into the second custom packet to obtain a first RPR packet, a destination MAC address in the first RPR header being a unicast MAC address of the second member device.

[0052] In some embodiments, the method further comprises:

[0053] receiving, through the RPR interface, a fourth RPR packet comprising a fourth RPR header, a fourth custom header and a fourth data packet;

[0054] if a destination MAC address in the fourth RPR header is a second unicast MAC address, the second unicast MAC address being a unicast MAC address of the first member device, stripping the fourth RPR header and the fourth custom header comprised in the fourth RPR packet to obtain the fourth data packet; determining a second unicast interface pointed by a unicast interface identifier in the fourth custom header; and forwarding the fourth data packet through the second unicast interface;

[0055] if the destination MAC address in the fourth RPR header is the second unicast MAC address, the second unicast MAC address not being the unicast MAC address of the first member device, sending the fourth RPR packet through the RPR interface.

[0056] In some embodiments, a specified protocol number and a packet level are carried in the RPR header of each RPR packet, the specified protocol number indicating a control packet or a data packet.

[0057] In some embodiments, the method further comprises:

[0058] receiving, through the RPR interface, a topology packet sent by another member device in the IRF system, the topology packet comprising a master device field and a local device field, the master device field being used to carry a chassis number of a master device, and the local device field being used to carry a chassis number of a source member device corresponding to the topology packet;

[0059] if a preset number of topology packets with empty master device fields are continuously received, and chassis numbers carried in the preset number of topology packets are greater than a chassis number of the first member device, determining that the first member device is a temporary master device;

[0060] When the first member device is a temporary master device, if a plurality of topology packets with non-empty master device field and a chassis number carried in the master device field is greater than a chassis number of the first member device are received, or a plurality of topology packets with empty master device field are received, the first member device is determined as a master device in the IRF system.

[0061] In some embodiments, the method further comprises:

[0062] When the first member device is a temporary master device, if at least one topology packet with non-empty master device field and a chassis number carried in the master device field is less than a chassis number of the first member device is received, the first member device is determined as a slave device in the IRF system.

[0063] In some embodiments, the method further comprises:

[0064] If a preset number of topology packets with a chassis number of a third member device in the master device field are continuously received, the third member device is determined as a master device in the IRF system.

[0065] In some embodiments, the reserved field of the topology packet comprises a first subfield and a second subfield, the first subfield is a local device field, and the second subfield is a master device field.

[0066] In a second aspect, the embodiments of the present application provide a packet processing apparatus applied to a first member device in an IRF system, the apparatus comprising:

[0067] an obtaining module, configured to obtain a service packet to be processed;

[0068] an encapsulating module, configured to encapsulate a first RPR header for the service packet to obtain a first RPR packet, a destination MAC address in the first RPR header pointing to other member devices in the IRF system except the first member device;

[0069] a sending module, configured to send the first RPR packet through an RPR interface on the first member device.

[0070] In a third aspect, the embodiments of the present application provide an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus;

[0071] the memory, configured to store a computer program;

[0072] the processor, configured to execute the program stored in the memory, to implement any packet processing method provided in the first aspect.

[0073] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program, when executed by a processor, implements any of the packet processing methods provided in the first aspect.

[0074] The embodiment of the present application further provides a computer program product containing instructions, which, when executed on a computer, cause the computer to execute any of the packet processing methods provided in the first aspect.

[0075] The embodiment of the present application has the following beneficial effects:

[0076] In the technical scheme provided by the embodiment of the present application, the member device in the IRF system encapsulates an RPR header for a service packet when processing the service packet, and obtains an RPR packet; and then the member device in the IRF system can use an RPR interface to implement the forwarding of the RPR packet (i.e. the service packet) between the member devices in the IRF system. In the embodiment of the present application, the member device in the IRF system does not need to use a self-developed IRF protocol when processing the service packet, but can use an RPR protocol, thereby reducing the complexity of the IRF system in processing the packet.

[0077] Of course, implementing any of the products or methods of the present application does not necessarily need to achieve all the advantages described above. BRIEF DESCRIPTION OF DRAWINGS

[0078] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and other embodiments can also be obtained by those skilled in the art based on these drawings.

[0079] Figure 1 It is a schematic diagram of an RPR ring;

[0080] Figure 2 It is a schematic diagram of forwarding a packet in an RPR ring;

[0081] Figure 3a It is a schematic diagram of a chain-shaped connection topology of an IRF system;

[0082] Figure 3b It is a schematic diagram of a ring-shaped connection topology of an IRF system;

[0083] Figure 4 It is a flowchart of a packet processing method provided by the embodiment of the present application;

[0084] Figure 5 It is a schematic diagram of an RPR packet provided by the embodiment of the present application;

[0085] Figure 6 A first diagram of a first RPR message provided by an embodiment of the present application;

[0086] Figure 7 A second diagram of the first RPR message provided by the embodiment of the present application;

[0087] Figure 8 A diagram of a multicast MAC table item ID provided by the embodiment of the present application;

[0088] Figure 9a A diagram of a topology message of the RPR protocol;

[0089] Figure 9b A diagram of a topology message modification provided by the embodiment of the present application;

[0090] Figure 10 A diagram of a master device election process provided by the embodiment of the present application;

[0091] Figure 11 A diagram of a structure of a message processing device provided by the embodiment of the present application;

[0092] Figure 12 A diagram of a structure of a network device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0093] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art based on the present application belong to the scope of protection of the present application.

[0094] For the convenience of understanding, the words appearing in the embodiments of the present application will be explained below.

[0095] Resilient Packet Ring (RPR): a Media Access Control (MAC) layer protocol designed for efficient data transmission on a ring topology. The RPR ring is a bi-directional ring topology, both rings can transmit messages, and the two rings are respectively called inner ring and outer ring, the outer ring can be called Ring 0, and the inner ring can be called Ring 1. Each node on the RPR has a separate MAC address, and each node operates according to the source MAC address and the destination MAC address of the message. For example, Figure 1The shown RPR ring includes nodes A-F, which are connected two by two to form the RPR ring. For a RPR node (i.e. a node on the RPR), the node includes a RPR interface, which includes two physical RPR ports, one connected to the 0 ring and the other connected to the 1 ring.

[0096] The operation of a packet on a RPR node is as follows:

[0097] 1) Insert: the RPR node inserts a packet forwarded from other interfaces into the data stream of the RPR ring;

[0098] 2) Copy: the RPR node receives a packet from the data stream of the RPR ring and hands it to the upper layer (e.g. GPU) for processing;

[0099] 3) Transit: a packet passing through the RPR node is forwarded to the next RPR node;

[0100] 4) Strip: a packet passing through the RPR node is not forwarded to the next RPR node.

[0101] Still taking the example of Figure 1 , node A introduces a data stream from outside the RPR ring into the RPR ring (referred to as insert), and the data stream is sent to node C. Node C forwards the data stream to outside the RPR ring (referred to as copy). In the process of the data stream from node A to node C, it must pass through node B, but node B finds that the destination MAC address is not the MAC address of the node, and the RPR MAC layer chip directly transmits to node C (referred to as transit), and node B does not need to perform packet forwarding processing.

[0102] The data stream of the RPR ring is divided into three levels: Class A, Class B and Class C. Different levels correspond to different queues and scheduling strategies, as follows:

[0103] 1) Class A (strict priority). Class A can be divided into:

[0104] Subclass A0: low delay, fixed bandwidth (such as TDM circuit simulation).

[0105] Subclass A1: low delay, recoverable bandwidth (such as real-time video).

[0106] 2) Class B (committed bandwidth + excess burst). Class B can be divided into:

[0107] Subclass B- committed information rate (CIR): bandwidth guarantee.

[0108] Subclass B - Excess Information Rate (EIR): Allows bursts and may be discarded.

[0109] 3) Level C (Best-effort). Under Level C, there are no guarantees; transmission occurs only when bandwidth is available (e.g., normal data streams).

[0110] The RPR ring uses a shared bandwidth approach to enable each RPR node to utilize bandwidth resources. When data traffic is low, the RPR ring can meet the traffic upload needs of all nodes. However, when data traffic is high, link overload and traffic congestion often occur. To ensure that each node can fairly enjoy bandwidth under congestion or overload conditions, the RPR ring provides a dedicated fairness algorithm to achieve fair bandwidth sharing and scheduling.

[0111] Bandwidth fairness and congestion control mechanisms are functions of the MAC control sublayer within the RPR data link layer. The RPR fairness algorithm is applicable to services that require bandwidth contention, namely EIR services and best-effort services.

[0112] The fairness algorithm implemented within the fairness control unit in the MAC control sublayer has the following functions:

[0113] 1) Detecting and eliminating congestion;

[0114] 2) Sending and receiving fair control messages between RPR nodes;

[0115] 3) Based on different service levels, access control is provided for the ring bandwidth of the RPR ring, and an equal or weighted fair algorithm is used to control the use of the total ring bandwidth.

[0116] 4) Ring 0 and Ring 1 provide independent bandwidth fairness operations, allocating all bandwidth between any two nodes on the RPR ring as global resources to users;

[0117] 5) Each node can control the speed at which it forwards data packets to the ring based on the message level and the ring bandwidth usage, ensuring that each node receives a fair allocation of ring bandwidth.

[0118] 6) For the same loop, the bandwidth fairness control frame and the associated data stream flow on different sub-loops, and the flow direction is opposite.

[0119] The following is combined Figure 1 The RPR ring shown illustrates the fair algorithm processing procedure. The RPR ring has a loop bandwidth of 2.5 Gbps, and the data stream is transmitted through ring 0.

[0120] When node B and node C send 1Gbps data stream to node D respectively, as shown in Fig. 1, two data streams share bandwidth in node C→node D segment, and the bandwidth consumed by node C→node D segment link is 2Gbps, without congestion. Figure 2 As shown in Fig. 2, node A also sends 1Gbps data stream to node D, at this time, three data streams share bandwidth in node C→node D segment, and the bandwidth consumed by node C→node D segment link reaches 3Gbps, exceeding the limit value 2.5Gbps of the ring bandwidth, and congestion occurs in node C→node D segment.

[0121] As shown in Fig. 2, node A also sends 1Gbps data stream to node D, at this time, three data streams share bandwidth in node C→node D segment, and the bandwidth consumed by node C→node D segment link reaches 3Gbps, exceeding the limit value 2.5Gbps of the ring bandwidth, and congestion occurs in node C→node D segment. Figure 2 According to the fair algorithm, node C locally calculates, immediately reduces the local upload traffic to 500Mbps, and sends a control packet to node B through the ring 1 to transfer the congestion and fair algorithm information.

[0122] After receiving the control packet, node B reduces the local upload traffic, and according to the fair algorithm calculation, the upload traffic of node C and node B is adjusted to 750Mbps. Meanwhile, node B continues to send a control packet to node A through the ring 1 to transfer the congestion and fair algorithm information.

[0123] After receiving the control packet, node A reduces the local upload traffic. According to the fair algorithm calculation, the upload traffic of node A, node B and node is adjusted to 833Mbps, and node A, node B and node fairly enjoy the bandwidth.

[0124] The RPR protocol can automatically discover the topology. The topology information is contained in the protection packet or the topology packet, and the protection packet or the topology packet is broadcasted on the RPR ring. The topology structure indicated by the topology information includes a full ring structure (such as the RPR ring shown in Fig. 3) and a chain structure (such as the link fault of node A→node F segment in Fig. 4). The automatic discovery of the topology is helpful for protection in the case of link fault, and also provides good support for network expansion, and can support node-level plug-and-play, that is, when a node is added or deleted on the RPR ring, no manual data configuration is needed.

[0125] Figure 1 The RPR protocol has good management and maintenance functions, and a large number of option parameters for performance management, fault management and configuration management are contained in the packet structure of the RPR protocol, which lays a good foundation for the operation, maintenance and management (OAM) of the RPR ring. The RPR ring implements fault monitoring, positioning and isolation of the RPR protocol layer through special control packets. Figure 1 The RPR protocol has good management and maintenance functions, and a large number of option parameters for performance management, fault management and configuration management are contained in the packet structure of the RPR protocol, which lays a good foundation for the operation, maintenance and management (OAM) of the RPR ring. The RPR ring implements fault monitoring, positioning and isolation of the RPR protocol layer through special control packets.

[0126] The RPR protocol has good management and maintenance functions, and a large number of option parameters for performance management, fault management and configuration management are contained in the packet structure of the RPR protocol, which lays a good foundation for the operation, maintenance and management (OAM) of the RPR ring. The RPR ring implements fault monitoring, positioning and isolation of the RPR protocol layer through special control packets.

[0127] ​In summary, the RPR ring has the following advantages:

[0128] 1) Over the ring processing, no occupation of forwarding resources, small delay.

[0129] For example, the data flow from node A to node C passes through node B, but node B finds that the destination MAC address is not the MAC address of the node, and directly transmits to node C, and node B does not need to perform packet forwarding processing.

[0130] 2) Packet classification, such as the above level A, level B and level C, different scheduling strategies are performed for different packet levels.

[0131] 3) Fair algorithm, fair sharing and scheduling bandwidth.

[0132] 4) Automatic discovery of topology.

[0133] 5) Good management and maintenance functions.

[0134] Intelligent Resilient Framework (IRF) is a software virtualization technology. The core idea of IRF is to connect multiple devices together, and after necessary configuration, virtualize the multiple devices into one device (i.e. IRF system). Using IRF technology can collect hardware resources and software processing capacity of multiple devices, realize cooperative work, unified management and uninterrupted maintenance of multiple devices. Among them, the device virtualized by using IRF technology can be called IRF system, and the multiple devices included in the IRF system can be called member devices included in the IRF system, which are divided into master device and slave device according to the role. The master device is responsible for the operation, management and maintenance of the IRF system, and the slave device is responsible for processing business and backing up data.

[0135] The topology structure of the IRF system has two kinds: chain connection and ring connection.

[0136] 1) Chain connection, as shown in Figure 3a The chain connection has lower requirements for the physical location of the member device than the ring connection, and the chain connection is mainly used for networking of the member devices with dispersed physical locations.

[0137] 2) Ring connection, as shown in Figure 3b The ring connection is more reliable than the chain connection. Because when a link fault occurs in the chain connection, the IRF system is split; and when a link fault occurs in the ring connection, a chain connection is formed, and the business of the IRF system is not affected.

[0138] The topology structure of the IRF system is a stack topology structure, and the stack topology structure is a subset of the RPR topology structure. Each member device in the stack topology has two stack ports, as shown inFigure 3a and Figure 3b IRF port 1 and IRF port 2 in the IRF system; the stacking port can be aggregated by multiple physical ports, and the stacking port is more flexible. The RPR port is a special physical port.

[0139] The IRF system has the following advantages:

[0140] 1) Simplified management: after the IRF system is formed, the user can log in to the IRF system through any port of any member device, and manage all member devices in the IRF system uniformly.

[0141] 2) 1:N backup: the IRF system is composed of multiple member devices, wherein the master device is responsible for the operation, management and maintenance of the IRF system, and the slave device is responsible for processing business and backing up data. Once the master device fails, the IRF system will quickly and automatically elect a new master device to ensure that the business does not interrupt, thereby realizing 1:N backup of the device.

[0142] 3) Link aggregation across member devices: the physical link between the IRF system and the upper layer device and the lower layer device supports aggregation function, and the physical link on different member devices can be aggregated into a logical link, and multiple physical links can back up each other or share the load; when a member device leaves the IRF system, the link on other member devices can still transmit and receive packets, thereby improving the reliability of the logical link.

[0143] 4) Strong network expansion capability: by increasing the member devices, the port number and bandwidth of the IRF system can be easily and freely expanded; in addition, each member device has a central processing unit (CPU) and can independently process protocol packets and data packets, so the IRF system can also easily and freely expand the processing capability.

[0144] The IRF system has the above-mentioned multiple advantages. However, when implementing cross-frame forwarding (i.e. cross-member device forwarding) and topology discovery and other packet processing, the IRF system needs to use self-developed protocols to implement, which is complex.

[0145] To solve the above problems, an embodiment of the present application provides a packet processing method, as shown in Figure 4 The method is applied to a first member device in an IRF system, and the method comprises the following steps:

[0146] Step S401, obtaining a to-be-processed service packet;

[0147] Step S402, encapsulating a first RPR header for the service packet to obtain a first RPR packet, wherein the destination MAC address in the first RPR header points to other member devices in the IRF system except the first member device.

[0148] Step S403, sending the first RPR packet through the RPR interface on the first member device.

[0149] In the technical scheme provided by the embodiments of the present application, the member device in the IRF system encapsulates an RPR header for a service packet when processing the service packet, to obtain an RPR packet; and then the member device in the IRF system can use the RPR interface to implement the forwarding of the RPR packet (i.e. the service packet) between the member devices in the IRF system. In the embodiments of the present application, the member device in the IRF system does not need to use the self-developed IRF protocol when processing the service packet, but can use the RPR protocol, thereby reducing the complexity of the IRF system in processing the packet.

[0150] In addition, the technical scheme provided by the embodiments of the present application combines the IRF and the RPR, so that the technical scheme provided by the embodiments of the present application takes into account the advantages of both the IRF and the RPR. The advantages of the IRF and the RPR can be referred to the above description, and will not be described here again.

[0151] In the embodiments of the present application, the IRF system includes a plurality of member devices, and the first member device is any one of the plurality of member devices. The first member device can be a master device included in the IRF system, or a slave device included in the IRF system.

[0152] In the above step S401, the service packet can be a control packet, or the service packet can be a data packet.

[0153] The control packet can be internal system information such as device operation, log, interaction information, etc. in the IRF system, and will not be forwarded outside the system. The control packet can also be a protocol packet for cross-frame transmission, such as ospf, isis, bgp, bfd, etc. For example, the master device (Master) generates an ospf protocol packet, and sends it to the member device where the out interface is located, which is a control packet; the CPU of the member device where the out interface is located processes the ospf protocol packet, and then sends it out from the out interface, which is no longer a control packet.

[0154] When the service packet is a control packet (such as a first control packet), the above step S401 can be: generating a first control packet to be processed.

[0155] When the service packet is a data packet (such as a first data packet or a third data packet), the above step S401 can be: receiving a first data packet or a third data packet sent by a device outside the IRF system. The first data packet is a multicast packet, and the third data packet is a unicast packet.

[0156] In step S402, the RPR packet is a packet forwarded on the RPR ring. The structure of the RPR packet can be found in the following table: Figure 5 As shown in the table, the RPR packet includes an RPR header, a service data unit field, a frame check sequence (FCS) field, and the like. The RPR header can include a time to live (TTL) field, a base control (BaseCtrl) field, a destination MAC address (DA) field, a source MAC address (SA) field, a TTL base (TTLBase) field, an extended control (ExtendedCtrl) field, a header error check (HEC) field, a protocol type (Protocol Type) field, and the like. The RPR packet can further include the service data unit field and the FCS field.

[0157] After obtaining the service packet, the first member device can determine the destination device corresponding to the service packet, such as any member device except the first member device in the IRF system, or all member devices except the first member device in the IRF system, and the like. The first member device encapsulates the MAC address of the destination device corresponding to the service packet in the DA field of the RPR header, encapsulates the MAC address of the first member device in the SA field of the RPR header, and adjusts other fields in the RPR header according to actual requirements to obtain the first RPR header.

[0158] In some embodiments, in order to facilitate subsequent differentiation between the control packet and the data packet, the IRF system preconfigures the protocol number and the packet level of the control packet and the data packet. For example, the protocol number of the control packet is abcd, and the protocol number of the data packet is 0800. The packet level of the control packet is level A, such as A0. The packet level of the data packet is C, or the packet level of each data packet is determined according to the differentiated services code point (DSCP) of the data packet and the preset correspondence between the DSCP and the packet level. For example, the preset correspondence between the DSCP and the packet level includes the correspondence between expedited forwarding (EF) and level B-CIR, the correspondence between assured forwarding (AF) and level B-EIR, and the correspondence between best effort (BE) and level C.

[0159] The first member device can encapsulate the designated protocol number corresponding to the service message in the protocol type field in the RPR header, and encapsulate the message level corresponding to the service message in the Extended Ctrl field or the designated message level field in the RPR header. Through the protocol number and the message level carried by the RPR header, the RPR interface on each member device in the IRF system can implement corresponding correct processing on the message. The designated protocol number described above can only be meaningful within the IRF system and will not be transferred out.

[0160] In step S403 described above, the first member device puts the first RPR message on the RPR interface, and the RPR interface includes two RPR ports, one RPR port of a 0 ring and one RPR port of a 1 ring. The RPR interface selects the ring number (Ring Identifier, RI) according to the RRL, and then transmits the first RPR message on the ring corresponding to the RI (such as the 0 ring or the 1 ring).

[0161] The processing of the control message and the data message will be described below respectively.

[0162] (1) Control message.

[0163] In the embodiment of the application, when the service message is a control message, such as the first control message, the first member device serves as an uplink device (an entry device), the first member device generates the first control message to be processed, and then performs step S402 described above to encapsulate the first RPR header for the service message, and obtains the first RPR message.

[0164] The first member device can perform step S402 according to the forwarding method of the first control message.

[0165] 1) The forwarding method of the first control message is broadcast.

[0166] In this case, step S402 described above can be: determining that the destination MAC address corresponding to the first control message is a broadcast MAC address; and encapsulating the first RPR header with the destination MAC address being the broadcast MAC address for the first control message, and obtaining the first RPR message.

[0167] For example, the broadcast MAC address is FFFF-FFFF-FFFF. The first member device encapsulates FFFF-FFFF-FFFF as the destination MAC address in the DA field of the RPR header, and encapsulates the MAC address of the first member device in the SA field of the RPR header, obtains the first RPR header, and then encapsulates the first RPR header for the first control message, and obtains the first RPR message. At this time, the structure of the first RPR message is as shown in FIG. 4. Figure 6

[0168] ​The first member device broadcasts the first RPR packet through the RPR interface. All member devices in the IRF system can learn that the source member device (i.e. the source box) of the first RPR packet is the first member device according to the SA field in the first RPR header, and that the first RPR packet is a broadcast packet according to the DA field in the first RPR header, and then continue to broadcast the first RPR packet on the RPR interface.

[0169] When the first member device broadcasts the first RPR packet through the RPR interface, other member devices in the IRF system can also broadcast the second RPR packet through the RPR interface. The second RPR packet carries a second RPR header and a second control packet.

[0170] In this case, the message processing method can further include: receiving the second RPR packet through the RPR interface, the second RPR packet carrying a second RPR header and a second control packet; if the destination MAC address in the second RPR header is a broadcast MAC address, sending the second RPR packet through the RPR interface and stripping the second RPR header included in the second RPR packet to obtain the second control packet; and processing the second control packet.

[0171] In the embodiment, after the first member device receives the second RPR packet through the RPR interface, it can recognize from the second RPR header that the protocol number indicates that the second RPR packet carries a control packet and the destination MAC address is a broadcast MAC address; and then the first member device can perform the following two operations in parallel:

[0172] Operation 1: Continue to send the second RPR packet through the RPR interface.

[0173] Operation 2: Strip the second RPR header included in the second RPR packet to obtain the second control packet; and process the second control packet by a control packet processor (such as a CPU or a switching board, etc.). Here, after the first member device processes the second control packet by the control packet processor (such as a CPU or a switching board, etc.), it no longer encapsulates an RPR header for the second control packet and forwards the encapsulated RPR packet through the RPR interface.

[0174] The processing of the broadcast first RPR packet by other member devices (such as the second member device) in the IRF system is the same as the processing of the broadcast second RPR packet by the first member device described above, and will not be repeated here.

[0175] 2) The forwarding method of the first control packet is unicast.

[0176] In this case, step S402 above can be: determining that the destination MAC address corresponding to the first control message is the unicast MAC address of the second member device in the IRF system; encapsulating the first control message with the destination MAC address being the unicast MAC address of the second member device to obtain the first RPR message.

[0177] For example, the first member device can obtain the destination MAC address, which is the unicast MAC address of the second member device, based on the destination frame number. The unicast MAC address of the second member device is 1111-2222-3333. The first member device encapsulates 1111-2222-3333 as the destination MAC address in the DA field of the RPR header, and encapsulates its own MAC address in the SA field of the RPR header, thus obtaining the first RPR header. This first RPR header is then used to encapsulate the first control message, resulting in the first RPR message. At this point, the structure of the first RPR message is as follows: Figure 6 As shown.

[0178] The first member device unicasts the first RPR message through the RPR interface. All member devices in the IRF system can determine that the source member device (i.e., the source frame) of the first RPR message is the first member device based on the SA field in the first RPR header, and can determine that the first RPR message is a unicast message based on the DA field in the first RPR header. They can then determine how to process the first RPR message based on the value of the DA field.

[0179] When the first member device unicasts the first RPR message through the RPR interface, other member devices in the IRF system can also unicast the second RPR message through the RPR interface. The second RPR message carries a second RPR header and a second control message.

[0180] In this case, the above message processing method may further include: receiving a second RPR message through the RPR interface, the second RPR message carrying a second RPR header and a second control message; if the destination MAC address in the second RPR header is a first unicast MAC address, and the first unicast MAC address is the unicast MAC address of the first member device, then stripping the second RPR header included in the second RPR message to obtain a second control message; processing the second control message; if the destination MAC address in the second RPR header is the first unicast MAC address, and the first unicast MAC address is not the unicast MAC address of the first member device, then sending the second RPR message through the RPR interface.

[0181] In this embodiment, after the first member device receives the second RPR message through the RPR interface, it can identify on the RPR interface that the protocol number in the second RPR header indicates that the second RPR message carries a control message, and that the destination MAC address is a unicast MAC address (i.e., the first unicast MAC address). The first member device is configured with a MAC address table for the RPR interface, which records the unicast MAC address and multicast MAC address of the first member device, etc.

[0182] The first member device can query the MAC address table of the RPR interface to determine whether the first unicast MAC address is the unicast MAC address of the first member device, and then perform different processing on the second RPR message based on the determination result.

[0183] A. The determined result is: the first unicast MAC address is the unicast MAC address of the first member device.

[0184] In this scenario, the first member device removes the second RPR header from the second RPR message to obtain the second control message; the second control message is then processed by a control message processor (such as a CPU or switch board). Here, the first member device no longer forwards the second RPR message through the RPR interface.

[0185] B, the determined result is: the first unicast MAC address is not the unicast MAC address of the first member device.

[0186] In this case, the first member device continues to send the second RPR message through the RPR interface.

[0187] The processing of the first RPR message by other member devices (such as the second member device) in the IRF system is the same as the processing of the second RPR message by the first member device, and will not be repeated here.

[0188] (2) Data message.

[0189] In this embodiment of the application, when the service message is a data message, such as a first data message or a third data message, the first data message is a multicast message and the third data message is a unicast message. The first member device acts as an uplink device (entry device). The first member device receives the first data message or the third data message sent by the device outside the IRF system, and then performs the above step S402 to encapsulate the first RPR header for the service message to obtain the first RPR message.

[0190] The first member device can execute step S402 according to the data packet forwarding method.

[0191] 1) The forwarding method of the data packet is broadcast or multicast. That is, the service packet is the first data packet, the first data packet is a multicast packet, and the first data packet is sent using the broadcast or multicast method.

[0192] In this case, step S402 can be as follows: determine the first multicast group corresponding to the first data packet based on the packet characteristics of the first data packet; if the first multicast group includes an RPR interface, encapsulate the first data packet with a first custom header to obtain a first custom packet, wherein the first custom header includes the identifier of the first multicast group; encapsulate the first custom packet with a first RPR header to obtain a first RPR packet, wherein the destination MAC address in the first RPR header is either a broadcast MAC address or the first multicast MAC address corresponding to the first multicast group.

[0193] In this embodiment of the application, each member device in the IRF system is configured with one or more multicast groups. For each multicast group, if the multicast group includes a local multicast interface of the member device, the local multicast interface is added to the multicast group. If the multicast group includes multicast interfaces on other member devices, the RPR interface is added to the multicast group.

[0194] For example, a multicast group includes interface A on member device A and interface B on member device B. For member device A, the stored multicast group is {interface A, RPR interface}; for member device B, the stored multicast group is {interface B, RPR interface}.

[0195] Each member device in the IRF system is also configured with a multicast forwarding table, which includes message characteristics and multicast group identifiers. Message characteristics can be a 5-tuple or a destination IP address, etc.

[0196] Custom headers include destination information, such as destination port and destination multicast group identifier, and may also include source information, such as source chip and source port.

[0197] After receiving the first data packet, the first member device extracts the packet characteristics and then queries the multicast forwarding table to determine the multicast group identifier corresponding to the first data packet, i.e., the identifier of the first multicast group. If the first multicast group includes a local multicast interface of the first member device (such as a third multicast interface), the first data packet is forwarded directly to devices outside the IRF system through the third multicast interface; if the first multicast group includes an RPR interface on the first member device, a first custom header including the identifier of the first multicast group (i.e., the destination multicast group identifier) ​​is generated, and the first data packet is encapsulated with the first custom header. The resulting packet is the first custom packet.

[0198] If the first data packet is broadcast, a first RPR header with the destination MAC address being the broadcast MAC address is generated. This first RPR header is then encapsulated in the first custom message, resulting in the first RPR message. If the first data packet is multicast, a first RPR header with the destination MAC address being the first multicast MAC address corresponding to the first multicast group is generated. This first RPR header is then encapsulated in the first custom message, resulting in the first RPR message. In this case, the structure of the first RPR message is as follows: Figure 7 As shown.

[0199] When the first member device broadcasts or multicasts the first RPR message through the RPR interface, other member devices in the IRF system can also broadcast or multicast the third RPR message through the RPR interface. The third RPR message carries a third RPR header, a second custom header, and a second data packet. The broadcast and multicast methods are explained below.

[0200] A. The first member device broadcasts the first RPR message through the RPR interface; other member devices in the IRF system broadcast the third RPR message through the RPR interface.

[0201] In this case, the above message processing method may further include: receiving a third RPR message through the RPR interface, the third RPR message including a third RPR header, a second custom header, and a second data message; if the destination MAC address in the third RPR header is a broadcast MAC address, then sending the third RPR message through the RPR interface, and stripping the third RPR header and the second custom header included in the third RPR message to obtain the second data message; determining the second multicast group corresponding to the multicast group identifier in the second custom header; if the second multicast group includes the first multicast interface on the first member device, then forwarding the second data message through the first multicast interface; if the second multicast group does not include the first multicast interface on the first member device, then discarding the second data message.

[0202] In this embodiment, after the first member device receives the third RPR message through the RPR interface, it can identify on the RPR interface that the protocol number in the third RPR header indicates that the third RPR message carries a data packet, and that the destination MAC address is a broadcast MAC address. Therefore, the first member device can perform the following two operations in parallel:

[0203] Operation 1: Continue sending the third RPR message through the RPR interface.

[0204] Operation 2: Remove the third RPR header and the second custom header from the third RPR message to obtain the second data message.

[0205] In operation 2, the first member device obtains the multicast group identifier from the second custom header and determines the multicast group corresponding to the multicast group identifier, i.e., the second multicast group. If the second multicast group includes a multicast interface on the first member device (such as the first multicast interface), the first member device forwards the second data packet through the first multicast interface. If the second multicast group does not include the first multicast interface on the first member device, the second data packet is discarded.

[0206] The first member device acts as a downlink device (egress device). After the data packet processor (such as a CPU or switching board) processes the second data packet, if the second multicast group is determined, it forwards the second data packet through the first multicast interface or discards the second data packet. It does not encapsulate the RPR header for the second data packet, and forwards the encapsulated RPR packet through the RPR interface.

[0207] B. The first member device multicasts the first RPR message through the RPR interface; other member devices in the IRF system multicast the third RPR message through the RPR interface.

[0208] In this case, the above message processing method may further include: receiving a third RPR message through the RPR interface, the third RPR message including a third RPR header, a second custom header, and a second data message; if the destination MAC address in the third RPR header is a second multicast MAC address, and the second multicast MAC address is the multicast MAC address of the first member device, then sending the third RPR message through the RPR interface, and stripping the third RPR header and the second custom header of the third RPR message to obtain the second data message; determining the second multicast group corresponding to the multicast group identifier in the second custom header; forwarding the second data message through the second multicast interface on the first member device in the second multicast group; if the destination MAC address in the third RPR header is a second multicast MAC address, and the second multicast MAC address is not the multicast MAC address of the first member device, then sending the third RPR message through the RPR interface.

[0209] In this embodiment, after the first member device receives the third RPR message through the RPR interface, it can identify on the RPR interface that the protocol number in the third RPR header indicates that the third RPR message carries a data packet, and that the destination MAC address is a multicast MAC address, such as the second multicast MAC address. The first member device is configured with a MAC address table for the RPR interface, which records the unicast MAC address and multicast MAC address of the first member device.

[0210] The first member device can query the MAC address table of the RPR interface to determine whether the second multicast MAC address is the multicast MAC address of the first member device, and then perform different processing on the third RPR message based on the determination result.

[0211] A. The determined result is: the second multicast MAC address is the multicast MAC address of the first member device.

[0212] In this case, the first member device can perform the following two operations in parallel:

[0213] Operation 1: Continue sending the third RPR message through the RPR interface;

[0214] Operation 2: Remove the third RPR header and the second custom header from the third RPR message to obtain the second data message.

[0215] In operation 2, the first member device obtains the multicast group identifier from the second custom header and determines the multicast group corresponding to this identifier, namely the second multicast group. Here, the second multicast MAC address is the multicast MAC address of the first member device; therefore, the second multicast group must exist on the first member device. After determining the second multicast group, the first member device directly forwards the second data packet through the multicast interface (such as the second multicast interface) on the first member device within the second multicast group.

[0216] Here, the first member device acts as a downlink device (egress device). After the data packet processor (such as a CPU or switching board) processes the second data packet, if the second multicast group is determined, the second data packet is forwarded through the first multicast interface. The second data packet is no longer encapsulated with an RPR header, and the RPR packet is obtained by forwarding and encapsulating through the RPR interface.

[0217] B, the result is: the second multicast MAC address is not the multicast MAC address of the first member device.

[0218] In this case, the first member device directly sends the third RPR message through the RPR interface without sending the third RPR message to the CPU or switching board, thus realizing RPR loopback processing and reducing the occupation of forwarding resources.

[0219] In this embodiment of the application, when the forwarding method of the data packet is multicast, the first member device can determine the first multicast MAC address corresponding to the first multicast group in the following way: query the multicast forwarding table according to the packet characteristics of the first data packet to obtain the target multicast entry identifier. The multicast forwarding table stores the correspondence between packet characteristics and multicast entry identifiers. Each bit in the multicast entry identifier corresponds to a member device in the IRF system. When a bit is a preset value, it indicates that the multicast interface on the corresponding member device belongs to the member interface in the corresponding multicast group. When the bit corresponding to other member devices in the target multicast entry identifier is a preset value, the first multicast MAC address corresponding to the target multicast entry identifier is searched from the preset multicast MAC table.

[0220] In this embodiment, the first member device is configured with a multicast forwarding table. The multicast forwarding table includes message characteristics and a multicast group identifier, and may also include multicast entry identifiers (such as multicast MAC entry IDs). The multicast MAC entry ID is a binary bit string. Each bit in the multicast MAC entry ID corresponds to a member device in the IRF system. When a bit is a preset value, it indicates that the multicast interface on the corresponding member device belongs to the member interface in the corresponding multicast group. The preset value can be 0 or 1.

[0221] For example, the default value is 1. If the IRF system includes member devices A through E, then the multicast MAC entry ID can be a five-bit binary string, with each bit corresponding to one member device. For details on the correspondence, please refer to [link to relevant documentation]. Figure 8 As shown. Where the 0th and 3rd bits are 1, it indicates... Figure 8 The multicast MAC entry ID shown indicates that the member interfaces in the multicast group are located on member devices A and D.

[0222] When adding a multicast group in the IRF system, the corresponding multicast MAC entry ID is added to the multicast forwarding table; when adding a new member device in the IRF system, the bit corresponding to the new member device is added to each multicast MAC entry ID; when adding a multicast interface on a member device in a multicast group, the bit corresponding to the member device in the multicast MAC entry ID of the multicast group is set to a preset value.

[0223] The first member device is configured with a preset multicast MAC table, which records the correspondence between multicast table entry identifiers and multicast MAC addresses, such as {multicast MAC table entry ID, multicast MAC address}.

[0224] When initializing each member device in the IRF system, after obtaining the preset multicast MAC table, the member device traverses each multicast MAC table entry ID. If the bit corresponding to the member device in the multicast MAC table entry ID is the preset value, the multicast MAC address corresponding to the multicast MAC table entry ID is added to the MAC address table of the RPR interface, allowing packets with the destination MAC address of the multicast MAC address to enter the device.

[0225] After receiving the first data packet, the first member device queries the multicast forwarding table to obtain the multicast entry identifier corresponding to the packet characteristics of the first data packet, i.e., the target multicast entry identifier. If the bits corresponding to other member devices (such as the second member device) in the target multicast entry identifier are preset values, then the first multicast MAC address corresponding to the target multicast entry identifier is searched from the preset multicast MAC table.

[0226] If the bits corresponding to other member devices (such as the second member device) in the target multicast entry identifier are not the preset values, it means that the other member devices do not include the member interface in the first multicast group corresponding to the first data packet. Therefore, there is no need to encapsulate the first data packet, and the first data packet can be forwarded locally.

[0227] Taking a preset value of 1 as an example. After the first member device obtains the target multicast entry identifier, the multicast entry identifier obtained by masking the corresponding bit of the first member device is not 0. This indicates that the bit corresponding to other member devices is the preset value. Then, the first multicast MAC address corresponding to the target multicast entry identifier is searched from the preset multicast MAC table.

[0228] The processing of the first RPR message for multicast / broadcast by other member devices (such as the second member device) in the IRF system is the same as the processing of the third RPR message for multicast / broadcast by the first member device, and will not be repeated here.

[0229] 2) The forwarding method for data packets is unicast, that is, the service packet is a third data packet, the third data packet is a unicast packet, and the third data packet is sent using the unicast method.

[0230] In this case, step S402 can be as follows: Based on the message characteristics of the third data message, determine the first unicast interface corresponding to the third data message; if the first unicast interface is a unicast interface on the second member device in the IRF system, then encapsulate the third data message with a third custom header to obtain a second custom message, wherein the third custom header includes the identifier of the first unicast interface; encapsulate the second custom message with a first RPR header to obtain a first RPR message, wherein the destination MAC address in the first RPR header is the unicast MAC address of the second member device.

[0231] Upon receiving the third data packet, the first member device extracts its packet characteristics and then queries its forwarding table to determine the corresponding unicast interface, i.e., the first unicast interface. If the first unicast interface is a local unicast interface of the first member device, the first member device directly forwards the third data packet to devices outside the IRF system through this first unicast interface. If the first unicast interface is not a unicast interface on the first member device, such as a unicast interface on the second member device, the first member device generates a third custom header including the identifier of the first unicast interface, encapsulates the third data packet with the third custom header, and the resulting packet is the second custom packet. Then, the first member device generates a first RPR header with the destination MAC address being the unicast MAC address of the second member device, encapsulates the second custom packet with the first RPR header, and the resulting RPR packet is the first RPR packet.

[0232] The first member device unicasts the first RPR message through the RPR interface. All member devices in the IRF system can determine that the source member device (i.e., the source frame) of the first RPR message is the first member device based on the SA field in the first RPR header, and can determine that the first RPR message is a unicast message based on the DA field in the first RPR header. They can then determine how to process the first RPR message based on the value of the DA field.

[0233] When the first member device unicasts the first RPR message through the RPR interface, other member devices in the IRF system can also unicast the fourth RPR message through the RPR interface. The fourth RPR message includes a fourth RPR header, a fourth custom header, and a fourth data packet.

[0234] In this case, the above message processing method may further include: receiving a fourth RPR message through the RPR interface; if the destination MAC address in the fourth RPR header is the second unicast MAC address, and the second unicast MAC address is the unicast MAC address of the first member device, then stripping the fourth RPR header and the fourth custom header included in the fourth RPR message to obtain a fourth data message; determining the second unicast interface pointed to by the unicast interface identifier in the fourth custom header; forwarding the fourth data message through the second unicast interface; if the destination MAC address in the fourth RPR header is the second unicast MAC address, and the second unicast MAC address is not the unicast MAC address of the first member device, then sending the fourth RPR message through the RPR interface.

[0235] In this embodiment, after the first member device receives the fourth RPR message through the RPR interface, it can identify on the RPR interface that the protocol number in the fourth RPR header indicates that the fourth RPR message carries a data packet, and that the destination MAC address is a unicast MAC address (i.e., the second unicast MAC address). The first member device is configured with a MAC address table for the RPR interface, which records the unicast MAC address and multicast MAC address of the first member device.

[0236] The first member device can query the MAC address table of the RPR interface to determine whether the second unicast MAC address is the unicast MAC address of the first member device, and then perform different processing on the fourth RPR message based on the determination result.

[0237] A. The determined result is: the second unicast MAC address is the unicast MAC address of the first member device.

[0238] In this scenario, the first member device removes the fourth RPR header and the fourth custom header from the fourth RPR message to obtain the fourth data packet. The first member device then retrieves the unicast interface identifier from the fourth custom header, determines the second unicast interface corresponding to this identifier, and forwards the fourth data packet to devices outside the IRF system through the second unicast interface. If...

[0239] Here, the first member device acts as a downlink device (egress device). After forwarding the fourth data packet through the second unicast interface, the first member device no longer encapsulates the fourth data packet and forwards the RPR packet through the RPR interface, that is, it no longer forwards across frames.

[0240] B, the determined result is: the second unicast MAC address is not the unicast MAC address of the first member device.

[0241] In this case, the first member device continues to send the fourth RPR message through the RPR interface without sending the fourth RPR message to the CPU or switching board, thus realizing RPR loopback processing and reducing the occupation of forwarding resources.

[0242] The processing of the first unicast RPR message by other member devices (such as the second member device) in the IRF system is the same as the processing of the fourth unicast RPR message by the first member device, and will not be repeated here.

[0243] In some embodiments, to further reduce the complexity of message processing in the IRF system, the IRF system can use RPR ring topology messages to achieve master device election, which may specifically include the following steps.

[0244] Step 1: Receive topology messages sent by other member devices in the IRF system through the RPR interface. The topology message includes a master device field and a local device field. The master device field is used to carry the frame number of the master device, and the local device field is used to carry the frame number of the source member device corresponding to the topology message.

[0245] According to the RPR protocol specification, each node in an RPR ring automatically discovers the topology and updates its ring selection table (i.e., the RPR table). RPR table entries include: MAC address, ring number (RI), and time-to-live (TTL). The MAC address identifies different nodes and is also the source MAC address (SA) in the packet header. The RPR ring has a dual-ring structure, with the ring number (RI) being either 0 or 1. Different TTLs correspond to different TTLs for a node (source MAC address) to reach other nodes (destination MAC address, DA) through different rings. When uploading traffic, the ring with the shortest TTL is selected for transmission. The structure of the RPR protocol topology packet is as follows: Figure 9a As shown, it includes fields such as version number, type, length, RI, SA, DA, timestamp, node information TLV, reserved, and FCS.

[0246] In an IRF system, each member device is identified by a frame number, and different frame numbers have different MAC addresses. To obtain the correspondence between frame numbers and MAC addresses in the IRF system, a "Local Device" field and a "Master Device" field have been added to the topology packet. The Master Device field carries the frame number of the master device, and the Local Device field carries the frame number of the source member device corresponding to the topology packet. To reduce the difficulty of modifying the topology packet and facilitate implementation, in some embodiments, the reserved field of the topology packet is modified, dividing the reserved field into two subfields: a first subfield and a second subfield. The first subfield is the Local Device field, and the second subfield is the Master Device field. For example, bits [0:3] of the reserved field are used as the Local Device field, and bits [4:7] of the reserved field are used as the Master Device field, such as... Figure 9b As shown.

[0247] In an IRF system, each member device can periodically send topology messages through the RPR interface. These topology messages allow each member device to know the frame number and MAC address of all devices in the topology. At this point, the IRF entry adds the frame number to the RPR entry; that is, the IRF entry includes: frame number, MAC address, RI, and TTL.

[0248] Step 2: If a preset number of topology messages with empty master device fields are received consecutively, and the frame number carried by the local device field in the preset number of topology messages is greater than the frame number of the first member device, then the first member device is determined to be a temporary master device.

[0249] In this embodiment of the application, the preset quantity can be set according to actual needs, for example, the preset quantity is 3, 5 or 8, etc.

[0250] If, up to the current time, the first member device continuously receives a preset number of topology messages with an empty master device field, it indicates that the master device election has not been completed. In addition, the frame number carried by the local device field in these preset number of topology messages is greater than the frame number of the first member device, that is, the frame number of the first member device is the smallest. Therefore, the first member device is determined to be the temporary master device, and then step three or step four is executed.

[0251] If a preset number of topology messages containing the frame number of the third member device as the master device are received consecutively, the first member device can consider the election complete and determine the third member device as the master device in the IRF system.

[0252] Step 3: When the first member device is a temporary master device, if multiple topology messages are received with the master device field not empty and the frame number carried by the master device field being greater than the frame number of the first member device, or multiple topology messages with the master device field empty, then the first member device is determined to be the master device in the IRF system.

[0253] When the first member device is a temporary master device, each member device in the IRF system will still periodically send topology messages through the RPR interface. In this case, if the first member device receives multiple topology messages with a non-empty master device field, and the frame number carried by the master device field in these multiple topology messages is greater than the frame number of the first member device, and the frame number of the first member device is the smallest, then the first member device is determined to be the master device.

[0254] Step 4: When the first member device is a temporary master device, if at least one topology message is received where the master device field is not empty and the priority of the frame number carried by the master device field is lower than that of the first member device's frame number, then the first member device is determined to be a slave device in the IRF system.

[0255] When the first member device is a temporary master device, each member device in the IRF system will still periodically send topology messages through the RPR interface. In this case, if the first member device receives multiple topology messages with a non-empty master device field, and in at least one of these topology messages, the frame number carried by the master device field has a lower priority than the frame number of the first member device, then the first member device is determined to be a slave device in the IRF system.

[0256] The following is combined Figure 10 The master device election process shown illustrates the master device election method in the IRF system provided in this application embodiment. The preset number is 3. The process is executed when a member device 1 in the IRF system starts up, or after the master device in the IRF system disappears. Figure 10 The process is shown below.

[0257] In step S1001, member device 1 periodically sends topology message 1 through the RPR interface and receives multiple topology messages 2 sent by other member devices through the RPR interface. The number of multiple topology messages 2 corresponding to each other member device can be greater than or equal to the preset number mentioned above, such as multiple topology messages 2 corresponding to each other member device ≥ 5.

[0258] In Topology Message 1, the "Local Device" field is frame number 1 of member device 1, and the "Master Device" field is the frame number of the master device confirmed by member device 1. If the master device is not confirmed, the "Master Device" field is empty. In Topology Message 2, the "Local Device" field is the frame number of the member device that sent Topology Message 2, such as frame number 2, frame number 3, etc. The "Local Device" field in Topology Message 2 is the frame number of the master device confirmed by the member device that sent Topology Message 2. If the master device is not confirmed, the "Master Device" field is empty.

[0259] In step S1002, for each topology message 2 received, member device 1 determines whether the master device field in the topology message 2 is empty; if not, i.e. the master device field is not empty, then proceed to step S1003; if yes, i.e. the master device field is empty, and no five topology messages 2 sent by a member device have been received, then continue to proceed to step S1001; if more than five topology messages 2 sent by various member devices are received, then proceed to step S1006, at which point the master device detection count is 0.

[0260] Step S1003: Member device 1 updates the master device discovery count. Specifically, if the frame number carried by the master device field in the current topology message 2 is different from the recorded master device frame number, the recorded master device frame number is updated to the frame number carried by the master device field, and the master device discovery count is updated to 0; if the frame number carried by the master device field in the current topology message 2 is the same as the recorded master device frame number, the master device discovery count is incremented by 1.

[0261] In step S1004, member device 1 determines whether the master device discovery count is greater than or equal to 3; if yes, then proceed to step S1005; if no, then continue to proceed to step S1001.

[0262] In step S1005, member device 1 determines that the member device indicated by the recorded master device frame number is the master device; the value carried by the master device field in topology message 1 can be updated to the recorded master device frame number.

[0263] In step S1006, member device 1 determines whether its frame number is the smallest; if not, it continues to step S1001; if so, it proceeds to step S1007.

[0264] In this step, member device 1 compares the frame number carried in the local device field of each topology message 2 with the frame number of member device 1; if the frame number of member device 1 is the smallest, then step S1007 is executed; member device 1 is determined to be a temporary master device; if the frame number of member device 1 is not the smallest frame number, then step S1001 is executed.

[0265] Step S1007: Member device 1 determines itself as a temporary master device.

[0266] In step S1008, member device 1 periodically sends topology message 1 through the RPR interface and receives multiple topology messages 2 sent by other member devices through the RPR interface.

[0267] In step S1009, member device 1 determines whether the master device field in these multiple topology packets 2 is empty; if yes, that is, the master device field is empty, then proceed to step S1011; if no, that is, the master device field is not empty, then proceed to step S1010.

[0268] In step S1010, member device 1 determines whether its frame number is the smallest; if not, proceed to step S1012; if yes, proceed to step S1011.

[0269] In this step, member device 1 compares the frame number carried in the local field of each topology message 2 with the frame number of member device 1; if the frame number of member device 1 is the smallest, then step S1011 is executed; if the frame number of member device 1 is not the smallest frame number, then step S1012 is executed.

[0270] Step S1011: Member device 1 determines itself as the master device.

[0271] In step S1012, member device 1 cancels the temporary master device status and continues to execute step S1001.

[0272] In the technical solution provided in this application embodiment, the IRF system borrows the RPR protocol when performing message processing such as cross-frame forwarding and topology discovery, without the need for a self-developed IRF protocol, resulting in low implementation complexity.

[0273] From the perspective of RPR ring network: In this embodiment of the application, the RPR ring is transformed into an IRF device, which has the advantages of IRF mentioned above.

[0274] From a stacking perspective: In this embodiment of the application, it is not necessary to implement a separate IRF protocol; the RPR protocol can be used, which has the advantages of RPR mentioned above.

[0275] Corresponding to the above message processing method, this application also provides a message processing apparatus, such as... Figure 11 As shown, a first member device applied in an IRF system includes:

[0276] The acquisition module 1101 is used to acquire business messages to be processed;

[0277] Encapsulation module 1102 is used to encapsulate the service message with a first RPR header to obtain a first RPR message. The destination MAC address in the first RPR header points to other member devices in the IRF system other than the first member device.

[0278] The sending module 1103 is used to send the first RPR message through the RPR interface on the first member device.

[0279] In some embodiments, the service message is a first control message;

[0280] The acquisition module is specifically used to generate the first control message to be processed.

[0281] The encapsulation module is specifically used to determine that the destination MAC address corresponding to the first control message is a broadcast MAC address; to encapsulate the first control message with a first RPR header whose destination MAC address is a broadcast MAC address, thereby obtaining the first RPR message; or,

[0282] The encapsulation module is specifically used to determine that the destination MAC address corresponding to the first control message is the unicast MAC address of the second member device in the IRF system; and to encapsulate the first control message with a first RPR header whose destination MAC address is the unicast MAC address of the second member device, thereby obtaining the first RPR message.

[0283] In some embodiments, the above-described message processing apparatus may further include;

[0284] The receiving module is used to receive a second RPR message through the RPR interface. The second RPR message carries a second RPR header and a second control message.

[0285] The processing module is used to send a second RPR message through the RPR interface if the destination MAC address in the second RPR header is a broadcast MAC address, and to remove the second RPR header included in the second RPR message to obtain a second control message; and to process the second control message.

[0286] In some embodiments, the above-described message processing apparatus may further include;

[0287] The receiving module is used to receive a second RPR message through the RPR interface. The second RPR message carries a second RPR header and a second control message.

[0288] The processing module is configured to, if the destination MAC address in the second RPR header is the first unicast MAC address and the first unicast MAC address is the unicast MAC address of the first member device, then strip the second RPR header included in the second RPR message to obtain the second control message; process the second control message; if the destination MAC address in the second RPR header is the first unicast MAC address and the first unicast MAC address is not the unicast MAC address of the first member device, then send the second RPR message through the RPR interface.

[0289] In some embodiments, the service message is a first data message, and the first data message is a multicast message;

[0290] The acquisition module 1101 is specifically used to receive the first data packet sent by a device outside the IRF system;

[0291] The encapsulation module 1102 is specifically used to determine the first multicast group corresponding to the first data packet based on the packet characteristics of the first data packet; if the first multicast group includes an RPR interface, then encapsulate the first data packet with a first custom header to obtain a first custom packet, the first custom header including the identifier of the first multicast group; encapsulate the first custom packet with a first RPR header to obtain a first RPR packet, the destination MAC address in the first RPR header being either a broadcast MAC address or the first multicast MAC address corresponding to the first multicast group.

[0292] In some embodiments, the above-described message processing apparatus may further include;

[0293] The receiving module is used to receive a third RPR message through the RPR interface. The third RPR message includes a third RPR header, a second custom header, and a second data message.

[0294] The processing module is configured to: if the destination MAC address in the third RPR header is a broadcast MAC address, send a third RPR message through the RPR interface, and strip the third RPR header and the second custom header included in the third RPR message to obtain a second data message; determine the second multicast group corresponding to the multicast group identifier in the second custom header; if the second multicast group includes the first multicast interface on the first member device, forward the second data message through the first multicast interface; if the second multicast group does not include the first multicast interface on the first member device, discard the second data message.

[0295] In some embodiments, the above-described message processing apparatus may further include;

[0296] The receiving module is used to receive a third RPR message through the RPR interface. The third RPR message includes a third RPR header, a second custom header, and a second data message.

[0297] The processing module is configured to: if the destination MAC address in the third RPR header is the second multicast MAC address, and the second multicast MAC address is the multicast MAC address of the first member device, then send a third RPR message through the RPR interface, and strip the third RPR header and the second custom header of the third RPR message to obtain a second data packet; determine the second multicast group corresponding to the multicast group identifier in the second custom header; and forward the second data packet through the second multicast interface on the first member device in the second multicast group; if the destination MAC address in the third RPR header is the second multicast MAC address, and the second multicast MAC address is not the multicast MAC address of the first member device, then send a third RPR message through the RPR interface.

[0298] In some embodiments, the above-described message processing apparatus may further include;

[0299] The first query module is used to query the multicast forwarding table based on the message characteristics of the first data packet to obtain the target multicast entry identifier. The multicast forwarding table stores the correspondence between message characteristics and multicast entry identifiers. Each bit in the multicast entry identifier corresponds to a member device in the IRF system. When a bit is a preset value, it indicates that the multicast interface on the corresponding member device belongs to the member interface in the corresponding multicast group.

[0300] The second query module is used to search for the first multicast MAC address corresponding to the target multicast entry identifier from the preset multicast MAC table when the bit corresponding to other member devices in the target multicast entry identifier is a preset value.

[0301] In some embodiments, the sending module 1103 can also be used to forward the first data packet through the third multicast interface if the first multicast group includes a third multicast interface on the first member device.

[0302] In some embodiments, the service message is a third data message, and the third data message is a unicast message;

[0303] The acquisition module 1101 is specifically used to receive third data packets sent by devices outside the IRF system;

[0304] The encapsulation module 1102 is specifically used to determine the first unicast interface corresponding to the third data packet based on the packet characteristics of the third data packet; if the first unicast interface is a unicast interface on the second member device in the IRF system, then the third data packet is encapsulated with a third custom header to obtain a second custom packet, the third custom header including the identifier of the first unicast interface; the second custom packet is encapsulated with a first RPR header to obtain a first RPR packet, the destination MAC address in the first RPR header being the unicast MAC address of the second member device.

[0305] In some embodiments, the above-described message processing apparatus may further include;

[0306] The receiving module is used to receive the fourth RPR message through the RPR interface. The fourth RPR message includes the fourth RPR header, the fourth custom header, and the fourth data message.

[0307] The processing module is configured to, if the destination MAC address in the fourth RPR header is the second unicast MAC address, and the second unicast MAC address is the unicast MAC address of the first member device, then strip the fourth RPR header and the fourth custom header included in the fourth RPR message to obtain the fourth data message; determine the second unicast interface pointed to by the unicast interface identifier in the fourth custom header; and forward the fourth data message through the second unicast interface; if the destination MAC address in the fourth RPR header is the second unicast MAC address, and the second unicast MAC address is not the unicast MAC address of the first member device, then send the fourth RPR message through the RPR interface.

[0308] In some embodiments, the RPR header of each RPR message carries a specified protocol number and message class, with the specified protocol number indicating whether it is a control message or a data message.

[0309] In some embodiments, the above-described message processing apparatus may further include;

[0310] The receiving module is used to receive topology messages sent by other member devices in the IRF system through the RPR interface. The topology message includes a master device field and a local device field. The master device field is used to carry the frame number of the master device, and the local device field is used to carry the frame number of the source member device corresponding to the topology message.

[0311] The first determining module is used to determine the first member device as a temporary master device if it continuously receives a preset number of topology messages with empty master device fields, and the frame number carried by the local device field in the preset number of topology messages is greater than the frame number of the first member device.

[0312] The second determining module is used to determine that the first member device is the master device in the IRF system if, when the first member device is a temporary master device, it receives multiple topology messages with a non-empty master device field and a frame number carried by the master device field that is greater than the frame number of the first member device, or receives multiple topology messages with an empty master device field.

[0313] In some embodiments, the second determining module is further configured to, when the first member device is a temporary master device, determine that the first member device is a slave device in the IRF system if it receives at least one topology message in which the master device field is not empty and the priority of the frame number carried by the master device field is lower than that of the frame number of the first member device.

[0314] In some embodiments, the first determining module is further configured to:

[0315] If a preset number of topology messages with the frame number of the third member device as the master device are received consecutively, then the third member device is determined to be the master device in the IRF system.

[0316] In some embodiments, the reserved fields of the topology message include a first subfield and a second subfield, wherein the first subfield is the local device field and the second subfield is the master device field.

[0317] In the technical solution provided in this application embodiment, when member devices in the IRF system process service packets, they encapsulate the service packets with an RPR header to obtain RPR packets. Then, member devices in the IRF system can use the RPR interface to forward RPR packets (i.e., service packets) between member devices in the IRF system. In this application embodiment, when member devices in the IRF system process service packets, they do not need to use a self-developed IRF protocol, but can use the RPR protocol instead, reducing the complexity of packet processing in the IRF system.

[0318] This application also provides a network device, such as... Figure 12 As shown, it includes a processor 1201, a communication interface 1202, a memory 1203, and a communication bus 1204, wherein the processor 1201, the communication interface 1202, and the memory 1203 communicate with each other through the communication bus 1204.

[0319] Memory 1203 is used to store computer programs;

[0320] When the processor 1201 executes the program stored in the memory 1203, the network device, as a member device in the IPR system, implements any of the above-mentioned message processing methods.

[0321] The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0322] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0323] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0324] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0325] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the above-described message processing methods.

[0326] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the message processing methods described above.

[0327] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0328] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0329] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, network devices, storage media, and program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0330] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method of processing a packet, the method comprising: A method applied to a first member device in an IRF system, the method comprising: obtaining a service packet to be processed; encapsulating a first RPR header for the service packet to obtain a first RPR packet, a destination MAC address in the first RPR header pointing to other member devices in the IRF system except the first member device; sending the first RPR packet through an RPR interface on the first member device.

2. The method of claim 1, wherein, The service packet is a first control packet; The step of obtaining the service packet to be processed comprises: generating the first control packet to be processed; The step of encapsulating the first RPR header for the service packet to obtain the first RPR packet comprises: determining that the destination MAC address corresponding to the first control packet is a broadcast MAC address, and encapsulating the first RPR header with the destination MAC address being the broadcast MAC address for the first control packet to obtain the first RPR packet; or determining that the destination MAC address corresponding to the first control packet is a unicast MAC address of a second member device in the IRF system, and encapsulating the first RPR header with the destination MAC address being the unicast MAC address of the second member device for the first control packet to obtain the first RPR packet.

3. The method of claim 2, wherein, The method further comprises: receiving a second RPR packet through the RPR interface, the second RPR packet carrying a second RPR header and a second control packet; if the destination MAC address in the second RPR header is a broadcast MAC address, sending the second RPR packet through the RPR interface and stripping the second RPR header included in the second RPR packet to obtain the second control packet; processing the second control packet; if the destination MAC address in the second RPR header is a first unicast MAC address, the first unicast MAC address being a unicast MAC address of the first member device, stripping the second RPR header included in the second RPR packet to obtain the second control packet; processing the second control packet; if the destination MAC address in the second RPR header is a first unicast MAC address, the first unicast MAC address not being a unicast MAC address of the first member device, sending the second RPR packet through the RPR interface.

4. The method of claim 1, wherein, The service packet is a first data packet, and the first data packet is a multicast packet; The step of obtaining the service packet to be processed comprises: receiving the first data packet sent by a device outside the IRF system; The step of encapsulating the first RPR header for the service packet to obtain the first RPR packet comprises: determining a first multicast group corresponding to the first data packet according to a packet feature of the first data packet; if the first multicast group includes the RPR interface, encapsulating a first custom header for the first data packet to obtain a first custom packet, the first custom header including an identifier of the first multicast group; encapsulating a first RPR header for the first custom packet to obtain a first RPR packet, a destination MAC address in the first RPR header being a broadcast MAC address or a first multicast MAC address corresponding to the first multicast group; The method further comprises: If the first multicast group includes a third multicast interface on the first member device, forwarding the first data packet through the third multicast interface.

5. The method of claim 4, wherein, The method further comprises: receiving a third RPR packet through the RPR interface, the third RPR packet including a third RPR header, a second custom header and a second data packet; If the destination MAC address in the third RPR header is the broadcast MAC address, sending the third RPR packet through the RPR interface and stripping the third RPR header and the second custom header included in the third RPR packet to obtain a second data packet; determining a second multicast group corresponding to a multicast group identifier in the second custom header; if the second multicast group includes the first multicast interface on the first member device, forwarding the second data packet through the first multicast interface; if the second multicast group does not include the first multicast interface on the first member device, discarding the second data packet; If the destination MAC address in the third RPR header is a second multicast MAC address, the second multicast MAC address being a multicast MAC address of the first member device, sending the third RPR packet through the RPR interface and stripping the third RPR header and the second custom header of the third RPR packet to obtain a second data packet; determining a second multicast group corresponding to a multicast group identifier in the second custom header; forwarding the second data packet through a second multicast interface on the first member device in the second multicast group; If the destination MAC address in the third RPR header is a second multicast MAC address, the second multicast MAC address not being a multicast MAC address of the first member device, sending the third RPR packet through the RPR interface.

6. The method of claim 4, wherein, The method further comprises: querying a multicast forwarding table according to a packet feature of the first data packet to obtain a target multicast table item identifier, the multicast forwarding table storing a correspondence between a packet feature and a multicast table item identifier, each bit in the multicast table item identifier corresponding to a member device in the IRF system, a member interface on a corresponding member device belonging to a corresponding multicast group when a bit is a preset value; when the bit corresponding to other member devices in the target multicast table item identifier is the preset value, searching the first multicast MAC address corresponding to the target multicast table item identifier from a preset multicast MAC table.

7. The method of claim 1, wherein, The service packet is a third data packet, and the third data packet is a unicast packet; The step of obtaining the service packet to be processed comprises: receiving a third data packet sent by a device outside the IRF system; The step of encapsulating a first RPR header for the service packet to obtain a first RPR packet comprises: According to a message feature of the third data message, a first unicast interface corresponding to the third data message is determined; If the first unicast interface is a unicast interface on a second member device in the IRF system, a third custom header is encapsulated for the third data message to obtain a second custom message, and the third custom header includes an identifier of the first unicast interface; A first RPR header is encapsulated for the second custom message to obtain a first RPR message, and a destination MAC address in the first RPR header is a unicast MAC address of the second member device.

8. The method of claim 7, wherein, The method further includes: A fourth RPR message is received through the RPR interface, and the fourth RPR message includes a fourth RPR header, a fourth custom header and a fourth data message; If a destination MAC address in the fourth RPR header is a second unicast MAC address, the second unicast MAC address is a unicast MAC address of the first member device, the fourth RPR header and the fourth custom header included in the fourth RPR message are stripped to obtain the fourth data message, and a second unicast interface pointed by a unicast interface identifier in the fourth custom header is determined; The fourth data message is forwarded through the second unicast interface; If the destination MAC address in the fourth RPR header is the second unicast MAC address, the second unicast MAC address is not the unicast MAC address of the first member device, and the fourth RPR message is sent through the RPR interface.

9. The method according to any one of claims 2-8, characterized in that, A specified protocol number and a message level are carried in the RPR header of each RPR message, and the specified protocol number indicates a control message or a data message.

10. The method of claim 1, wherein, The method further includes: A topology message sent by another member device in the IRF system is received through the RPR interface, the topology message includes a master device field and a local device field, the master device field is used to carry a frame number of a master device, and the local device field is used to carry a frame number of a source member device corresponding to the topology message; If a preset number of topology messages with the frame number of the third member device in the master device field are continuously received, the third member device is determined as the master device in the IRF system; If a preset number of topology messages with the empty master device field are continuously received, and frame numbers carried in the local device fields of the preset number of topology messages are greater than the frame number of the first member device, the first member device is determined as a temporary master device; When the first member device is the temporary master device, if a plurality of topology messages with the non-empty master device field and the frame number carried in the master device field greater than the frame number of the first member device are received, or a plurality of topology messages with the empty master device field are received, the first member device is determined as the master device in the IRF system; When the first member device is the temporary master device, if at least one topology message with the non-empty master device field and a priority of the frame number carried in the master device field smaller than the frame number of the first member device is received, the first member device is determined as a slave device in the IRF system.

11. The method of claim 10, wherein, The first subfield is a local device field, and the second subfield is a master device field.

12. A packet processing device, characterized by, The device is applied to a first member device in an IRF system, and the device comprises: An acquisition module is configured to acquire a service message to be processed. An encapsulation module is configured to encapsulate a first RPR header for the service message to obtain a first RPR message, wherein a destination MAC address in the first RPR header points to other member devices in the IRF system except the first member device. A sending module is configured to send the first RPR message through an RPR interface on the first member device.

13. An electronic device, comprising: The device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus. The memory is configured to store a computer program. The processor is configured to execute the program stored in the memory to implement the method in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1-11.

Images