A method for large-scale IP multicast service two-layer ring reliable switch cluster

Abstract

The application discloses a kind of large-scale IP multicast service's two-layer annular reliable switch cluster method, comprising: interconnection switch 1, switch 2, switch 3 and switch 4 into 1 annular network, to constitute annular cluster;Adjacent switch 1 and switch 2 are configured as an aggregation switch;Switch 3 and switch 4 are set as normal switch;The port of aggregation switch, switch 3 and switch 4 is divided into inter-machine interconnection port and normal end device access port;Annular cluster is configured using modified IGMP snooping, and the mapping relationship table of IP multicast service frame and destination port is obtained;When switch receives IP multicast service frame, according to mapping relationship table, find the destination port corresponding to IP multicast service frame received by itself, send IP multicast service frame to corresponding destination port, while forwarding IP multicast service frame to adjacent switch, realize two-layer forwarding to IP multicast service.

Description

Technical Field

[0001] This invention belongs to the field of switch networks, specifically relating to a Layer 2 ring reliable switch cluster method for large-scale IP multicast services. Background Technology

[0002] In today's internet and communications fields, the processing of large-capacity and high-speed data streams has become increasingly important and urgent. From network communications to cloud computing, from big data analytics to real-time video transmission, the ability to efficiently process massive data streams is essential. Switches, as key network devices, are crucial nodes for forwarding network data to all terminal devices; their performance and reliability are critical to the end devices that need to forward services across the entire network. Simultaneously, with the increasing complexity of business environments, the number of end devices that a single switch needs to connect to, and the number of containers mounted on a single end device, have increased rapidly. Large-scale IP multicast services are becoming increasingly common. IP multicast technology provides an efficient data transmission method, enabling the simultaneous transmission of large amounts of audio and video streams, real-time data, and other multimedia content in wide area networks (WANs) and local area networks (LANs). However, due to the increasing volume of multicast data and the demands on network capacity, traditional network architectures and switch designs are no longer suitable for handling large-scale IP multicast services. Therefore, a new switch clustering approach is needed that can meet the requirements of modern large-scale IP multicast services while also providing reliability for data forwarding by end devices.

[0003] Currently, many large organizations and enterprises use Layer 2 ring topologies in their networks to provide high availability and redundant connectivity. However, in traditional Layer 2 ring topologies, due to backpressure issues between switches and circular packet forwarding, this topology cannot effectively handle large-scale IP multicast traffic. In multicast transmission, packet duplication and delivery often lead to network congestion and increased latency, thereby reducing system performance and user experience. To support a large number of end devices and the reliability of end device data in current switched networks, the connected switches must have sufficient resources. Since implementing switch designs using FPGAs is currently more convenient than using chips, many manufacturers use FPGAs. However, FPGAs have limited logic and storage resources, and a single FPGA board cannot support the switching needs of a large number of connected devices.

[0004] Based on the above analysis, the problems and shortcomings of the existing technology are as follows:

[0005] (1) The number of ports on existing individual switches is too small to enable large-scale end device access;

[0006] (2) Due to the limitations of the internal resources of the FPGA, a single switch board cannot store enough multicast entries, especially when performing IP multicast services;

[0007] (3) Existing switch networks cannot improve the reliability of data forwarding for access devices, and cannot even back up individual data streams. Once the network link is disconnected, data transmission to end devices may fail.

[0008] (4) Although conventional switches can also form cascades, the cascade topology is not flexible enough and cannot improve the reliability of network links. They also cannot differentiate between end devices with different service requirements. Summary of the Invention

[0009] To address the aforementioned problems in the existing technology, this invention provides a Layer 2 ring-based reliable switch cluster method for large-scale IP multicast services. The technical problem to be solved by this invention is achieved through the following technical solution:

[0010] A method for a Layer 2 ring-reliable switch cluster for large-scale IP multicast services includes:

[0011] Switches 1, 2, 3, and 4 are interconnected to form a ring network, thus creating a ring cluster.

