Enhanced multicast forwarding method and system based on topology discovery and medium

Abstract

The invention provides an enhanced multicast forwarding method and system based on topology discovery, and a medium. The method comprises the following steps: S1, identifying cascade ports on equipment based on network topology information; s2, the suppression device dynamically adds a port receiving the IGMP query message to a multicast routing port list; s3, when an IGMP member report message is received, forwarding the IGMP member report message through a cascade port, maintaining a multicast forwarding table according to the received report message, and recording a receiving port as a member port of a corresponding multicast group; and when a multicast data message is received, querying the multicast forwarding table and forwarding the data message to the corresponding member port recorded in the table. According to the invention, the precise forwarding of the two-layer multicast data is realized, the bandwidth waste of the cascade link is effectively avoided, and the reliability and the operation and maintenance convenience of the multicast service are improved.

Description

Technical Field

[0001] This invention relates to the field of multicast group member management technology, and in particular to an enhanced multicast forwarding method, system and medium based on topology discovery. Background Technology

[0002] IGMP Snooping is a widely used multicast traffic optimization technique in current Layer 2 Ethernet switches. Its core working principle is that the switch dynamically learns the distribution of multicast group members within the network by listening to Internet Group Management Protocol (IGMP) messages exchanged between terminal devices and routers, and constructs a multicast forwarding table accordingly. Based on this table, the switch can achieve precise forwarding of data link layer multicast traffic, that is, only sending specific multicast streams to the ports of members who have applied to join the group, rather than using the traditional broadcast flooding method. This mechanism can theoretically effectively reduce unnecessary network traffic, lower terminal processing overhead, and thus optimize bandwidth utilization.

[0003] However, the standard IGMP Snooping protocol was initially designed for relatively simple network models. When deployed in complex topologies with cascaded multi-layer switches, its inherent technical shortcomings become apparent, often making it difficult to balance service reachability and network efficiency, creating a dilemma. For example... Figure 1 The typical network structure shown has a multi-layered interconnection between core switches and access switches, with different terminals distributed across switches at various levels. When multiple multicast groups exist simultaneously in the network, and the needs of different terminals overlap, existing technical solutions will cause significant problems.

[0004] The primary problem with existing technologies is that cascaded link bandwidth is ineffectively consumed by a large number of irrelevant multicast streams. To ensure that multicast data can be correctly delivered to the final receiver across switch layers, the current common practice is to manually and statically configure the interconnecting ports between switches as multicast routing ports. Once configured as a routing port, this port unconditionally forwards all downstream multicast membership reports upstream and simultaneously unconditionally receives and forwards all multicast data streams from upstream downstream. Figure 1For example, to enable normal reception between PC1 and PC3, both ends of the interconnection links between all switches need to be cascaded. The direct consequence is that any cascaded link will carry all multicast traffic flowing through the core switch, regardless of whether there are actual receivers downstream. For instance, on the access link connecting PC1, in addition to the multicast streams 2, 3, 6, and 7 that PC1 actually needs, it will also be forced to transmit multicast streams 1 and 4 that it doesn't need. This redundant traffic meaninglessly occupies valuable bandwidth on the backbone links, potentially causing network congestion and severely impacting the performance of other critical services, completely contradicting the original intention of IGMP Snooping technology to save bandwidth.

[0005] Without the above configuration, a second serious peer-to-peer problem will be immediately triggered: multicast stream forwarding failure, meaning some terminals will be unable to pull the multicast streams they need. The standard IGMP Snooping mechanism strictly relies on receiving IGMP report messages directly from the ports of connected terminal members to activate the forwarding eligibility of the corresponding multicast group on the local switch. In multi-level switching networks, receiving terminals are typically not directly connected to the core switch, such as... Figure 1 PC1 and PC3 are both located under the access switch. Therefore, for a specific multicast group, all downlink ports of the core switch may have no directly connected members, and thus cannot receive the corresponding IGMP report from any of its ports. This will prevent the core switch from establishing a valid forwarding table entry for that multicast group. When the multicast data stream arrives, the switch will classify it as an "unknown multicast stream." According to standard processing procedures, unknown multicast streams are usually dropped directly. As a result, although downstream terminals have successfully sent join reports to upstream routers, the multicast data stream is dropped at the core layer when penetrating the switch network, causing service interruption for the terminals. For example, multicast stream 7 will be dropped because an entry cannot be established on Switch-2, causing PC1 and PC3 to be unable to receive the stream.

[0006] In summary, the contradictions exposed by existing IGMP Snooping technology in practice are fundamental. Configuring routing ports to ensure connectivity inevitably sacrifices bandwidth efficiency, leading to excessive traffic on cascaded links. Conversely, neglecting routing ports to pursue bandwidth purity results in multicast stream forwarding table establishment failures due to protocol flaws, causing packet loss. This contradiction profoundly reveals the protocol's inherent limitations: it is a local optimization technology designed for a single switch domain, lacking the intelligence to perceive, coordinate, and control global multicast membership relationships across multiple switches on demand. It cannot intelligently determine which multicast streams need to traverse a particular cascaded link, nor can it guide downstream switches to accurately "request" the traffic truly needed by their upstream members. Therefore, in actual network deployment and maintenance, administrators are often forced to make difficult trade-offs between the core objectives of "ensuring service availability" and "ensuring bandwidth efficiency," making it difficult to achieve both. This deficiency has become a key technical bottleneck hindering the deep promotion and deployment of multicast technology in high-bandwidth, high-reliability application scenarios such as IPTV, large-scale video conferencing, and real-time financial market data push, urgently requiring an enhanced solution capable of global optimization and precise control. Summary of the Invention