[0012] The adjacent switches 1 and 2 are configured as a single aggregation switch; the aggregation switch is used to access user terminal equipment and equipment with special requirements.

[0013] The switches 3 and 4 are configured as ordinary switches; both switches 3 and 4 are used to access network terminal devices and user terminal devices.

[0014] The ports of the aggregation switch, the switch 3, and the switch 4 are divided into inter-machine interconnection ports and ordinary terminal device access ports;

[0015] A modified IGMP snooping configuration is applied to the ring cluster to obtain a mapping table of IP multicast service frames and destination ports;

[0016] When a switch in the ring cluster receives an IP multicast service frame, it finds the destination port corresponding to the IP multicast service frame it received according to the mapping table, sends the IP multicast service frame to the corresponding destination port, and forwards the IP multicast service frame to the adjacent switch, thereby realizing Layer 2 forwarding of IP multicast services.

[0017] In one embodiment of the present invention, the CPUs of switch 1 and switch 2 are configured with aggregation group information; the aggregation group information includes: group number and priority information; the group number is the identity identifier in the aggregation group formed by switch 1 and switch 2; the priority information indicates the priority of the switch operation.

[0018] In one embodiment of the present invention, the adjacent switches 1 and 2 are configured as a single aggregation switch, including:

[0019] The aggregation group information is configured by the CPUs of switch 1 and switch 2, and the aggregation group information is configured to their respective hardware FPGA boards via PIO;

[0020] The hardware FPGA boards of switch 1 and switch 2 encapsulate the received aggregate group information after configuration and broadcast it as an aggregate group hello message on their local ports to send their own aggregate group hello message to their adjacent switches.

[0021] When an adjacent switch receives the corresponding aggregation group hello message, it checks whether it meets the preset conditions: it has an aggregation group number that is the same as the aggregation group number in the received aggregation group hello message. If it meets the conditions, it determines that the group of switches that send and receive the aggregation group hello message is a pair of switches to be paired. The ports of the switches to be paired that are responsible for sending and receiving aggregation group hello messages are connected to each other to form an intra-group interconnection port, thus forming an aggregation switch.

[0022] While completing the aggregation, the switch receiving the corresponding aggregation group hello message compares the priority information in the received aggregation group hello message with its own priority information to confirm the master device and the slave device.

[0023] In one embodiment of the present invention, the switch receiving the corresponding aggregation group hello message compares the priority information in the corresponding aggregation group hello message with its own priority information to confirm the master device and the slave device, including:

[0024] The switch receiving the aggregation group hello message determines whether the priority information in the received aggregation group hello message is greater than its own priority information;

[0025] If so, the switch that sends the aggregation group hello message is determined to be the master device, and the switch that receives the aggregation group hello message is the slave device;

[0026] If not, the switch receiving the aggregation group hello message is determined to be the master device, and the switch sending the aggregation group hello message is determined to be the slave device.

[0027] In one embodiment of the present invention, the link of the interconnection port within the group is a peer link.

[0028] In one embodiment of the present invention, the ports of the aggregation switch, the switch 3, and the switch 4 are divided into inter-device interconnection ports and ordinary terminal device access ports, including:

[0029] Manual partitioning mode and automatic partitioning recognition mode.

[0030] In one embodiment of the present invention, the manual pattern division process includes:

[0031] After receiving the user's configuration command, the CPU of the current switch sends the inter-machine interconnection port number of the current switch to the hardware FPGA board of the current switch, and the hardware FPGA board of the current switch performs maintenance.

[0032] In one embodiment of the present invention, the process of automatically identifying the segmentation pattern includes:

[0033] The CPU of the current switch sends a port discovery command to its own hardware FPGA board. After sensing the port discovery command, the hardware FPGA board performs framing. The information after framing includes its own switch number. The current switch forwards the information after framing in the form of broadcast.

[0034] When a switch receives a framed message containing a number other than its own, the port that received the framed message is designated as an inter-device interconnection port, and the remaining ports are designated as ordinary terminal device access ports.

[0035] When the network access environment changes, the ports are reassigned.

[0036] In one embodiment of the present invention, the process of obtaining the mapping table between IP multicast service frames and destination ports by applying a modified IGMP snooping configuration to the ring cluster includes:

[0037] Select any one switch in the ring cluster and send a normal group query request through the CPU of the selected switch.

[0038] After receiving the normal group query request, the selected switch's hardware FPGA board frames the normal group query message and sends the framed normal group query message to all ports.

[0039] Upon receiving a normal group query message after framing, a user-side device supporting the IGMP protocol generates a group addition message and sends it to the switch connected to the user-side device. The group addition message includes the IP multicast address of the user-side device supporting the IGMP protocol. The switch connected to the user-side device receives the group addition message and sends it to its own CPU. The CPU parses the group addition message, extracts the IP multicast address from the group addition message, and forms a mapping table between the IP multicast address in the group addition message and its port.

[0040] In one embodiment of the present invention, when a switch in the ring cluster receives an IP multicast service frame, it queries the mapping table to find the destination port and forwards the IP multicast service frame to the destination port, thereby realizing the forwarding process of the IP multicast service in the ring cluster, including:

[0041] After receiving the IP multicast service frame, the switches in the ring cluster parse out the IP multicast address in the IP multicast service frame, query the mapping table according to the parsed IP multicast address to obtain the corresponding destination port, send the received IP multicast service frame to the corresponding destination port, and forward the received IP multicast service frame to the two adjacent switches through the inter-machine interconnection port.

[0042] The beneficial effects of this invention are:

[0043] Compared with the prior art, the embodiments of the present invention have the following advantages:

[0044] (1) The cluster structure consisting of 4 switches has a larger access scale and supports more end devices than ordinary switches. In addition, switches can still be added in the cluster model to enhance scalability.

[0045] (2) With limited FPGA resources, it can maintain a large number of forwarding table entries in the cluster, which improves the forwarding capability and processing speed of IP multicast services;

[0046] (3) When one link of the user-side device fails, the aggregation switch selects the remaining links for forwarding. The two switches in the aggregation switch are redundant to each other, which improves the reliability and redundancy of the device.

[0047] (4) Using a ring cluster design, switches 3 and 4 are connected to the network side respectively. When one of the inter-machine links of the switches or the network side link fails, the forwarding of information is guaranteed, thereby achieving high reliability and load balancing. Attached Figure Description

[0048] Figure 1This is a flowchart illustrating a method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services provided in an embodiment of the present invention.

[0049] Figure 2 This is a schematic diagram of a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention.

[0050] Figure 3 A schematic diagram of the aggregation switch structure for a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention;

[0051] Figure 4 A flowchart illustrating the configuration of an aggregation switch in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention.

[0052] Figure 5 A flowchart illustrating port partitioning in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention;

[0053] Figure 6 This is a flowchart illustrating the IGMP snooping configuration of a ring cluster in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention.

[0054] Figure 7 This is a schematic diagram of data flow forwarding in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention during user-side link failure.

[0055] Figure 8 This is a schematic diagram of data flow forwarding during inter-machine link failure in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention.

[0056] Figure 9 This is a schematic diagram of data flow forwarding in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in an embodiment of the present invention, illustrating network-side link failure. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] This invention provides a method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services, such as... Figure 1 As shown, it may include:

[0059] S1 interconnects switch 1, switch 2, switch 3 and switch 4 into a ring network, thus forming a ring cluster;

[0060] S2, configure adjacent switches 1 and 2 into a single aggregation switch; the aggregation switch is used to access user terminal equipment and equipment with special requirements;

[0061] S3, configure switches 3 and 4 as ordinary switches; both switches 3 and 4 are used to access network devices and user devices;

[0062] S4 divides the ports of the aggregation switch, switch 3 and switch 4 into inter-device interconnection ports and ordinary terminal device access ports;