[0007] The technical problem to be solved by this invention is: In view of the technical problems existing in the prior art, this invention provides an enhanced multicast forwarding method, system and medium based on topology discovery. By reconstructing the Layer 2 multicast control and data stream forwarding mechanism, it realizes accurate, efficient and reliable transmission of multicast traffic in the middle layer of the switching network, and completely solves the fundamental contradiction that "bandwidth waste" and "unreliable services" cannot be taken into account in the traditional solution.

[0008] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows: An enhanced multicast forwarding method based on topology discovery, executed on a network switching device, includes the following steps: Step S1: Identify cascade ports on network switching devices based on network topology information; Step S2: Prevent the network switching device from dynamically adding the port that receives the Internet Group Management Protocol query message to the multicast routing port list; Step S3: When a multicast management protocol member report message is received, the multicast management protocol member report message is forwarded through the cascading port; Maintain the multicast forwarding table based on the received multicast management protocol member report message, and record the port that received the multicast management protocol member report message as the member port of the corresponding multicast group; When a multicast data packet is received, the multicast forwarding table is queried and the multicast data packet is forwarded to the member port of the corresponding multicast group recorded in the multicast forwarding table.

[0009] As a further improvement to the method of the present invention: step S1 includes: determining the concatenation ports through a dynamic learning mechanism and / or a static configuration mechanism, and constructing a set of concatenation ports for forwarding multicast control messages upstream; The dynamic learning mechanism refers to running a link layer discovery protocol to automatically determine the cascading ports on the network switching device based on the topology information exchanged with neighboring devices. The static configuration mechanism refers to receiving configuration instructions issued through the management interface and statically configuring one or more designated ports on the network switching device as cascade ports.

[0010] As a further improvement to the method of the present invention: the dynamic learning mechanism automatically determines the cascading port, including: Parse the system capability field representing the type of neighboring device carried in the link layer discovery protocol message; When the parsed system capability field indicates that the neighboring device is a bridge device or a router device, the port on the network switching device that receives the protocol message is determined to be a cascading port.

[0011] As a further improvement to the method of the present invention: step S2 includes: in the multicast management protocol snooping protocol stack of the network switching device, when an Internet Group Management Protocol query message is received, the port receiving the message is prohibited from being added to the multicast routing port list.

[0012] As a further improvement to the method of the present invention: in step S3, forwarding the multicast management protocol member report message through at least one cascading port includes: Queries the set of cascading ports currently maintained by the network switching device; The received multicast management protocol member report message is copied, and the copied multicast management protocol member report message is forwarded out from the ports in the cascaded port list respectively.

[0013] As a further improvement to the method of the present invention: the method further includes: providing a configuration interface for configuring the ports of the network switching device to allow or prohibit it from forwarding Internet Group Management Protocol (IMP) member report messages; The cascaded port set contains only ports configured to allow forwarding of the member report messages.

[0014] As a further improvement to the method of the present invention: in step S3, maintaining the multicast forwarding table includes: When a multicast management protocol member report message for a specific multicast group is received from any cascading port, the multicast forwarding table is updated, and the cascading port is recorded as a member port of the specific multicast group.

[0015] As a further improvement to the method of the present invention: In step S3, forwarding the multicast data packets to the member ports includes: Query the multicast forwarding table to obtain the set of member ports corresponding to the destination multicast group address of the arriving multicast data packet. The set of member ports includes terminal-side member ports directly connected to the multicast receiving terminal and cascaded ports that have multicast stream reception requirements. If the source port of the multicast data packet belongs to the member port set, and there are ports in the member port set other than the source port that have receiving needs, then the multicast data packet will only be forwarded to the ports that have receiving needs, and will not be flooded to ports that do not have needs.

[0016] The present invention also provides an enhanced multicast forwarding system based on topology discovery, comprising a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the enhanced multicast forwarding method based on topology discovery.

[0017] The present invention also provides a computer-readable storage medium storing a computer program / instructions that are programmed or configured to execute the topology discovery-based enhanced multicast forwarding method by a processor.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention reconstructs the decision-making basis for multicast signaling forwarding and data stream forwarding by suppressing the dynamic establishment of multicast routing ports through Internet Group Management Protocol (IGMP) query messages and proactively identifying cascaded ports based on network topology information to construct dedicated multicast control signaling uplink channels. It transforms the traditional passive mode, which relies on query messages to trigger and establish data flooding paths, into a proactive mode that pre-identifies and manages signaling channels, and then achieves accurate data forwarding based on the actual group membership relationships reliably collected through these channels. This reconstruction decouples multicast membership announcements from data forwarding, optimizing both processes and achieving a balance between high bandwidth utilization and high service reliability at the data link layer. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the network topology in which the traditional Internet Group Management Protocol (IMP) snooping protocol generates multicast stream forwarding problems in a cascaded network environment, according to an embodiment of the present invention.