[0063] S5 uses a modified IGMP snooping configuration for the ring cluster to obtain a mapping table of IP multicast service frames and destination ports;

[0064] S6. When a switch in a ring cluster receives an IP multicast service frame, it finds the destination port corresponding to the IP multicast service frame it received according to the mapping table, sends the IP multicast service frame to the corresponding destination port, and forwards the IP multicast service frame to the adjacent switch, thus realizing Layer 2 forwarding of IP multicast services.

[0065] For S1, please refer to the schematic diagram of a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in this embodiment of the invention. Figure 2 The ring cluster model proposed in this embodiment of the invention consists of four switches, each made using an independent FPGA board. These four switches are interconnected to form a ring network, thus constituting a ring cluster. The four switches are differentiated according to their configuration and function. Switch 1 and Switch 2 are configured to appear as a single switch externally, referred to as the aggregated switch. The aggregated switch is used to connect user-end devices and devices with special requirements. Devices with special requirements may include those with high reliability and load capacity. Switches 3 and 4 are not configured for aggregation and are referred to as ordinary switches, both used to connect network-end devices and user-end devices.

[0066] For S2, please refer to the schematic diagram of the aggregation switch structure of the Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in this embodiment of the invention. Figure 3In this embodiment of the invention, there is an aggregation group formed by two switches. The configuration of the aggregation group needs to be completed in the early stage of networking. Usually, two adjacent switches in a ring cluster are combined into an aggregation group. For the connected devices, the two switches in the aggregation group are virtualized into one switch, thereby improving the reliability from the link level to the device level.

[0067] Initially, when forming a ring cluster via links, there are no aggregation groups. Aggregation groups need to be configured at the very beginning. For a flowchart of configuring the aggregation switch, please refer to [link to flowchart]. Figure 4 The configuration process for the aggregation switch is as follows:

[0068] Specifically, configuring adjacent switches 1 and 2 as a single aggregation switch can include:

[0069] S21, the CPUs of switch 1 and switch 2 configure the aggregation group information and configure the aggregation group information to their respective hardware FPGA boards via PIO.

[0070] The CPUs of Switch 1 and Switch 2 are configured with aggregation group information; the aggregation group information may include: group number and priority information; the group number is the identity identifier in the aggregation group formed by Switch 1 and Switch 2; the priority information indicates the priority of the switch operation.

[0071] S22, the hardware FPGA boards of switch 1 and switch 2 encapsulate the received aggregate group information after configuration and broadcast it as an aggregate group hello message on their local ports to send their own aggregate group hello message to their adjacent switches.

[0072] S23, when an adjacent switch receives the corresponding aggregation group hello message, it checks whether it meets the preset conditions: it has an aggregation group number and the aggregation group number is the same as the aggregation group number in the received aggregation group hello message; if it meets the conditions, it determines that the set of switches that send and receive the aggregation group hello message is a pair of switches to be paired; the ports of the switches to be paired that are responsible for sending and receiving the aggregation group hello message are connected to each other to form an intra-group interconnection port, thus forming an aggregation switch;

[0073] S24, while completing the aggregation, the switch receiving the corresponding aggregation group hello message compares the priority information in the received aggregation group hello message with its own priority information to confirm the master device and the slave device.

[0074] For S24, it may include:

[0075] The switch receiving the aggregation group hello message determines whether the priority information in the received aggregation group hello message is greater than its own priority information;

[0076] If so, determine that the switch that sends the aggregation group hello message is the master device, and the switch that receives the aggregation group hello message is the slave device;

[0077] If not, determine that the switch receiving the aggregation group hello message is the master device, and the switch sending the aggregation group hello message is the slave device.

[0078] It should be noted that the same user terminal device can access different switches within the aggregation group simultaneously, and the two access links are equivalent because the terminal device views the switch within the aggregation group as a single unit.

[0079] The interconnecting ports within the group are peer links. After pairing of the aggregation group is completed, the peer link will generally no longer forward data, but will only be used to transmit synchronization information and aggregation group configuration information, such as multicast forwarding table entries and MAC table entries. The switches within the aggregation group share this information used for forwarding.

[0080] After configuring the aggregation group, ports with the same port number on the switches within the aggregation group are set as a group of aggregation member ports. User devices can achieve link aggregation by simultaneously accessing this group of aggregation member ports. Devices need to support the LACP protocol to access the aggregation group and use its aggregation function. After the master device completes pairing, it will perform LACP negotiation. The slave device will modify the MAC addresses of all aggregation member ports on its device to be the same as the master device's system MAC address. Thus, during LACP negotiation, the LACP PDUs sent by the master and slave devices contain the same system ID, making user devices that support the LACP protocol perceive that they are negotiating with the same device, thereby achieving the purpose of cross-device link aggregation.

[0081] For S3, both switch 3 and switch 4 are used to access network-end devices and user-end devices.

[0082] After configuring the switches in a ring trunking system, it is necessary to allocate inter-device interconnection ports and ordinary device access ports. For a flowchart of the port allocation method for a Layer 2 ring reliable switch trunking system for large-scale IP multicast services provided in this embodiment of the invention, please refer to [link to relevant documentation]. Figure 5 .

[0083] For S4, the ports of the aggregation switch, switch 3, and switch 4 are divided into inter-device interconnection ports and general-purpose device access ports, including:

[0084] Manual partitioning mode and automatic partitioning recognition mode.

[0085] S41, the manual partitioning process includes:

[0086] After receiving the user's configuration command, the CPU of the current switch sends the inter-machine interconnection port number of the current switch to the hardware FPGA board of the current switch, and the hardware FPGA board of the current switch performs maintenance.

[0087] S42, the automatic identification and segmentation pattern working process includes:

[0088] The CPU of the current switch sends a port discovery command to its own hardware FPGA board. After sensing the port discovery command, the hardware FPGA board performs framing. The information after framing includes its own switch number. The current switch forwards the framed information in the form of broadcast.

[0089] When a switch receives a framed message that carries a number other than its own switch number, the port that received the framed message is set as an inter-device interconnection port, and the other ports are set as access ports for ordinary end devices.

[0090] When the network access environment changes, the ports are reassigned.

[0091] It is important to note that, with Figure 2 Taking the overall structure shown as an example, switches 3 and 4, as ordinary switches, will generate port discovery frames and broadcast them. Switches 1 and 2, as members of the aggregation group, will also generate their own port discovery frames, but they will block the broadcasting of interconnecting ports within the group (port 2 of switch 1 and port 2 of switch 2). The port discovery frames will be forwarded among network devices. Taking switch 3 as an example, port 1 and port 2 of switch 3 will receive the port discovery frames from switch 1 and switch 4 respectively, thus treating their own port 1 and port 2 as interconnecting ports.

[0092] For S5, the switch cluster supports Layer 2 forwarding for IP multicast services, but requires a modified IGMP snooping configuration to maintain the IP multicast forwarding table internally. For a flowchart of the IGMP snooping configuration for the ring cluster in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in this embodiment of the invention, please refer to [link to relevant documentation]. Figure 6 .

[0093] Specifically, the process of obtaining the mapping table between IP multicast service frames and destination ports by applying a modified IGMP snooping configuration to a ring cluster can include:

[0094] S51 allows you to select any one switch in the ring cluster and send a normal group query request through the CPU of the selected switch.

[0095] S52, after receiving the normal group query request, the selected switch's hardware FPGA board frames the normal group query message and sends the framed normal group query message to all ports;

[0096] S53: After receiving a normal group query message after framing, the user-side device supporting the IGMP protocol generates a group addition message in response and sends it to all switches. The group addition message includes the IP multicast address of the user-side device supporting the IGMP protocol. The switch receives the group addition message and sends it to its own CPU. Its own CPU parses the group addition message, extracts the IP multicast address in the group addition message, and forms a mapping table between the IP multicast address in the group addition message and the port where it is located.