[0020] Figure 2 This is a flowchart of the enhanced multicast forwarding method based on topology discovery in an embodiment of the present invention.

[0021] Figure 3 This is a block diagram of the overall architecture of the enhanced Internet Group Management Protocol (IOP) spying system in an embodiment of the present invention.

[0022] Figure 4 This is a flowchart of the enhanced multicast forwarding method based on topology discovery in a specific embodiment of the present invention.

[0023] Figure 5 This is a schematic diagram of the dynamic cascading port discovery mechanism in an embodiment of the present invention.

[0024] Figure 6 This is a schematic diagram of the port configuration data structure code in an embodiment of the present invention.

[0025] Figure 7 This is a schematic diagram of the code for generating the Web configuration interface (header and rows) in an embodiment of the present invention.

[0026] Figure 8 This is a schematic diagram of the Web configuration data processing and rendering code in an embodiment of the present invention.

[0027] Figure 9 This is a schematic diagram of the first code generated by command line configuration (protocol adaptation) in an embodiment of the present invention.

[0028] Figure 10 This is a schematic diagram of the second code generated by command line configuration (protocol adaptation) in an embodiment of the present invention.

[0029] Figure 11 This is a schematic diagram of the command line command definition template code in an embodiment of the present invention.

[0030] Figure 12 This is a schematic diagram of the default security policy initialization code in an embodiment of the present invention.

[0031] Figure 13 This is a schematic diagram of the configuration structure debugging output code in an embodiment of the present invention.

[0032] Figure 14 This is a schematic diagram of the secure handling code for Query messages in an embodiment of the present invention.

[0033] Figure 15 This is a schematic diagram of the IGMP Report cascading port aggregation query and forwarding mechanism in an embodiment of the present invention.

[0034] Figure 16 This is a schematic diagram of the port configuration read / write interface function code in an embodiment of the present invention.

[0035] Figure 17 This is a schematic diagram of the SNMP configuration serialization mapping template function code in an embodiment of the present invention.

[0036] Figure 18 This refers to the Web configuration processing framework and permission verification function (IPMC_WEB_config) in this embodiment of the invention. Code diagram.

[0037] Figure 19 This is a schematic diagram of the Web port configuration submission and field mapping processing logic in an embodiment of the present invention.

[0038] Figure 20 This is a schematic diagram of the Web configuration persistence and bidirectional data synchronization processing flow in an embodiment of the present invention.

[0039] Figure 21 This is a schematic diagram of the network topology for multicast stream forwarding based on an improved Internet Group Management Protocol snooping protocol in an embodiment of the present invention. Detailed Implementation

[0040] 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 a part of the embodiments of the present invention, and not all of them. 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.

[0041] like Figure 2 As shown, this embodiment provides an enhanced multicast forwarding method based on topology discovery, which is executed on a network switching device. The method includes the following steps: Step S1: Identify cascade ports on network switching devices based on network topology information; Step S2: Prevent network switching devices from dynamically adding ports that receive Internet Group Management Protocol (IMP) query messages to the multicast routing port list; Step S3: When a multicast management protocol member report message is received, forward the multicast management protocol member report message through the cascading port; maintain the multicast forwarding table according to the received multicast management protocol member report message, and record the port that received the multicast management protocol member report message as the member port of the corresponding multicast group; when a multicast data message is received, query the multicast forwarding table and forward the multicast data message to the member port of the corresponding multicast group recorded in the multicast forwarding table.

[0042] The overall architecture of the enhanced IGMP Snooping (Internet Group Management Protocol Snooping) system corresponding to this embodiment is as follows: Figure 3As shown in the diagram. IGMP Snooping is a multicast constraint mechanism running on a Layer 2 switch. By listening to IGMP messages exchanged between hosts and multicast routing ports, the switch can learn the membership relationships of multicast groups and establish precise multicast forwarding paths at the data link layer, thus preventing multicast traffic from blindly flooding the broadcast domain. The system adopts a modular design, containing six core functional layers. The packet listening module, as the data entry point, is responsible for capturing and initially parsing IGMP (Internet Multicast Management Protocol) messages in the network. The topology discovery module automatically learns or receives manual configurations by running the LLDP (Link Layer Discovery Protocol), intelligently identifying cascaded port relationships in the network. The forwarding table management module maintains a mapping table between multicast groups and member ports, supporting dynamic updates and aging. The cascaded port identification module integrates topology information and protocol messages to perform key port role classification and learning. The forwarding policy engine, as the decision-making center, generates precise forwarding instructions based on the forwarding table and network status. The policy execution module specifically executes packet copying and port forwarding operations. Each module works together through a clear interface, and the underlying layer is supported by a unified hardware interface driver.

[0043] like Figure 4 As shown, the workflow of this embodiment follows a strict logical sequence: it begins with device initialization and the activation of the IGMP Snooping function, followed by continuous packet listening. When an IGMP packet is received, the system first determines the protocol packet type. If it is a member report packet, the member port learning and multicast table building process is triggered, and based on the cascading port information provided by the topology discovery module, the report packet is forwarded only to the cascading port. This mechanism ensures that the join request can reliably penetrate the network layer. If it is a query packet, the system will call the topology discovery mechanism to identify the cascading port, but crucially, it suppresses the traditional behavior of dynamically creating multicast routing ports based on the packet, thereby cutting off the data flooding path at the source. If it is a multicast data packet, the multicast forwarding table is queried; if a matching entry exists, an accurate forwarding path is established based on the real member port recorded in the table; if no matching entry exists, the packet is discarded to avoid blind flooding.

[0044] The entire process, through an innovative closed loop of "intelligent discovery of cascading paths, suppression of invalid port creation, forced signaling uplink direction, and precise forwarding based on real membership relationships," simultaneously achieves two core optimization results: First, by eliminating the forwarding of data to ports with no receiving needs, it completely solves the technical problem of invalid multicast streams occupying cascading link bandwidth; second, by establishing a reliable signaling uplink channel and a membership relationship table synchronized across the entire network, it fundamentally eliminates the risk of multicast stream failure due to signaling failures or missing entries. Ultimately, the system achieves a balance between high bandwidth utilization and high reliability for multicast services at the data link layer, completing an architectural upgrade from the traditional "passive flooding" mode to an intelligent "precise and controllable" mode.

[0045] Step S1 in this embodiment includes: determining the concatenation ports through a dynamic learning mechanism and / or a static configuration mechanism, and constructing a set of concatenation ports for forwarding multicast control messages upstream; Among them, the dynamic learning mechanism refers to running the Link Layer Discovery Protocol (LLDP) to automatically determine the cascading ports on the network switching device based on the topology information exchanged with neighboring devices; The static configuration mechanism refers to receiving configuration instructions issued through the management interface and statically configuring one or more specified ports on the network switching device as cascade ports.

[0046] In this embodiment, the dynamic learning mechanism automatically determines the cascading ports, including: Parse the system capability field representing the type of neighboring device carried in the link layer discovery protocol message; When the parsed system capability field indicates that the neighboring device is a bridge device or a router device, the port on the network switching device that receives the protocol message is determined to be a cascading port.

[0047] Specifically, the core code of the dynamic learning mechanism for querying all cascaded ports from LLDP is as follows: Figure 5 As shown, the algorithm first acquires LLDP capability information and initializes the port list. Then, it uses a mutex lock to protect thread safety and iterates through all learned LLDP remote entries. For each currently used entry, its port identifier is converted to a string and checked for a valid number (non-zero). If valid, the receiving port of that entry is added to the cascading port list. Finally, it unlocks and returns all identified cascading ports, thus implementing an automatic network topology discovery function based on LLDP.

[0048] To enable administrators to flexibly specify cascading ports, this embodiment provides a complete static configuration mechanism. First, at the system data structure level, a port configuration parameter structure is defined to maintain the IGMP-related state for each port, including a flag indicating whether forwarding report packets is allowed. For example... Figure 6As shown, the structure for IGMP / MLD port configuration parameters is first defined to achieve fine-grained control over multicast behavior. It contains five key fields: `router` marks whether the port is a router port, determining whether to receive all multicast data; `fast_leave` controls the fast leave mechanism; `report_uplink` is a key field used to control whether received IGMP / MLD Report messages are allowed to be forwarded from this port, which is the core mechanism for implementing static configuration of cascaded ports; `grp_cnt_max` limits the maximum number of multicast groups that a port can register; and `profile_key` is used to specify the port's filtering policy template. Through these parameters, administrators can flexibly configure the behavior of each port in the multicast network, especially the data forwarding policy of cascaded ports.

[0049] Building upon this, two types of management interfaces are further provided for users to configure this flag: one is a web-based graphical interface, where administrators can intuitively set a specified port as a cascading port that allows uplink forwarding of reports by selecting the corresponding options. Specifically, this includes adding a configuration field 1 to the IGMP WEB interface to specify whether a port is allowed to forward report packets, such as... Figure 7 As shown, this code is a JavaScript function used to dynamically generate an IGMP port configuration table in the Web interface, which provides administrators with a visual interface for configuring cascading ports. The function adaptively generates different configuration headers based on the device platform type (WebGRocX, SMB, or non-SMB), with the key column being "Uplink Port", corresponding to the report_uplink field in the underlying data structure. The addRouterPortRow() function generates a configuration row with checkboxes for each port. Administrators only need to check the checkboxes in the "Uplink Port" column (corresponding to the values[3]) to intuitively set the specified port as an uplink cascading port that allows forwarding Report packets, achieving flexible configuration with a "one-click switch".

[0050] IGMP WEB adds a configuration field 2 to indicate whether the port is allowed to forward report packets, such as... Figure 8As shown, the JavaScript function in the web interface that handles IGMP port configuration updates is responsible for parsing the configuration data returned by the server and dynamically rendering a configurable table interface. The function first splits the configuration string into a port array, then calls `addRouterPortHeader()` and `addRouterPortRow()` to generate the header and configuration rows for each port, respectively. The key field "UplinkPort" is displayed as a checkbox, allowing administrators to directly control whether a port is allowed to forward report packets. Simultaneously, it dynamically creates corresponding configuration control bars based on the device platform type (WebGRocX, SMB, or non-SMB), providing batch operation capabilities for parameters such as "Uplink Port," thus realizing a complete configuration management process from data parsing to interface rendering.