[0097] It is important to note that regardless of which switch in the cluster is selected to send the normal group query request, the normal group query message can reach all ports in the cluster. Furthermore, due to the configuration of the aggregation group, the peer link will not transmit the normal group query message, thus preventing broadcast storms in the ring cluster.

[0098] Specifically for S6, when a switch in a ring cluster receives an IP multicast service frame, it queries the mapping table to find the destination port and forwards the IP multicast service frame to the destination port. This process of forwarding IP multicast services within the ring cluster can include:

[0099] S61, after receiving an IP multicast service frame, the switch in the ring cluster resolves the IP multicast address in the IP multicast service frame.

[0100] S62, based on the parsed IP multicast address, query the mapping table to obtain the corresponding destination port;

[0101] S63 sends the received IP multicast service frames to the corresponding destination port; and forwards the received IP multicast service frames to the two adjacent switches through the inter-machine interconnection port.

[0102] Another noteworthy point is that the group addition message from the user terminal device only needs to be uploaded to its directly connected switch. The switch receiving the group addition message sends it to the CPU, storing it in its own hardware FPGA board. Simultaneously, the CPU selectively sends the group addition message to the inter-device interconnect port, ensuring that all switches in the cluster receive the message. In practical applications, the storage resources required for this entry are extremely high, especially when the switch has a multi-bus processing structure. This embodiment of the invention sets up such an entry for each bus to ensure query efficiency. Because the storage resources of switches implemented using FPGAs are extremely limited, using the method provided in this embodiment to set up the cluster allows for entry distribution when large-scale IP multicast services arrive, thus significantly reducing the storage pressure on each switch in the cluster.

[0103] Ring switch clusters offer high reliability, allowing forwarding to continue via alternative paths even after a link failure. They effectively address user-side link failures, inter-device link failures, and network-side link failures.

[0104] For a schematic diagram illustrating the data flow forwarding during user-side link failures in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in this embodiment of the invention, please refer to [link to relevant documentation]. Figure 7 User-side link failure refers to a situation where a user-end device connects to two switches within an aggregation group via dual-homed access, resulting in... Figure 7 Taking user device 1 as an example, after configuration, the link to port 3 of switch 1 and the link to port 3 of switch 2 are equivalent for user device 1. The two links serve as backups for each other, enabling load balancing for user device 1. The blue arrow represents user device 1 sending data to user device 3 on the network side. When the port 3 link of switch 1 fails, the data can still enter the ring switch cluster via its backup link, namely port 3 of switch 2, and be forwarded to user device 3 via switch 2—switch 4—switch 3. The red arrow represents data traffic from the network side. After reaching switch 1, due to the link failure at port 3 of switch 1, the peer_link forwarding restriction can be released, allowing the data to reach switch 2 in the same group via the peer_link, and then be sent to user device 1 via port 3 of switch 2. This design significantly improves the high reliability of the ring switch cluster.

[0105] A schematic diagram illustrating data flow forwarding during inter-machine link failures in a Layer 2 ring reliable switch cluster method for large-scale IP multicast services provided in this embodiment of the invention is available in the following diagram: Figure 8 Inter-machine link failure refers to a disruption in transmission caused by damage to the inter-machine link in a ring network. Figure 8 Taking the link between switch 1 and switch 3 as an example, the blue arrow still represents the data flow sent from user-side device 1 to network-side user-side device 3. Due to the ring-shaped cluster structure, the failure of the inter-machine link of one switch will not affect data forwarding. The data can be routed through switch 2—switch 4—switch 3 and forwarded to user-side device 3. It is worth noting that user-side device 1 has load balancing, meaning that different loads are transmitted on the two equal-cost aggregated links. When there is an inter-machine link failure, the data cannot be directly forwarded to switch 3 after arriving at switch 1. At this time, the forwarding restriction of peer_link can be released, and the data can reach switch 2, which is in the same group as it, and then be forwarded to user-side device 3 via switch 2—switch 4—switch 3. The red arrow represents the data traffic coming from the network side. After arriving at switch 3, the data cannot be directly transmitted to switch 1 through the shortest path due to the inter-machine link failure, but it can still be routed through switch 3—switch 4—switch 2 to reach user-side device 1.