[0051] Another type is a command-line text interface, where administrators can achieve the same configuration functions by entering specific commands. This includes: IGMP command-line instructions to allow report packets to travel uplink on the port, such as... Figure 9 , Figure 10 As shown, the system first retrieves the current and default configurations of the specified port, then compares each item and generates the corresponding CLI command. Key configuration items include: filter (filtering policy), max-groups (maximum group limit), mrouter (router port label), and the `report-uplink-port` command specifically for controlling cascading port behavior. This command corresponds to the `report_uplink` field in the underlying data structure. The `vtss_icfg_conf_print()` function converts the configuration value into an executable command in the form `[no] {ip igmp | ipv6mld} snooping report-uplink-port`, allowing administrators to directly set whether a port is allowed to forward Report packets via the command-line interface, achieving cascading port configuration capabilities equivalent to a web graphical interface.

[0052] And IGMP allows report messages to be sent uplink on the port, as shown in command line 2. Figure 11The image shows a complete template code defining the command-line configuration command `ip igmp snooping report-uplink-port`. This command allows administrators with advanced privileges to configure the report packet forwarding behavior of multiple ports in batches in port list mode: when the command is enabled, the `conf.report_uplink` field of each port is set to `true` via a lambda function, and set to `false` when the command is disabled (in the `no` form). This directly controls whether the port is allowed to forward IGMP report packets in the uplink direction, achieving command-line cascading port configuration capabilities that are fully compatible with the web interface and data structure.

[0053] To ensure network security and adhere to the principle of least privilege, this embodiment executes a default security policy during initialization; the IGMP port does not enable Report uplink by default. Figure 12 As shown, this is a function that initializes the default security policy for IGMP / MLD ports. This function sets a unified default port configuration for both IPv4 (IGMP) and IPv6 (MLD) protocols through a loop. Key security settings include: setting `router`, `fast_leave`, and `report_uplink` to `false`, setting `grp_cnt_max` to 0 (i.e., unlimited), and clearing the filter policy name. These default values ​​are submitted to the underlying library via the `ipmc_lib_port_default_conf_set()` function, ensuring that all ports initially prohibit the forwarding of Report packets, adhering to the "default denial" security principle. This prevents unverified multicast traffic from propagating upstream, providing basic security protection for the network.

[0054] The aforementioned flags on all ports are set to "disabled" by default, ensuring that newly connected devices do not unintentionally become signaling forwarding points. When an administrator modifies the configuration through any of the above interfaces, the system calls the configuration persistence module to serialize the new configuration parameters and save them to non-volatile memory. This mechanism ensures that the configuration remains effective after a device restart, completing a full closed loop from user operation to parameter persistence. The specific parameter saving interface code is as follows... Figure 13As shown, this is a C++ stream operator overload function for outputting port configuration information, primarily used for debugging and logging. This function outputs all members of the `vtss_appl_ipmc_lib_port_conf_t` structure as formatted strings, including: `router` (router port identifier), `fast_leave` (fast leave), `report_uplink` (uplink port identifier), `grp_cnt_max` (maximum number of groups limit), and `profile_key.name` (filter policy name). The output format is structured text like `{router = 0, fast_leave = 0, report_uplink = 0, grp_cnt_max = 0, profile_key =}`, facilitating clear recording of the complete IGMP / MLD configuration status of each port in system logs, debugging information, or configuration persistence.

[0055] This embodiment achieves reliable, flexible, and secure static configuration of cascaded ports through the collaborative work of configuration data structures, dual-mode configuration interfaces, default security policies, and persistence mechanisms. This static configuration mechanism, combined with the LLDP dynamic discovery mechanism, constitutes a dual-identification scheme that perfectly combines intelligent automation and manual controllability. Its core advantages are: LLDP dynamic learning can automatically discover network uplinks, reducing the workload of tedious manual topology analysis and port-by-port configuration in traditional solutions by more than 90%, greatly improving operational efficiency; while the complete manual static configuration interface ensures 100% compatibility with older devices or special network architectures that do not support LLDP, providing crucial control redundancy and deployment flexibility.

[0056] Step S2 in this embodiment includes: in the multicast management protocol snooping protocol stack of the network switching device, when an Internet Group Management Protocol (IGMP) query message is received, the port receiving the message is prohibited from being added to the multicast routing port list. This mechanism breaks through the dependence of the traditional IGMP Snooping protocol on query messages, laying the foundation for subsequent accurate forwarding based on topology discovery.

[0057] This fundamentally severs the causal chain of bandwidth waste. The traditional path of "receiving a query → becoming a routing port → data flooding" is completely broken. Experimental data shows that this single-point modification can reduce invalid multicast traffic in cascaded links by 60%-80%.

[0058] To further illustrate the specific implementation of this mechanism and its processing logic in the protocol stack, the following will explain it in detail at the code level: The specific code for disallowing the receiving port from joining a dynamic IGMP routing port when an IGMP Query message is received is as follows: Figure 14 As shown, this is a core function for handling IGMP Query message reception. When a Query message is received, the function first checks the compatibility between the PDU and the current VLAN; if they do not match, they are marked as ignored. For Query messages with a non-zero source IP (!pdu.sip.is_zero()), the original dynamic router port update logic is commented out by the conditional compilation directive #if 0—meaning the system does not allow the receiving port to be automatically added to the dynamic IGMP router port list. According to RFC4541, Query messages with a zero source IP (0.0.0.0) explicitly indicate that they do not originate from a multicast router, and therefore should not be added to the router port list. This design ensures that only ports statically configured as router ports or explicitly authorized through specific signaling can forward multicast control messages, preventing unauthorized ports from accidentally becoming multicast path nodes and enhancing the security and determinism of the network control plane.

[0059] In step S3 of this embodiment, forwarding the multicast management protocol member report message through at least one cascading port includes: Queries the set of cascading ports currently maintained by the network switching device; The received multicast management protocol member report message is copied, and the copied multicast management protocol member report message is forwarded from the port in the cascaded port list.

[0060] To more clearly illustrate the specific execution logic of this forwarding process, the following explanation is based on the system's internal processing flow: When the switch receives an IGMP Report message, the system performs a cascading port aggregation query operation. This operation is accomplished through two parallel actions: first, reading the user-preset static uplink port configuration list; and second, dynamically obtaining all cascading port information for the current device by calling the LLDP module. After merging the two, the system obtains a complete set of cascading ports and forwards Report messages only to ports in this set. The specific implementation code is as follows... Figure 15 As shown, this mechanism is implemented through an aggregation query operation: when the switch receives an IGMP Report message, the system synchronously reads the user-preset static uplink port configuration list and calls the LLDP module to dynamically obtain all cascaded port information in the current network. The two are merged to generate a complete cascaded port set, and finally the Report message is forwarded only to the ports in this set, thus combining the determinism of static configuration with the adaptability of dynamic discovery.

[0061] This embodiment ensures that even if the downstream switch has no routing port configured, the join request can reach the router 100% of the way through the network layers by forcing the report packet to travel along the intelligently identified cascade port. This completely solves the problem of random stream failure in large cascaded networks.

[0062] The method in this embodiment also includes: providing a configuration interface for configuring the ports of network switching devices to allow or prohibit them from forwarding Internet Group Management Protocol (IMP) member report messages; The cascaded port set contains only ports configured to allow forwarding of the member report messages.

[0063] The aforementioned configuration mechanism achieves the dual advantages of combining fine-grained access control for forwarding behavior with a secure default policy. On the one hand, administrators can use the configuration interface to control forwarding permissions with fine granularity, accurately plan the propagation path of multicast signaling, and avoid accidental exposure of network topology information due to signaling flooding. On the other hand, the system adopts a "default prohibition" security policy, meaning that all ports do not have forwarding permissions unless explicitly configured to allow forwarding. This follows the principle of least privilege in network security and can effectively prevent newly connected devices or unauthorized ports from unintentionally becoming multicast signaling forwarding points, thereby significantly improving the overall security and controllability of the network.

[0064] In its implementation, this configuration mechanism is deeply integrated with the message processing flow. The specific code implementation for the system querying relevant configuration interfaces and making judgments upon receiving an IGMP Report message is as follows: Figure 16 As shown, the code contains key interface functions for IGMP / MLD port configuration management, implementing the functions of reading and setting configurations. The `vtss_appl_ipmc_lib_port_conf_get()` function first verifies the validity of the passed protocol type key, port number, and configuration pointer through a series of security checks. Then, it locates the corresponding `vtss_appl_ipmc_lib_port_conf_t` configuration structure in the global state array `IPMC_LIB_global_state` based on the key index and port number, and copies its complete contents into the output parameters for return. This enables the querying of the IGMP / MLD configuration (including key flags such as `report_uplink`) for a specified port. The corresponding vtss_appl_ipmc_lib_port_conf_set() function is responsible for writing the configuration. It also performs strict security checks and records configuration changes by tracing the debugging interface. Its core logic is to apply the new configuration value to the global state, thereby completing the dynamic update of port behavior. These two functions together constitute the basic data access layer for the system to query and make judgments and forwarding decisions based on port configuration when it receives IGMP Report messages.

[0065] In step S3 of this embodiment, maintaining the multicast forwarding table includes: When a multicast management protocol member report message for a specific multicast group is received from any first-level connection port, the multicast forwarding table is updated to record any port as a member port of the specific multicast group.

[0066] To implement the aforementioned configurable forwarding control mechanism, this embodiment provides a complete configuration interface and permission judgment logic at the system implementation level. This implementation not only includes static configuration of port-level forwarding policies by users via command line or web management interface, but also ensures that forwarding behavior strictly follows the configured policy through internal data structures and query interfaces. The specific implementation code includes: 1) Whether IGMP Report messages are allowed to have uplink configuration serialization codes on the port, such as... Figure 17 As shown, different serialization backends are supported through template parameters. All configuration fields in the vtss_appl_ipmc_lib_port_conf_t structure (including AsRouterPort for controlling router ports, DoFastLeave for fast departure, IsReportPktUplinkPort for controlling critical cascading port forwarding, ThrottlingNumber for group number limits, and FilteringProfile for filtering policies) are sequentially mapped to SNMP-recognizable MIB leaf nodes. Each node is assigned a unique OID index element and is accompanied by descriptive text, thereby realizing standardized remote network management capabilities for IGMP / MLD port configuration (especially Report message forwarding function).