[0106] For a data flow forwarding diagram illustrating a Layer 2 ring reliable switch cluster method for large-scale IP multicast services in an embodiment of this invention, please refer to [link to relevant documentation]. Figure 9 Network-side link failure refers to a disruption in the link between the ordinary switches used for accessing network devices on the network side of a ring switch cluster and the network devices themselves. Figure 9 Taking the link between port 4 of switch 3 and the network device as an example, the diagram shows that this ring cluster has two ordinary switches, meaning there are two links connecting to the network device: the link between port 4 of switch 3 and the network device, and the link between port 4 of switch 4 and the network device. The blue arrow represents the data flow from user device 1 to the network device. When the data flow reaches switch 3, it cannot enter the network device due to a network link failure, but it can still be sent to the network device via the other link connected to the network device, passing through switch 4. The red arrow represents the data flow from the network side. The same principle applies to the data flow arriving from the network side; when one network access link fails, the data flow can still be sent to the ring switch cluster via the other network access link, and finally reach user device 1 through forwarding.

[0107] In summary, the ring switch cluster provided in this embodiment of the invention consists of four switches. Two switches are located on the user side and aggregated into a single switch to ensure reliable access for user data. The remaining two ordinary switches are located on the network side, providing two links for network-end devices, ensuring reliable access for these devices, and also allowing user-end devices with lower reliability requirements to enter the cluster. The ring structure of the four switches further ensures the reliability of inter-device links within the ring cluster. While ensuring the scale of access devices, the flexible coordination of these three mechanisms achieves high system link reliability and bandwidth. The switches in the cluster cooperate with each other to complete Layer 2 forwarding of large-scale IP multicast services.

[0108] Compared with the prior art, the embodiments of the present invention have the following advantages:

[0109] (1) The cluster structure consisting of 4 switches has a larger access scale and supports more end devices than ordinary switches. In addition, switches can still be added in the cluster model to enhance scalability.

[0110] (2) With limited FPGA resources, it can maintain a large number of forwarding table entries in the cluster, which improves the forwarding capability and processing speed of IP multicast services;

[0111] (3) When one link of the user-side device fails, the aggregation switch selects the remaining links for forwarding. The two switches in the aggregation switch are redundant to each other, which improves the reliability and redundancy of the device.

[0112] (4) Using a ring cluster design, switches 3 and 4 are connected to the network side respectively. When one of the inter-machine links of the switches or the network side link fails, the forwarding of information is guaranteed, thereby achieving high reliability and load balancing.

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

Claims

1. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services, characterized in that, include: Switches 1, 2, 3, and 4 are interconnected to form a ring network, thus creating a ring cluster. The adjacent switches 1 and 2 are configured as a single aggregation switch; the aggregation switch is used to access user terminal equipment and equipment with special requirements; the equipment with special requirements includes equipment with high reliability and load requirements; The switches 3 and 4 are configured as ordinary switches; both switches 3 and 4 are used to access network terminal devices and user terminal devices. The ports of the aggregation switch, the switch 3, and the switch 4 are divided into inter-machine interconnection ports and ordinary terminal device access ports; A modified IGMP snooping configuration is applied to the ring cluster to obtain a mapping table of IP multicast service frames and destination ports, including: Select any one switch in the ring cluster and send a normal group query request through the CPU of the selected switch. After receiving the normal group query request, the selected switch's hardware FPGA board frames the normal group query message and sends the framed normal group query message to all ports. Upon receiving a normal group query message after framing, a user-side device supporting the IGMP protocol generates a group addition message and sends it to the switch connected to the user-side device. The group addition message includes the IP multicast address of the user-side device supporting the IGMP protocol. The switch connected to the user-side device receives the group addition message and sends it to its own CPU. The CPU parses the group addition message, extracts the IP multicast address from the group addition message, and forms a mapping table between the IP multicast address in the group addition message and its port. When a switch in the ring cluster receives an IP multicast service frame, it finds the destination port corresponding to the IP multicast service frame it received according to the mapping table, sends the IP multicast service frame to the corresponding destination port, and forwards the IP multicast service frame to the adjacent switch, thereby realizing Layer 2 forwarding of IP multicast services.

2. The method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 1, characterized in that, The CPUs of switch 1 and switch 2 are configured with aggregation group information; the aggregation group information includes: group number and priority information; the group number is the identity identifier in the aggregation group formed by switch 1 and switch 2; the priority information indicates the priority of the switch operation.

3. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 2, characterized in that, The step of configuring adjacent switches 1 and 2 into a single aggregation switch includes: The aggregation group information is configured by the CPUs of switch 1 and switch 2, and the aggregation group information is configured to their respective hardware FPGA boards via PIO; The hardware FPGA boards of switch 1 and switch 2 encapsulate the received aggregate group information after configuration and broadcast it as an aggregate group hello message on their local ports to send their own aggregate group hello message to their adjacent switches. When an adjacent switch receives the corresponding aggregation group hello message, it checks whether it meets the preset conditions: it has an aggregation group number that is the same as the aggregation group number in the received aggregation group hello message. If it meets the conditions, it determines that the group of switches that send and receive the aggregation group hello message is a pair of switches to be paired. The ports of the switches to be paired that are responsible for sending and receiving aggregation group hello messages are connected to each other to form an intra-group interconnection port, thus forming an aggregation switch. While completing the aggregation, the switch receiving the corresponding aggregation group hello message compares the priority information in the received aggregation group hello message with its own priority information to confirm the master device and the slave device.

4. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 3, characterized in that, The switch receiving the corresponding aggregation group hello message compares the priority information in the corresponding aggregation group hello message with its own priority information to confirm the master and slave devices, including: The switch receiving the aggregation group hello message determines whether the priority information in the received aggregation group hello message is greater than its own priority information; If so, the switch that sends the aggregation group hello message is determined to be the master device, and the switch that receives the aggregation group hello message is the slave device; If not, the switch receiving the aggregation group hello message is determined to be the master device, and the switch sending the aggregation group hello message is determined to be the slave device.

5. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 4, characterized in that, The interconnection ports within the group are peer link links.

6. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 5, characterized in that, The port division mode of the aggregation switch, the switch 3, and the switch 4 into inter-machine interconnection ports and ordinary terminal device access ports includes: Manual partitioning mode and automatic partitioning recognition mode.

7. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 6, characterized in that, The working process of the manual partitioning mode includes: After receiving the user's configuration command, the CPU of the current switch sends the inter-machine interconnection port number of the current switch to the hardware FPGA board of the current switch, and the hardware FPGA board of the current switch performs maintenance.

8. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 7, characterized in that, The automatic identification and segmentation pattern working process includes: The CPU of the current switch sends a port discovery command to its own hardware FPGA board. After sensing the port discovery command, the hardware FPGA board performs framing. The information after framing includes its own switch number. The current switch forwards the information after framing in the form of broadcast. When a switch receives a framed message containing a number other than its own, the port that received the framed message is designated as an inter-device interconnection port, and the remaining ports are designated as ordinary terminal device access ports. When the network access environment changes, the ports are reassigned.

9. A method for a Layer 2 ring reliable switch cluster for large-scale IP multicast services according to claim 8, characterized in that, When a switch in the ring cluster receives an IP multicast service frame, it queries the mapping table to find the destination port and forwards the IP multicast service frame to the destination port. This process of forwarding IP multicast services by the ring cluster includes: After receiving the IP multicast service frame, the switches in the ring cluster parse out the IP multicast address in the IP multicast service frame, query the mapping table according to the parsed IP multicast address to obtain the corresponding destination port, send the received IP multicast service frame to the corresponding destination port, and forward the received IP multicast service frame to the two adjacent switches through the inter-machine interconnection port.

Images