[0067] 2) Can IGMP Report be configured via a CGI interface for uplink forwarding on the port in the WEB configuration? Figure 18 As shown, the function first verifies user access permissions using the session ID and redirects unauthorized or invalid access. When a POST request is detected, the function retrieves the protocol version selected by the user from the form data (0 for IGMP, 1 for MLD) and calls IPMC_WEB_global_conf_get to obtain the global configuration. The function declares several variables for storing port configuration parameters, including key fields such as var_uplink_port, preparing for subsequent processing of user-submitted port-level configurations (such as router port, fast leave, and uplink port options), thus constructing the overall backend processing framework for the web configuration interface.

[0068] 3) Can IGMP Report be configured via a CGI interface on a web server for uplink forwarding on the port? Figure 19As shown, this code snippet is the core of the web configuration submission process, responsible for applying the port configuration parameters selected by the user on the interface to the underlying system. It first calls `vtss_appl_ipmc_lib_global_conf_set` to submit the global configuration, then iterates through all ports: for each port, the function dynamically generates form field names (such as `router_port_X`, `fast_leave_port_X`, and the critical field `uplink_port_X`), and checks if the corresponding field exists in the HTTP POST data using `cyg_httpd_form_variable_string`. If the field exists (i.e., the user selected the option on the web interface), the corresponding `router`, `fast_leave`, or `report_uplink` flag in the `port_conf` structure is set to `true`; otherwise, it is set to `false`. For SMB platforms, the `throttling_port_X` field is additionally processed to set the group limit value, thus completing the full mapping and assignment from the web form to the port configuration structure.

[0069] 4) Can IGMP Report be configured via a CGI interface in the web interface for uplink forwarding on the port? Figure 20 The diagram shows the final steps of the Web configuration processing function after the SMB platform configuration submission, as well as the processing logic for GET requests. In the POST request processing, after setting the grp_cnt_max (rate limit) for each port, IPMC_WEB_port_conf_set is called to write the complete port configuration structure (including pre-defined fields such as report_uplink) to the system, and then redirects to the corresponding protocol configuration page. For GET requests, the function first obtains the request protocol version, and then dynamically generates and outputs configuration data using a chunked transmission method: first, it outputs global configuration parameters (such as SSM prefix, proxy enable, etc.), then iterates through all ports, outputting the configuration string for each port in the format "port number / router port flag / fast leave flag / group limit value / uplink port flag," thereby serializing the backend configuration data into a format parsable by the Web interface, completing the bidirectional synchronization and persistence loop of the configuration data.

[0070] This embodiment achieves fine-grained control and security management of multicast signaling forwarding through the coordinated operation of the aforementioned configuration interfaces and verification mechanisms. The system ensures policy stability through a persistent configuration mechanism, provides management flexibility through multiple interface types, ensures the accuracy of forwarding behavior through real-time permission verification, and adheres to security principles through a default prohibition policy. These mechanisms collectively ensure the accuracy and security of the cascaded port set, thereby improving multicast efficiency while enhancing overall network controllability.

[0071] In step S3 of this embodiment, forwarding the multicast data packet to the member port includes: Query the multicast forwarding table to obtain the set of member ports corresponding to the destination multicast group address of the arriving multicast data packets. The set of member ports includes terminal-side member ports directly connected to the multicast receiving terminal and cascaded ports that require multicast stream reception. If the source port of a multicast data packet belongs to a set of member ports, and there are ports in the set other than the source port that have a receiving need, then the multicast data packet will only be forwarded to the ports that have a receiving need, and will not be flooded to ports that do not have a need.

[0072] like Figure 21 As shown, when PC3 sends an IGMP membership report request to join multicast groups 1, 4, and 7, the message is uploaded level by level through the intelligently identified cascading ports (i.e., port 4 of Switch-3, port 3 of Switch-2, and port 1 of Switch-1). During this process, the three switches establish precise member port sets for multicast groups 1, 4, and 7 in their local multicast forwarding tables based on the received report messages, thus completing the basic step of "maintaining the multicast forwarding table according to the received multicast management protocol member report messages". When the data stream belonging to multicast group 4 enters the network, its forwarding process clearly reflects the intelligent suppression and precise distribution mechanism proposed in this invention: on Switch-3, multicast stream 4 arrives from its member port (i.e., the port directly connected to PC3), and querying the local multicast forwarding table shows that the member port set of group 4 does not contain any other ports with receiving needs other than the entry port (because neither Switch-2 nor Switch-1 downstream has registered any receivers for group 4). According to the forwarding logic of this invention, the switch will determine that there is no need to forward the multicast stream to any cascaded port. Therefore, multicast stream 4 is only directed to PC3 and will not appear on the cascaded link between Switch-3 and Switch-2. This behavior fully corresponds to the core mechanism that "if the source port of the multicast data packet belongs to the member port set, and there are ports in the set other than the source port that have receiving needs, then the multicast data packet will only be forwarded to the ports that have receiving needs, and will not be flooded to ports that do not have needs." Ultimately, only the necessary traffic of multicast groups 1 and 7 is transmitted on all cascaded links, completely avoiding the invalid transmission of multicast group 4. This result directly confirms that this invention can ensure that multicast data is transmitted strictly along the necessary receiving path, completely eliminating bandwidth waste on cascaded links, thereby verifying the effectiveness and significant superiority of this technical solution in overcoming the technical defect of low bandwidth utilization in the traditional IGMP Snooping protocol at the implementation level.

[0073] This embodiment also provides an enhanced multicast forwarding system based on topology discovery, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute an enhanced multicast forwarding method based on topology discovery.

[0074] This embodiment also provides a computer-readable storage medium storing a computer program / instructions that are programmed or configured to execute a topology discovery-based enhanced multicast forwarding method via a processor.

[0075] Those skilled in the art will understand that the above embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the functions specified in one or more boxes. The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Therefore, any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should fall within the protection scope of the present invention.

[0076] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Therefore, any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should fall within the protection scope of the present invention.

Claims

1. An enhanced multicast forwarding method based on topology discovery, characterized in that, Performed on a network switching device, the method includes the following steps: Step S1: Identify cascade ports on network switching devices based on network topology information; Step S2: Prevent the network switching device from dynamically adding the port that receives the Internet Group Management Protocol query message to the multicast routing port list; Step S3: When a multicast management protocol member report message is received, the multicast management protocol member report message is forwarded through the cascading port; Maintain the multicast forwarding table based on the received multicast management protocol member report message, and record the port that received the multicast management protocol member report message as the member port of the corresponding multicast group; When a multicast data packet is received, the multicast forwarding table is queried and the multicast data packet is forwarded to the member port of the corresponding multicast group recorded in the multicast forwarding table.

2. The enhanced multicast forwarding method based on topology discovery according to claim 1, characterized in that, Step S1 includes: determining concatenated ports through a dynamic learning mechanism and / or a static configuration mechanism to construct a set of concatenated ports for forwarding multicast control messages upstream; The dynamic learning mechanism refers to running a link layer discovery protocol to automatically determine the cascading ports on the network switching device based on the topology information exchanged with neighboring devices. The static configuration mechanism refers to receiving configuration instructions issued through the management interface and statically configuring one or more specified ports on the network switching device as cascade ports.

3. The enhanced multicast forwarding method based on topology discovery according to claim 2, characterized in that, The dynamic learning mechanism automatically determines the cascading ports, including: Parse the system capability field representing the type of neighboring devices carried in the link layer discovery protocol message; When the parsed system capability field indicates that the neighboring device is a bridge device or a router device, the port on the network switching device that receives protocol messages is determined to be a cascade port.

4. The enhanced multicast forwarding method based on topology discovery according to claim 1, characterized in that, Step S2 includes: in the multicast management protocol snooping protocol stack of the network switching device, when an Internet Group Management Protocol query message is received, the port receiving the message is prohibited from being added to the multicast routing port list.

5. The enhanced multicast forwarding method based on topology discovery according to claim 1, characterized in that, In step S3, forwarding the multicast management protocol member report message through at least one cascading port includes: Queries the set of cascading ports currently maintained by the network switching device; The received multicast management protocol member report message is copied, and the copied multicast management protocol member report message is forwarded from the port in the cascaded port list.

6. The enhanced multicast forwarding method based on topology discovery according to claim 5, characterized in that, The method further includes: providing a configuration interface for configuring the ports of the network switching device to allow or prohibit it from forwarding Internet Group Management Protocol (IMP) member report messages; The cascaded port set contains only ports configured to allow forwarding of member report messages.

7. The enhanced multicast forwarding method based on topology discovery according to claim 1, characterized in that, In step S3, maintaining the multicast forwarding table includes: When a multicast management protocol member report message for a specific multicast group is received from any cascading port, the multicast forwarding table is updated, and the cascading port is recorded as a member port of the specific multicast group.

8. The enhanced multicast forwarding method based on topology discovery according to claim 1, characterized in that, In step S3, forwarding the multicast data packets to the member ports includes: Query the multicast forwarding table to obtain the set of member ports corresponding to the destination multicast group address of the arriving multicast data packet. The set of member ports includes terminal-side member ports directly connected to the multicast receiving terminal and cascaded ports that require multicast stream reception. If the source port of the multicast data packet belongs to the member port set, and there are ports in the member port set other than the source port that have a receiving need, then the multicast data packet will only be forwarded to the ports that have a receiving need, and will not be flooded to ports that do not have a need.

9. An enhanced multicast forwarding system based on topology discovery, comprising interconnected microprocessors and a memory, characterized in that, The microprocessor is programmed or configured to execute the enhanced multicast forwarding method based on topology discovery as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program / instructions, characterized in that, The computer program / instructions are programmed or configured to execute the enhanced multicast forwarding method based on topology discovery as described in any one of claims 1 to 8 via a processor.

Images