Multicast group management method and device, storage medium and electronic equipment

Abstract

The invention discloses a multicast group management method and device, a storage medium and electronic equipment. The method comprises the following steps: in response to multicast source equipment, sending a multicast data stream to target equipment, obtaining an extension protocol message sent by the multicast source equipment, pausing updating of a membership of a target multicast group where the multicast source equipment is located, sending the extension protocol message to the target equipment, and receiving a membership report message returned by the target equipment, and updating the membership of the target multicast group based on the membership report message. According to the invention, the technical problem of service interruption caused by aging of multicast group membership is solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a method and device for managing a multicast group, a storage medium, and an electronic device. Background Art

[0002] In a multicast communication system, the multicast network relies on a membership management mechanism to dynamically maintain multicast group member information to ensure that data is accurately delivered to the target device. In related technologies, the multicast membership management mechanism is implemented based on the periodic interaction between the querier and the terminal device. The querier periodically sends protocol messages to trigger the terminal response, thereby updating the multicast forwarding table entries. However, when the querier fails or the network status is abnormal, the membership update mechanism will fail, causing the multicast forwarding table entries to be deleted due to timeout. At this point, even if the multicast source device continues to send data streams, the router cannot establish an effective forwarding path, which ultimately causes the multicast service to be interrupted. In other words, the related technology cannot maintain the validity of the multicast membership when the multicast group querier is unavailable. Therefore, the current multicast network urgently needs a membership maintenance mechanism that is compatible with existing protocols and does not rely on the querier status to meet the challenges of multicast service reliability in complex network environments.

[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0004] The embodiments of the present application provide a multicast group management method and apparatus, a storage medium, and an electronic device to at least solve the technical problem of service interruption caused by aging of multicast group membership.

[0005] According to one aspect of an embodiment of the present application, a method for managing a multicast group is provided, comprising: in response to a multicast source device sending a multicast data stream to a target device, obtaining an extended protocol message sent by the multicast source device, wherein the target field carried by the extended protocol message is used to instruct the target device to report multicast group membership to a routing device; pausing updating the membership of the target multicast group where the multicast source device is located, and sending the extended protocol message to the target device; receiving a membership report message returned by the target device, and updating the membership of the target multicast group based on the membership report message.

[0006] According to another aspect of an embodiment of the present application, a multicast group management device is also provided, including: an acquisition module, configured to, in response to a multicast source device sending a multicast data stream to a target device, acquire an extended protocol message sent by the multicast source device, wherein the target field carried by the extended protocol message is used to instruct the target device to report the multicast group membership to a routing device; a forwarding module, configured to suspend updating the membership of the target multicast group where the multicast source device is located, and send the extended protocol message to the target device; and a receiving module, configured to receive a membership report message returned by the target device, and update the membership of the target multicast group based on the membership report message.

[0007] In an exemplary embodiment, the apparatus is configured to obtain an extended protocol message sent by a multicast source device in response to a multicast source device sending a multicast data stream to a target device in the following manner: in response to a multicast source device sending a multicast data stream to a target device, obtain an extended protocol message sent by the multicast source device, wherein the target field represents a protocol identification field constructed by the multicast source device, and the protocol identification field is used to indicate whether to prohibit or allow triggering a state machine change of the routing device.

[0008] In an exemplary embodiment, the apparatus is further configured to: in response to a multicast source device sending a multicast data stream to a target device, obtain a first extended protocol message sent by the multicast source device, wherein a trigger field is set in a message header of the first extended protocol message, and the trigger field is used to instruct the routing device to forward the first extended protocol message to the target device and prohibit triggering a state machine change of the routing device; in response to a multicast source device sending a multicast data stream to the target device, obtain a second extended protocol message carrying a target field sent by the multicast source device, wherein the target device, the multicast source device, and the routing device all comply with the Internet Group Management Protocol, and the second extended protocol message indicates adding a control field to the end of a query message of the Internet Group Management Protocol, and the control field is used to instruct the routing device to forward the second extended protocol message to the target device and prohibit triggering a state machine change of the routing device.

[0009] In an exemplary embodiment, the device is used to suspend updating the membership of the target multicast group in which the multicast source device is located and send the extended protocol message to the target device in the following manner: parsing the route suppression flag in the target field; when the route suppression flag is in an activated state, prohibiting updating the state machine of the querier associated with the target multicast group; and sending the extended protocol message to the target device.

[0010] In an exemplary embodiment, the apparatus is further configured to: receive the membership report message returned by the target device, update the membership of the target multicast group based on the membership report message, and then receive the multicast data stream sent by the multicast source device; and send the multicast data stream to the target device.

[0011] In an exemplary embodiment, the device is used to receive a membership report message returned by the target device in the following manner, and update the membership of the target multicast group based on the membership report message: receive a membership report message returned by the target device, wherein the membership report message represents a message generated based on a revised message that complies with the protocol specification, and the revised message represents a message generated after the target device ignores the initial value of the integrity verification field preset in the message header when receiving the extended protocol message, and recalculates the integrity verification field based on the payload data of the extended protocol message; and update the membership of the target multicast group based on the membership report message.

[0012] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the multicast group management method when running.

[0013] According to another aspect of an embodiment of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the multicast group management method described above.

[0014] According to another aspect of the embodiments of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the multicast group management method through the computer program.

[0015] In an embodiment of the present application, a technical means is adopted in which a multicast source device actively generates an extended protocol message carrying a trigger identifier. By embedding a target field in the protocol message to instruct the terminal device to execute an operation mechanism for reporting membership, the purpose of autonomously triggering membership updates on the multicast source side is achieved, thereby achieving the technical effect of maintaining the validity of membership relationships in the multicast network even in a querier failure scenario.

[0016] Specifically, by extending the target field of the protocol message, the state machine update behavior of the routing device is dynamically controlled, so that the routing device suspends the aging time of the target multicast group membership after receiving the message, avoiding the problem of accidental deletion of table entries due to querier failure; at the same time, the reverse feedback mechanism of automatically generating a membership report message after the terminal device parses the target field ensures that the routing device can rebuild the forwarding path based on the latest reported information, effectively solving the risk of multicast traffic interruption.

[0017] Furthermore, by embedding the trigger identifier into the protocol message header or extended control field, this method is compatible with different versions of the multicast protocol standard, enabling functional expansion without modifying the existing multicast network architecture. This reduces equipment modification costs and improves the solution's universality. Furthermore, through an exception handling mechanism that dynamically calculates the integrity verification field of the protocol message, the compatibility of extended protocol messages in cross-vendor devices is ensured, preventing message discards due to verification failures and enhancing the robustness of the multicast membership update process.

[0018] Ultimately, this embodiment reconstructs the collaborative processing logic of multicast source devices, routing devices, and terminal devices to form a closed-loop membership maintenance mechanism. While ensuring zero interruption of multicast services, it maintains seamless compatibility with traditional multicast protocols, providing a feasible technical path for improving the reliability of large-scale multicast networks.

[0019] Therefore, the present application can solve the technical problem of service interruption caused by aging of multicast group membership. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0021] Figure 1 is a schematic diagram of an application environment of an optional multicast group management method according to an embodiment of the present application;

[0022] Figure 2 1 is a flow chart of an optional multicast group management method according to an embodiment of the present application;

[0023] Figure 3 is a schematic diagram of an optional multicast group management method according to an embodiment of the present application;

[0024] Figure 4 is a schematic diagram of another optional multicast group management method according to an embodiment of the present application;

[0025] Figure 5is a schematic diagram of another optional multicast group management method according to an embodiment of the present application;

[0026] Figure 6 It is a structural diagram of an optional multicast group management device according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0030] IGMP Protocol: The Internet Group Management Protocol (IGMP) is a multicast protocol in the Internet Protocol family. It runs between hosts and multicast routers. There are three versions of IGMP: IGMPv1, v2, and v3.

[0031] In multicast communications, the multicast network needs to send multicast data to specific multicast group members. Therefore, the multicast network needs to know the location of the multicast group members and the multicast groups they have joined. Using the IGMP protocol, members can send a message to the multicast network to join the multicast group, allowing the multicast network to detect the location of the group members and the multicast groups they have joined.

[0032] IGMPv1 primarily manages multicast group membership based on a query and response mechanism. IGMPv2, while maintaining compatibility with and inheriting IGMPv1, adds a mechanism for leaving a multicast group. The IGMP querier periodically multicasts IGMP query messages to all hosts and devices on the local network segment. After receiving the query message, Host1 first multicasts an IGMP membership report message to announce its membership in the G multicast group. Because all hosts and devices on the local network segment can receive the report message sent by Host1 to G, other hosts will no longer send the same report message to G after receiving it. The IGMP device already knows that there are hosts interested in G on the local network segment. This mechanism, called IGMP membership report suppression on hosts, helps reduce traffic on the local network segment. In IGMPv2, when a host leaves a multicast group, it sends a Leave Multicast Group message to all multicast devices on the local network segment. Upon receiving this message, the IGMP querier sends a Group-Specific Query message to the multicast group that the host announced it was leaving. If there are other members of the multicast group on the network segment, these members will send Membership Report messages within the maximum response time specified in the Group-Specific Query message. If the IGMP querier receives a Membership Report message from another member within the maximum response time, it will resume maintaining the multicast group membership. Otherwise, the IGMP querier assumes that there are no more members of the multicast group on the network segment and ceases to maintain the multicast group membership. If the IGMP querier on a multicast network does not periodically send IGMP Query messages to maintain multicast group membership, multicast group membership will age, multicast traffic will not be forwarded, and multicast services will fail, reducing network reliability.

[0033] To improve the reliability of multicast services, a method is proposed to trigger multicast group membership joining through a multicast source device. After the multicast group membership ages, the multicast source triggers the multicast group members to rejoin the multicast group, ensuring the normal operation of the multicast service without affecting the availability of the multicast network.

[0034] The present application will be described below with reference to the following embodiments:

[0035] According to one aspect of an embodiment of the present application, a method for managing a multicast group is provided. Optionally, in this embodiment, the multicast group management method can be applied to: Figure 1 In the hardware environment composed of the server 101 and the terminal device 103 shown in FIG. Figure 1As shown, the server 101 is connected to the terminal device 103 via a network and can be used to provide services for the terminal device or the application 107 installed on the terminal device. The application can be a video application, instant messaging application, browser application, educational application, game application, etc. A database 105 may be set up on the server or independently of the server to provide data storage services for the server 101, for example, a game data storage server. The above-mentioned network may include but is not limited to: a wired network, a wireless network, wherein the wired network includes: a local area network, a metropolitan area network and a wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that realize wireless communication. The terminal device 103 may be a terminal configured with an application, and may include but is not limited to at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop computer, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal and other computer devices. The above-mentioned server may be a single server, a server cluster consisting of multiple servers, or a cloud server.

[0036] Combine Figure 1 As shown, the multicast group management method can be executed by an electronic device, which can be a terminal device or a server. The multicast group management method can be implemented by the terminal device or the server separately, or by the terminal device and the server together.

[0037] The above is only an example and is not specifically limited in this embodiment.

[0038] Alternatively, as an optional implementation, Figure 2 As shown, the above multicast group management method includes:

[0039] S202: In response to the multicast source device sending a multicast data stream to the target device, obtaining an extended protocol message sent by the multicast source device, wherein the target field carried in the extended protocol message is used to instruct the target device to report multicast group membership to the routing device;

[0040] S204, suspending updating the membership of the target multicast group where the multicast source device is located, and sending an extended protocol message to the target device;

[0041] S206: Receive a membership report message returned by the target device, and update the membership of the target multicast group based on the membership report message.

[0042] Optionally, in an embodiment of the present application, the above-mentioned extended protocol message may include but is not limited to field extensions or newly added message types based on the existing IGMP protocol message format. Specifically, the extended protocol message is a protocol message formed by introducing a new message type (such as a Hello message) within the IGMP protocol framework or adding an extended field to an existing query message (such as a general group query message). The core function of this message is to carry specific control information (such as a flag that triggers a terminal response, a maximum response time parameter, etc.), which is used to instruct routing devices and terminal devices in the multicast network to perform preset behaviors. For example, the newly added Hello message type may contain fields such as a source address list and a suppression flag, while the extended field may include a protocol version identifier, a trigger mode selection bit, etc. The design of this message must meet the compatibility requirements with the existing IGMP protocol, and it can not only transmit control instructions between devices that support new features, but also be normally forwarded or ignored in traditional devices.

[0043] It should be noted that there are multiple implementation dimensions for the generation of extended protocol messages: in the trigger condition dimension, it can be a periodic timed trigger (such as sending every 60 seconds), an event-driven immediate trigger (such as detecting a multicast traffic interruption) or a manual trigger of human intervention (such as initiation by operation and maintenance personnel through CLI commands); in the field design dimension, a fixed-length flag bit combination (such as a 1-byte control field), a variable-length TLV structure (type-length-value) or a bitmap encoding method (such as a 32-bit mask to represent multiple multicast group states) can be used; in the encapsulation dimension, you can choose to carry it directly at the IP layer (such as protocol number 2), encapsulate it in a UDP tunnel (such as specifying a destination port number) or as an application layer protocol extension (such as HTTP / 2 frame type extension). This application does not make specific restrictions on this.

[0044] Optionally, in an embodiment of the present application, the above-mentioned target field may include but is not limited to a data unit in the protocol message used to carry control information that triggers the response behavior of the terminal device. Specifically, the target field may be expressed as a specific bit combination of the protocol header (such as a 1-byte "Hello" flag), a status identifier in the extension field (such as a 3-bit trigger mode code), or metadata in the payload part (such as a multicast group address mapping table). For example, in the extended IGMP query message, when the "Hello" field takes a value of 1, it indicates that the terminal device is required to respond to the membership report immediately, and when the value is 0, it is processed according to the standard protocol. The design of this field must follow the principle of protocol extensibility, and achieve synchronization of the interaction logic between devices through predefined coding rules, while retaining the flexibility of future upgrades.

[0045] Optionally, in an embodiment of the present application, the above-mentioned membership report message may include but is not limited to a multicast group join declaration message generated after the terminal device responds to a protocol message trigger. The message may follow the IGMPv2 / v3 standard format and include core parameters such as the multicast group address, source address filtering mode (INCLUDE / EXCLUDE), and maximum response time. When the terminal device receives the extended protocol message, it will generate a report message containing the current multicast group subscription status within a specified time window based on the indication content of the target field. For example, in a specific scenario, the terminal may use a suppression mechanism to only allow the first device to send a report, or dynamically adjust the response frequency according to the network load. The timely generation and delivery of the message is a key link in maintaining the validity of the multicast group membership table entry.

[0046] It should be noted that the membership update mechanism can be flexibly configured according to the network environment: in the update trigger dimension, a strict timeliness strategy (update immediately after receiving the first report), a batch processing strategy (wait for the maximum response time window to close and then update uniformly) or an incremental update strategy (only refresh the changed part) can be adopted; in the state synchronization dimension, it can support two-way synchronization of master and backup routers, cluster synchronization based on distributed databases or centralized management and control of SDN controllers; in the exception handling dimension, a retransmission mechanism (automatic retry when the report message is lost), a conflict resolution algorithm (priority determination when multiple devices report at the same time) or a degraded fault tolerance mode (maintaining historical entries when some devices do not respond) can be set. This application does not make specific restrictions on this.

[0047] For example, when the multicast source device starts data stream transmission, it first constructs an extended protocol message carrying the target field. The message generation process includes protocol version detection (automatically selecting the v2 or v3 extended format), multicast group address mapping (converting the service flow target address to the corresponding control message group address), and field padding (setting parameters such as the Hello flag and maximum response time). When receiving the message, the routing device will perform a message validity check, including checksum verification, protocol version compatibility check, and target field parsing, to ensure that only legitimate messages are forwarded to downstream terminal devices.

[0048] Then, during the membership update suspension phase, the routing device enters a temporary state-holding mode: First, it freezes the target multicast group's timer to prevent entry aging due to querier failure; second, it activates the lightweight forwarding engine to perform topology-aware routing decisions (such as selecting the optimal forwarding interface), traffic shaping (such as limiting the bandwidth usage of protocol packets), and priority marking (such as setting the DSCP differential services code point) on extended protocol packets. This dual mechanism prevents network oscillations while ensuring efficient transmission of control packets.

[0049] Finally, after parsing the destination field of the extended protocol message, the terminal device triggers a rapid response mechanism: it first checks the local subscription status (confirming whether the multicast group membership needs to be maintained) and then generates a standard membership report message (containing all subscription source addresses of the current multicast group). After receiving these reports, the routing device uses an incremental update algorithm to refresh the forwarding table entries and reactivates the timer maintenance mechanism. This process ensures smooth recovery of multicast services, avoiding the data flow interruption caused by table loss in traditional solutions.

[0050] This application implements intelligent maintenance of multicast group membership through protocol layer extensions, offering the following advantages over existing technologies: 1) Strong compatibility, ensuring service continuity when mixed networking with new and legacy devices through standard protocol extension fields; 2) High reliability, with a dual trigger mechanism (source device proactively pushes messages + terminal device promptly responds) effectively preventing abnormal aging of entries; and 3) Optimized resource utilization, with dynamic adjustment of protocol message sending frequency and response windows to avoid inefficient consumption of network bandwidth. This solution can significantly reduce control plane overhead and service recovery time, particularly in large-scale IoT multicast scenarios.

[0051] Through the embodiments of the present application, a technical means is adopted in which a multicast source device actively generates an extended protocol message carrying a trigger identifier. By embedding a target field in the protocol message to instruct the terminal device to execute an operation mechanism for reporting membership, the purpose of autonomously triggering membership updates on the multicast source side is achieved, thereby achieving the technical effect of maintaining the validity of membership in the multicast network in the scenario of querier failure. The present application solves the technical problem of service interruption caused by aging of multicast group membership.

[0052] As an optional solution, in response to a multicast source device sending a multicast data stream to a target device, obtaining an extended protocol message sent by the multicast source device includes:

[0053] In response to a multicast source device sending a multicast data stream to a target device, an extended protocol message sent by the multicast source device is obtained, wherein the target field represents a protocol identification field constructed by the multicast source device, and the protocol identification field is used to indicate whether to prohibit or allow triggering a state machine change of the routing device.

[0054] Optionally, in an embodiment of the present application, the above-mentioned protocol identification field may include but is not limited to a set of control flags for controlling the behavior of the state machine of the routing device. Specifically, this field is a specially designed control unit in the extended protocol message, which indicates whether the routing device performs a state machine update operation when processing the message through predefined coding rules (such as a 1-bit flag, a multi-bit status code, etc.). For example, when the protocol identification field is set to "trigger disabled" mode, the routing device only performs message forwarding without updating the local multicast group membership table; when it is set to "trigger allowed" mode, it is processed according to the standard IGMP protocol process. The introduction of this field realizes controllable intervention in the traditional protocol processing process, which not only retains the compatibility of the original protocol stack, but also gives the multicast source device the ability to actively regulate the network status. Typical application scenarios include: temporarily freezing routing table item updates during the multicast service recovery phase, and implementing differentiated multicast policy execution in multi-tenant networks.

[0055] It should be noted that there are multiple scalable dimensions for the implementation of the protocol identification field: in the field position dimension, it can be located in the protocol message header (such as the reserved bit after the IGMP type field), the extension header (such as the newly added option field) or the payload specific offset (such as the control area immediately after the multicast group address); in the encoding method dimension, a binary bit mask (such as the 0th bit represents the state machine control flag), an enumeration value (such as 0x00-0xFF corresponds to different operating modes) or TLV (type-length-value) structured encoding can be used; in the trigger logic dimension, it can support unidirectional control (only prohibiting state machine updates), bidirectional negotiation (confirming the processing mode through the handshake protocol) or conditional triggering (dynamically switching the identification state according to the network load). This application does not make specific restrictions on this.

[0056] For example, the steps may include but are not limited to:

[0057] S1, trigger condition determination and protocol message generation: Before initiating multicast data stream transmission, the multicast source device performs dynamic configuration of the protocol identification field, including but not limited to analyzing the service characteristics of the target multicast group (such as real-time requirements and historical packet loss rate), selecting "trigger disable" or "trigger enable" mode based on the preset policy, and constructing an extended protocol message containing the protocol identification field, ensuring that the field encoding complies with the agreed specifications between devices.

[0058] S2, Network Transmission Optimization: Routing devices perform layered processing after receiving extended protocol packets, including but not limited to:

[0059] Protocol parsing layer: extracts protocol identification fields and verifies their legitimacy (such as checking value boundaries and compatibility flags)

[0060] Policy execution layer: switches processing modes based on field values ​​(bypassing the state machine update module when triggering is disabled)

[0061] Message forwarding layer: performs intelligent forwarding based on the multicast routing table (such as prioritizing low-latency links)

[0062] S3, terminal response coordination: The target device parses the protocol identification field and performs an adaptive response, including but not limited to generating a membership report message according to the standard process when the field indicates "trigger prohibited", dynamically adjusting the maximum response time parameter when the field contains special control instructions (such as delayed response request), and automatically selecting a compatible message encapsulation format (such as IGMPv3 over IPv6) in a heterogeneous network environment.

[0063] This application uses the fine-grained control of the protocol identification field and the flexible encoding mechanism of the protocol identification field to enable mixed networking of new and old devices. Traditional devices can ignore unknown fields and process according to standard procedures, while new devices can accurately parse control instructions. The multicast source device can dynamically switch the trigger mode according to the real-time network conditions. For example, when the link is congested, non-essential state machine updates are prohibited to reduce the control plane load. By accurately blocking the false triggering of the routing device state machine (such as querier election conflicts), service interruptions caused by abnormal refresh of multicast table entries are effectively avoided. It is particularly suitable for high-reliability multicast scenarios in 5G slicing networks.

[0064] As an optional solution, the above method further includes:

[0065] In response to a multicast source device sending a multicast data stream to a target device, obtaining a first extended protocol message sent by the multicast source device, wherein a trigger field is set in a message header of the first extended protocol message, the trigger field being used to instruct the routing device to forward the first extended protocol message to the target device and prohibit triggering a state machine change of the routing device;

[0066] In response to a multicast source device sending a multicast data stream to a target device, a second extended protocol message carrying a target field sent by the multicast source device is obtained, wherein the target device, the multicast source device and the routing device all comply with the Internet Group Management Protocol. The second extended protocol message indicates that a control field is added to the end of the query message of the Internet Group Management Protocol. The control field is used to instruct the routing device to forward the second extended protocol message to the target device and prohibit triggering a state machine change of the routing device.

[0067] Optionally, in an embodiment of the present application, the trigger field may include but is not limited to a combination of flag bits in the protocol message header for controlling the forwarding behavior of the routing device and the triggering of the state machine. This field realizes dual functions through predefined coding rules (such as a 1-bit forwarding control flag, a 2-bit state machine suppression flag, etc.): one is to instruct the routing device to only perform message forwarding operations, such as transparently transmitting the message to the downstream target device; the other is to prohibit the IGMP state machine update process inside the routing device to avoid abnormal refresh of group membership table entries caused by message processing. For example, in the reserved bits of the IGMPv3 protocol header, bits 5-6 can be defined as a trigger field, where "01" means forced transparent transmission and prohibition of state machine update, and "10" means processing according to the standard protocol. This design enables the multicast source device to accurately control the processing logic of the network device, and is suitable for emergency multicast recovery scenarios that need to bypass the conventional query mechanism.

[0068] It should be noted that there are multiple scalable dimensions for the deployment of trigger fields: in the protocol compatibility dimension, it can support differentiated embedding of IGMPv1 / v2 / v3 (such as the v1 version uses the high-order reserved bit of the Type field, and the v3 version uses additional options); in the functional control dimension, it can define multi-level triggering strategies (such as the primary trigger only prohibits state machine updates, and the advanced trigger enables traffic mirroring at the same time); in the interactive mode dimension, it can support one-way forced transparent transmission (no confirmation mechanism), two-way handshake negotiation (confirming the processing status through ACK messages) or conditional triggering (dynamically enabled based on network topology). This application does not make specific restrictions on this.

[0069] Optionally, in an embodiment of the present application, the above-mentioned control field may include but is not limited to an extended data unit attached to the end of the standard IGMP query message, which is used to carry the control signaling between the multicast source device and the routing device. This field usually adopts a TLV (type-length-value) structure or a fixed-length bitmap form, and contains forwarding policy instructions (such as specifying the forwarding interface index), a state machine suppression mark (such as a 32-bit mask identifying the multicast group to be frozen) and a priority parameter (such as a QoS level identifier). For example, when a 4-byte control field is appended to the IGMP general group query message, the first 2 bytes can define the forwarding mode (unicast redirection / multicast flooding), and the last 2 bytes define the state machine processing rules (global freeze / selective freeze). This extension method provides fine-grained control capabilities for multicast services while maintaining protocol compatibility.

[0070] It should be noted that the encapsulation design of the control field can be flexibly adjusted according to the network environment: in the structural dimension, a fixed-length field (such as an 8-byte unified format), a variable-length TLV structure (dynamically adapting to different business needs) or a hierarchical nested design (the main field defines the operation type, and the subfield carries detailed parameters); in the encoding dimension, it can support binary bit mapping (such as each bit corresponds to a multicast group control policy), ASCII string (human-readable instruction description) or encrypted data block (to ensure the security of control signaling); in the interactive logic dimension, it can support end-to-end transparent transmission (routing equipment does not parse), hop-by-hop parsing (each device extracts some fields on demand) or a mixed mode (key field transparent transmission, auxiliary field hop-by-hop processing). This application does not make specific restrictions on this.

[0071] Illustratively, the first extended protocol message processing flow may include but is not limited to the following steps:

[0072] S1, message construction and trigger field injection: Before sending the multicast data stream, the multicast source device dynamically generates the first extended protocol message, analyzes the service attributes of the target multicast group (such as real-time level and historical packet loss rate), selects the encoding mode of the trigger field according to the preset policy (such as enabling "forced transparent transmission + state machine freeze" in emergency recovery mode), inserts the trigger field into the IGMP message header, and recalculates the checksum to ensure protocol compatibility.

[0073] S2, intelligent processing by the routing device: After receiving the first extended protocol message, the routing device performs layered processing, including but not limited to:

[0074] Header parsing layer: extracts trigger fields and verifies their legitimacy (such as checking value boundaries and protocol version matching);

[0075] Policy execution layer: switches to transparent transmission mode (bypassing the IGMP state machine processing module) based on the trigger field value;

[0076] Forwarding decision layer: performs intelligent path selection based on the multicast forwarding table (such as giving priority to links with low packet loss rates).

[0077] S3, terminal device response coordination: The target device parses the trigger field and performs adaptive operations, ignores the trigger field content (compatible with traditional device scenarios), starts a fast response mechanism according to the field indication (such as shortening the maximum response time window), and generates an enhanced membership report message (carrying extended information such as device capability identification).

[0078] Illustratively, the second extended protocol message processing flow may include but is not limited to the following steps:

[0079] S1, dynamic encapsulation of control fields: When constructing the second extended protocol message, the multicast source device analyzes the topological characteristics of the target multicast group (such as the need for cross-AS transmission), generates a control field containing forwarding policies and QoS parameters (such as defining the multicast stream priority as emergency level), appends the control field to the end of the standard IGMP query message, and adopts an incremental checksum calculation strategy.

[0080] S2, Routing Device Collaborative Processing: The routing device enables collaborative processing mechanisms when processing the second extended protocol message, including but not limited to:

[0081] Control field extraction: parse the control field from the end of the message (supports dynamic segmentation of variable-length fields);

[0082] Policy mapping: converts the control field content into a local forwarding table entry (e.g., creating a temporary high-priority forwarding path);

[0083] State machine isolation: Freezes the state machine timer of the related multicast group according to the field indication.

[0084] S3, end-to-end service assurance: After receiving the second extended protocol message, the target device identifies the service parameters in the control field (such as the maximum delay requirement), adjusts the local multicast subscription policy (such as actively sending redundant report messages to improve reliability), and feeds back network status information (such as link quality indicators) to the multicast source device to form a closed-loop optimization.

[0085] This application utilizes a dual extension mechanism, utilizing the trigger field and control field design to be compatible with standard IGMP devices. Traditional devices can ignore the extended content and process it according to the standard process, while new devices can accurately parse the control instructions, achieving smooth upgrades of network devices. Multicast source devices can dynamically select the first or second extended protocol message based on the real-time network topology and service needs. For example, in cross-domain multicast scenarios, the control field is prioritized to define the path strategy, while in LAN recovery scenarios, the trigger field is used to achieve rapid response. By prohibiting unnecessary state machine update operations, the CPU computing overhead of routing devices is reduced.

[0086] As an optional solution, suspend updating the target multicast group membership of the multicast source device and send extended protocol messages to the target device, including:

[0087] Parse the route suppression flag in the target field;

[0088] When the route suppression flag is activated, updating the state machine of the querier associated with the target multicast group is prohibited;

[0089] Send an extended protocol message to the target device.

[0090] Optionally, in an embodiment of the present application, the above-mentioned route suppression flag may include but is not limited to a binary flag in the extended protocol message used to control the state machine update behavior of the routing device. The flag is defined by a preset bit (such as the 4th bit of the protocol header) to indicate whether the routing device performs a state machine update operation related to the target multicast group when processing the extended protocol message. When the flag is in an activated state (such as a binary value of 1), the routing device will freeze the group membership table maintenance process of the corresponding multicast group, including but not limited to stopping the timer refresh, pausing the querier election process, and ignoring events triggered by the membership report message; when it is in an inactivated state (such as a binary value of 0), it is processed according to the standard protocol process. For example, in the IGMPv3 extended message, the 3rd bit of the reserved field can be redefined as a route suppression flag to achieve precise control of the state machine of a specific multicast group, which is suitable for network cutover scenarios where it is necessary to temporarily maintain the stability of the multicast table entries.

[0091] It should be noted that there are multiple implementation dimensions for the activation mechanism of the routing suppression flag: in the trigger condition dimension, it can be based on time strategy (such as pre-configured time window activation), event-driven (such as detecting that the burst packet loss rate of multicast traffic exceeds the threshold) or external instructions (such as the flow table rules issued by the SDN controller); in the encoding method dimension, a single-bit switch mode (0 / 1 means disable / enable), multi-bit priority encoding (such as 2 bits for 4 levels of suppression strength) or dynamic mask mapping (32-bit mask corresponding to different multicast group suppression states) can be used; in the interactive mode dimension, it can support one-way forced activation (no confirmation mechanism), two-way negotiated activation (confirming status synchronization through ACK message) or conditional reflex activation (dynamic switching according to network load). This application does not make specific restrictions on this.

[0092] Optionally, in an embodiment of the present application, the state machine of the above-mentioned querier may include but is not limited to a core logic module that implements the IGMP protocol stack in a routing device, which is responsible for managing the discovery, maintenance and aging process of multicast group membership. The state machine drives protocol behavior through a finite state machine model (such as initial state, query state, and maintenance state), specifically including periodically sending general group query messages, processing membership report messages, and executing specific group query timeout logic. For example, in a standard IGMPv2 implementation, the querier state machine will enter a specific group query state after receiving a leave group message, and trigger the deletion of the multicast group relationship if no member report is received within the maximum response time. This proposal intervenes in the conversion logic of the state machine through the routing suppression flag to achieve temporary freezing of state migration in specific business scenarios (such as during network topology reconstruction) to avoid abnormal refresh of table entries due to protocol interaction.

[0093] It should be noted that the control strategy for the queryer state machine can be flexibly configured according to network requirements: in the policy dimension, global freezing (pausing the state machine of all multicast groups), selective freezing (only for the target multicast group) or partial function freezing (such as allowing query messages to be sent but prohibiting the processing of response messages) can be performed; in the synchronization mechanism dimension, the state mirror synchronization of the master and standby routers, cluster synchronization based on distributed databases or transactional updates based on version numbers can be used; in the exception handling dimension, timeout automatic recovery (such as automatic release after the suppression state lasts for 5 minutes), manual intervention recovery (CLI operation by operation and maintenance personnel) or gradual recovery (restarting the state machine submodule in stages) can be set. This application does not make specific restrictions on this.

[0094] For example, it may include but is not limited to the following steps:

[0095] S1, protocol message parsing and flag extraction. After receiving the extended protocol message, the routing device performs layered parsing: identifying the message type (such as IGMPv3 extended query message) and locating the storage location of the route suppression flag; verifying whether the flag value complies with the protocol specification (such as whether it is a legal Boolean value); binding the flag status with the forwarding table entry of the target multicast group to establish a control relationship.

[0096] S2, state machine operation interception. When the route suppression flag is activated, the routing device enables the state machine interception engine: suspends all timers related to the target multicast group (general query timer, specific group query timer); discards external events that trigger state machine migration (such as membership report messages and leave group messages); and allocates independent memory space for the frozen state machine to prevent resource competition with the state machines of other multicast groups.

[0097] S3, protocol message forwarding and terminal response. After completing state machine control, the routing device performs intelligent forwarding: selects the optimal forwarding path based on the network topology (such as load balancing link, low-latency path); marks the extended protocol message with a high priority queue to ensure transmission reliability; and the target device generates an enhanced response (such as a membership report carrying the device capability set) after parsing the message.

[0098] This application uses the collaborative design of the route suppression flag and the state machine control mechanism to freeze the state machine update of the target multicast group during multicast network reconstruction or equipment upgrades, thereby avoiding service interruptions caused by protocol interaction interruptions and significantly improving the availability of key multicast services (such as real-time video distribution). Suppressing unnecessary state machine operations can reduce the CPU utilization of routing devices and reduce the bandwidth consumption caused by the flooding of control plane protocol messages. It supports fine-grained multicast group-level state machine control, allowing network administrators to implement differentiated management strategies based on different service priorities (such as only freezing the state machine of high-priority multicast groups). Interoperability with traditional equipment is retained through extended field design. Traditional equipment can ignore the route suppression flag and process according to standard procedures, while new equipment can accurately execute state machine control logic.

[0099] As an optional solution, after receiving the membership report message returned by the target device and updating the membership of the target multicast group based on the membership report message, the method further includes:

[0100] Receive multicast data streams sent by multicast source devices;

[0101] Sends multicast data streams to target devices.

[0102] Optionally, in an embodiment of the present application, the above-mentioned multicast data stream may include but is not limited to a set of continuous data packets sent by a multicast source device to a specific multicast group address. The data stream complies with the multicast transmission protocol specifications (such as IP multicast address allocation rules), and contains service payloads (such as video streaming content, IoT sensor data), multicast group identification information (such as target group address, source address filtering mode) and transmission control parameters (such as TTL value, QoS tag). For example, in a video conferencing scenario, the multicast data stream may be composed of a sequence of H.264-encoded video frames, which are periodically sent through the multicast address 239.255.0.1. Its core features include: one-way transmission mode (source to group members), intelligent copy forwarding based on group membership (sent only to network branches where subscribers exist), and traffic optimization mechanism (such as dynamically adjusting the sending rate based on the network congestion status). The correct delivery of the data stream depends on the accurate maintenance of the group membership table and the real-time update of the forwarding path.

[0103] It should be noted that there are multiple implementation dimensions for constructing the transmission path of multicast data streams: in the forwarding protocol dimension, native multicast routing (such as PIM-SM protocol to build a distribution tree), unicast tunnel encapsulation (such as GRE tunnel to carry multicast messages) or application layer multicast (such as self-organizing forwarding based on overlay network) can be used; in the traffic scheduling dimension, shortest path priority (based on OSPF cost calculation), load balancing distribution (dynamic selection of low-utilization links) or policy routing (selection of transmission paths based on service priority) can be supported; in the fault tolerance mechanism dimension, redundant path backup (synchronous switching of primary and backup forwarding trees), message retransmission request (loss recovery based on NACK) or forward error correction coding (FEC enhances anti-packet loss capability) can be deployed. This application does not make specific restrictions on this.

[0104] For example, the steps may include but are not limited to:

[0105] S1, multicast data stream reception and preprocessing. After completing the group membership update, the routing device starts the multicast data stream reception engine: identifies the multicast address and source address of the data stream, and matches the updated group membership table entry; dynamically adjusts the receiving buffer size according to the network load status (such as enabling the traffic shaping window under high load); and verifies the multicast source device permissions (such as filtering illegal data streams based on the source address whitelist).

[0106] S2, intelligent forwarding decision, the routing device performs forwarding path calculation based on the latest group membership: querying the downstream interface list of subscribed members according to the target multicast group address; using dynamic routing algorithms (such as shortest path tree reconstruction based on delay measurement) to select the optimal forwarding interface; applying QoS policies (such as marking video streams with EF acceleration queues) and security rules (such as multicast access control lists).

[0107] S3, data stream distribution and monitoring, routing devices perform multicast data stream distribution and quality assurance: generate copy messages on demand at branch nodes (sent only to downstream interfaces where group members exist); collect indicators such as packet loss rate and delay jitter in real time to trigger dynamic routing adjustments (such as switching to a backup distribution tree); and enable fast rerouting mechanisms (such as millisecond-level failover based on BFD) when a link interruption is detected.

[0108] This application avoids flooding data streams to network branches without subscribers through the coordinated control of group membership and data stream distribution, based on accurately updated group membership table entries, and can reduce invalid bandwidth consumption by more than 60% in typical scenarios. By linking dynamic path optimization with QoS policies, the end-to-end transmission delay of high-priority multicast streams (such as industrial control instructions) is ensured to be stable at the millisecond level. The dual fault-tolerance mechanism (redundant path + fast rerouting) shortens the multicast service recovery time to sub-seconds in single-point failure scenarios, which is significantly better than the second-level interruption of traditional solutions. It supports hybrid transmission modes in heterogeneous network environments (such as 5G slicing networks and wired networks in collaboration) to achieve seamless connection of cross-domain multicast services.

[0109] As an optional solution, receiving a membership report message returned by the target device and updating the target multicast group membership based on the membership report message include:

[0110] receiving a membership report message returned by the target device, wherein the membership report message is a message generated based on a modified message that complies with the protocol specification, and the modified message is a message generated after the target device, when receiving an extended protocol message, ignores an initial value of an integrity verification field preset in a message header and recalculates the integrity verification field based on payload data of the extended protocol message;

[0111] Updates the membership of the target multicast group based on the membership report message.

[0112] Optionally, in an embodiment of the present application, the above-mentioned corrected message may include but is not limited to a standardized response message generated after the terminal device performs protocol compatibility adaptation on the received extended protocol message. Specifically, when the target device receives an extended protocol message carrying a special control field (such as a route suppression flag), it is necessary to perform compatibility processing of the protocol stack: first, the initial value of the integrity verification field (such as the IGMP checksum field) preset in the message header is ignored, and then the legitimacy verification code is recalculated based on the payload data (such as the multicast group address, the maximum response time parameter), and finally a membership report message that conforms to the standard protocol format is generated. For example, in a terminal device that supports IGMPv3, if a query message containing a custom extended field is received, the device will strip off the extended part and reconstruct the standard message format, and recalculate the checksum to ensure that the traditional routing device can parse it normally. This mechanism achieves seamless compatibility between new protocol extensions and existing devices, and solves the protocol interoperability problem in hybrid networking scenarios.

[0113] It should be noted that the generation logic of the corrected message can be flexibly adjusted according to the network environment: in the trigger condition dimension, it can be based on protocol version detection (correction is only enabled for versions below IGMPv3), network topology status (such as triggering correction when a traditional routing device is detected) or device capability negotiation (confirming downstream device compatibility through the LLDP protocol); in the field processing dimension, it can support partial field ignoring (only covering the checksum of the extended field), dynamic field selection (determining the check range according to the message type) or conditional coverage (recalculating only when the initial check value is illegal); in the calculation method dimension, it can be compatible with multiple check algorithms (such as CRC-32, SHA-1), segmented calculation strategies (block check for long messages) or hardware accelerated calculation (improving processing efficiency through the network card Offload engine). This application does not make specific restrictions on this.

[0114] Optionally, in an embodiment of the present application, the above-mentioned integrity verification field may include but is not limited to a checksum unit in the protocol message for ensuring the integrity of data transmission. This field is usually located at the header or tail of the message, and is filled after the message content is calculated by a specific algorithm (such as CRC cyclic redundancy check, MD5 hash), and is used by the receiving end to verify whether the message has been tampered with or damaged during transmission. For example, in the IGMPv2 protocol, the checksum field covers the entire message (from the type field to the group address field), and the receiving device needs to recalculate and compare it with this field to confirm the validity of the message. In the present application, when the target device generates the corrected message, it needs to actively ignore the initial checksum value preset in the extended protocol message, and instead regenerate the verification code based on the actual content of the payload data, so as to ensure protocol compatibility and avoid message discarding due to field tampering.

[0115] It should be noted that there are multiple ways to implement the generation mechanism of the integrity verification field: in the dimension of generation timing, it can support pre-processing generation (synchronous calculation when constructing the message), real-time calculation (streaming processing byte-by-byte update) or post-processing completion (filling the placeholder first and then asynchronous calculation); in the dimension of algorithm selection, it can configure a variety of hash algorithm libraries (such as the MD5 / SHA series provided by OpenSL), custom lightweight checks (such as XOR check) or encryption signature algorithms (such as HMAC-SHA256); in the dimension of verification scope, it can define full message coverage (including extension fields), payload-specific (only calculate the data part) or layered verification (header and payload are calculated separately). This application does not make specific restrictions on this.

[0116] Optionally, in an embodiment of the present application, the above-mentioned payload data may include but is not limited to data units in the protocol message that carry actual control instructions or business information. This part is located after the message header and contains the core parameters required for multicast group member management, such as: multicast group address, source address filter list (INCLUDE / EXCLUDE mode), maximum response time, etc. In the extended protocol message scenario, the payload data may also include custom control fields (such as routing suppression flags, QoS priority tags). For example, when the target device receives an IGMP query message carrying an extended field, the payload data not only contains standard group address information, but may also embed path selection policies or state machine control instructions. Accurate parsing and processing of this data is the key to ensuring the correct maintenance of multicast group membership.

[0117] It should be noted that there is multi-dimensional expansion space for the parsing and utilization of payload data: in the structural parsing dimension, it can support fixed-length field decoding (such as direct reading of 4-byte group addresses), dynamic parsing of TLV formats (extracting variable-length data based on type identifiers) or nested structure processing (unpacking of multi-layer encapsulation protocols); in the encoding dimension, it can process binary raw data (direct memory mapping), ASCII escape characters (such as URL encoding format) or compression encoding (such as Zlib compressed data stream); in the dynamic adjustment dimension, it can dynamically trim the payload content according to the network load (only retain key fields when the load is high), select the parsing depth based on the service priority (full parsing of high-priority multicast groups) or implement security policy filtering (automatically discarding blacklisted addresses). This application does not make specific restrictions on this.

[0118] Exemplarily, the steps include but are not limited to:

[0119] S1, protocol message correction and verification. After receiving the extended protocol message, the target device performs compatibility processing: identifying and stripping the protocol extension part (such as the custom control field), retaining the standard protocol structure; ignoring the original integrity verification field, and recalculating the checksum based on the payload data; encapsulating the multicast group membership information according to the standard protocol format, and generating a compliance report message.

[0120] S2, dynamic update of membership. The routing device receives the corrected message and performs table maintenance: it parses the multicast group address and member device identifier to locate the forwarding table entry of the target multicast group; updates the group member list (adds subscribed members, removes timed-out members) and associated parameters (such as source filtering mode); resets the group membership aging timer to extend the validity period of the entry.

[0121] S3, network status linkage optimization, performs intelligent service adjustments based on updated group membership: reconstructs the multicast distribution tree based on the latest member distribution (such as switching to a more optimal RPF path); reserves bandwidth resources for high-priority multicast groups (such as implementing QoS guarantees based on DiffServ marking); and applies multicast access control lists (ACLs) to block subscription requests from unauthorized devices.

[0122] This application uses protocol correction and dynamic verification mechanisms, and the standardized reconstruction of the corrected messages makes the new protocol extension backward compatible with traditional devices, supports seamless collaboration of IGMPv1 / v2 / v3 devices in hybrid networking scenarios, and reduces network upgrade costs. Through the double verification mechanism (ignoring the initial field + dynamic recalculation), it effectively resists message tampering attacks during transmission (such as man-in-the-middle attacks to inject forged group addresses), and improves the security of multicast services. Based on the precise analysis and local calculation of payload data, the protocol stack processing overhead is reduced (such as avoiding repeated verification of the entire message). The dynamic membership update and network status linkage mechanism ensure that the multicast distribution path always matches the real-time network topology, significantly improving the transmission stability of large-scale multicast applications (such as 4K live video).

[0123] The following is a further explanation of this application with reference to specific examples:

[0124] This application provides a method for triggering a terminal device to join a multicast group membership by sending an IGMP protocol message through a multicast source device, replacing the function of completing the failure of the IGMP querier in the multicast network, allowing multicast services to operate normally and improving network reliability.

[0125] Provides configurable parameters: multicast source sending device side / IGMP-configured router side / terminal device side that needs to receive multicast data.

[0126] Enable switch: Configure to use this application method.

[0127] Specific working principle:

[0128] The present application provides a method and apparatus for triggering multicast group membership joining through a multicast source device, wherein the method actively sends an IGMP extended protocol message through the multicast source device.

[0129] When an IGMP querier receives an IGMP extended protocol message, it does not trigger a querier election and forwards the message.

[0130] When the terminal multicast service device receives the IGMP extended protocol message, it processes it according to the original IGMP query message.

[0131] There are two implementation strategies to achieve this:

[0132] The first method is to enable a new type of IGMP protocol message, the IGMP Hello message. The format of the IGMP Hello message is as follows: Figure 3 The meaning of each field is shown in Table 1:

[0133]

[0134] Table 1

[0135] The strategy implementation modification points:

[0136] The multicast source device can flexibly construct and send IGMP Hello messages; the router can identify the IGMP Hello message and only forward it to the terminal without triggering the IGMP state machine change on the router; the multicast receiver device can identify the IGMP Hello message and reply with a multicast group membership report message when it needs to respond to the multicast membership. Among them, the IGMP Hello message acts on the target terminal to enable the target terminal to reply to the multicast group membership. On the router device it passes through, it is only forwarded without triggering the IGMP state machine change on the router.

[0137] The second method is to expand the fields in the existing IGMP query message (Extended). In the newly added extended fields, the main consideration is to determine the subsequent processing operations to be done based on the field type to prevent incorrect processing and cause protocol exceptions. The format of the message is as follows: Figure 4 The meaning of each field is shown in Table 2:

[0138]

[0139] Table 2

[0140] The 4-byte design of the Extended segment is shown in Table 3:

[0141]

[0142] Table 3

[0143] The implementation modifications of this policy are as follows: multicast source devices can flexibly construct and send extended IGMP query messages; routers can identify extended IGMP query messages and determine message processing behavior based on the information in the extended field. For example, the current extended field is intended to forward only to terminals and does not trigger changes in the IGMP state machine on the router; multicast receiver devices need to correct checksum processing to prevent routers from discarding extended IGMP messages after verification fails.

[0144] Currently, the hello field in the extended field is supported. A value of 1 indicates that the protocol message is forwarded without triggering a change in the IGMP state machine on the router, while a value of 0 indicates that the original protocol is used. For routers, this mapping relationship must be agreed upon between the multicast source device, router device, and terminal device.

[0145] Usage scenario introduction:

[0146] After the mobile phone is connected to the router's WIFI, it sends a multicast data stream, which is forwarded to the terminal device through the router to complete the multicast service. The comparison process of multicast service failure and multicast service success is as follows: Figure 5 The detailed process is as follows:

[0147] S1: Before sending a multicast data stream, the multicast source device first sends an IGMP Hello message or an extended IGMP query message to the multicast group corresponding to the multicast data.

[0148] S2: When the router receives an IGMP Hello message or an extended IGMP query message, it only needs to forward the message to the terminal device.

[0149] S3: When the multicast service device receives the IGMP Hello message or the extended IGMP query message, if it needs to receive the data stream of the multicast group, it needs to reply with a multicast group membership report message.

[0150] S4: At this time, the multicast source device sends the multicast data stream again, which can be forwarded to the multicast service device according to the multicast forwarding mechanism to complete the multicast service.

[0151] This application uses extended IGMP protocol messages (Hello messages or extended IGMP query messages), which have a wider range of applications, fewer limitations, simpler maintenance, and strong scalability. It is also compatible with all versions of IGMP. Updating multicast entries through protocol messages has a wider range of applications and stronger scalability.

[0152] In summary, this application uses the extended Hello message of IGMP or the extended normal query message of IGMP, which does not affect the multicast network and is compatible with all versions of IGMP. The method provided by this application requires the network source device and router device and the receiver device of multicast transmission to adapt the protocol message for the first time, which makes subsequent maintenance simpler and more flexible to use. This application controls the IGMP protocol message through the multicast source device, which has stronger controllability and scalability. Similar problems can be solved by reusing protocol messages, providing an operational method for solving the multicast problem of existing devices.

[0153] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0154] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0155] According to another aspect of the embodiment of the present application, a multicast group management device for implementing the above multicast group management method is also provided. Figure 6 As shown, the device includes:

[0156] An acquisition module 602 is configured to acquire, in response to a multicast source device sending a multicast data stream to a target device, an extended protocol message sent by the multicast source device, wherein the target field carried in the extended protocol message is used to instruct the target device to report multicast group membership to the routing device;

[0157] Forwarding module 604, configured to suspend updating the membership of the target multicast group where the multicast source device is located, and send an extended protocol message to the target device;

[0158] The receiving module 606 is configured to receive a membership report message returned by the target device, and update the membership of the target multicast group based on the membership report message.

[0159] As an optional solution, the above-mentioned device is used to obtain an extended protocol message sent by the multicast source device in response to the multicast source device sending a multicast data stream to the target device in the following manner: in response to the multicast source device sending a multicast data stream to the target device, obtain an extended protocol message sent by the multicast source device, wherein the target field represents a protocol identification field constructed by the multicast source device, and the protocol identification field is used to indicate whether to prohibit or allow triggering a state machine change of the routing device.

[0160] As an optional solution, the above-mentioned device is also used to: in response to a multicast source device sending a multicast data stream to a target device, obtain a first extended protocol message sent by the multicast source device, wherein a trigger field is set in the message header of the first extended protocol message, and the trigger field is used to instruct the routing device to forward the first extended protocol message to the target device and prohibit triggering a state machine change of the routing device; in response to the multicast source device sending a multicast data stream to the target device, obtain a second extended protocol message carrying a target field sent by the multicast source device, wherein the target device, the multicast source device and the routing device all comply with the Internet Group Management Protocol, and the second extended protocol message indicates that a control field is added to the end of the query message of the Internet Group Management Protocol, and the control field is used to instruct the routing device to forward the second extended protocol message to the target device and prohibit triggering a state machine change of the routing device.

[0161] As an optional solution, the above-mentioned device is used to suspend the update of the membership of the target multicast group where the multicast source device is located and send an extended protocol message to the target device in the following manner: parse the route suppression flag in the target field; when the route suppression flag is in the activated state, prohibit the update of the state machine of the querier associated with the target multicast group; send an extended protocol message to the target device.

[0162] As an optional solution, the above-mentioned device is also used to: receive a membership report message returned by the target device, update the membership of the target multicast group based on the membership report message, receive the multicast data stream sent by the multicast source device; and send the multicast data stream to the target device.

[0163] As an optional solution, the above-mentioned device is used to receive a membership report message returned by a target device in the following manner, and update the membership of the target multicast group based on the membership report message: receive a membership report message returned by the target device, wherein the membership report message represents a message generated based on a revised message that complies with the protocol specification, and the revised message represents a message generated after the target device ignores the initial value of the integrity verification field preset in the message header when receiving an extended protocol message, and recalculates the integrity verification field based on the payload data of the extended protocol message; and update the membership of the target multicast group based on the membership report message.

[0164] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0165] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0166] According to one aspect of the present application, a computer program product is provided, which includes a central processing unit (CPU), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) or a program loaded from a storage portion into a random access memory (RAM). In the random access memory, various programs and data required for system operation are also stored. The central processing unit, the read-only memory, and the random access memory are connected to each other via a bus. An input / output interface (i.e., an I / O interface) is also connected to the bus.

[0167] The following components are connected to the input / output interface: an input section including a keyboard, mouse, etc.; an output section including a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section including a hard disk; and a communication section including a network interface card such as a local area network card and a modem. The communication section performs communication processing via a network such as the Internet. A drive is also connected to the input / output interface as needed. Removable media such as magnetic disks, optical disks, magneto-optical disks, semiconductor memories, etc. are installed in the drive as needed so that computer programs read from them can be installed into the storage section as needed.

[0168] In particular, according to an embodiment of the present application, the processes described in the various method flow charts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the methods shown in the flow charts. In such an embodiment, the computer program can be downloaded and installed from a network via a communication portion, and / or installed from a removable medium. When the computer program is executed by a central processing unit, the various functions defined in the system of the present application are performed.

[0169] In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion, and / or installed from a removable medium. When the computer program is executed by the central processing unit, various functions provided by the embodiments of the present application are performed.

[0170] According to another aspect of the embodiment of the present application, an electronic device for implementing the above-mentioned multicast group management method is also provided. The electronic device may be Figure 1 The terminal device or server shown. This embodiment is described by taking the electronic device as an example of a terminal device. The electronic device includes a memory and a processor, the memory stores a computer program, and the processor is configured to execute the steps of any of the above method embodiments through the computer program.

[0171] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0172] Optionally, in this embodiment, the above-mentioned processor can be configured to execute the methods in each embodiment of the present application through a computer program.

[0173] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the multicast group management method and device in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the multicast group management method described above. The memory can include high-speed random access memory and can also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory can further include a memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0174] Optionally, the transmission device of the electronic device is used to receive or send data via a network. Specific examples of the above-mentioned network may include wired networks and wireless networks. In one embodiment, the transmission device includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and a router via a network cable so as to communicate with the Internet or a local area network. In one embodiment, the transmission device is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0175] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting multiple nodes via network communication. The nodes may form a peer-to-peer network, and any computing device, such as a server, terminal, or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0176] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the multicast group management method provided in various optional implementations of the above-mentioned multicast group management aspects.

[0177] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be configured to store data for executing the methods in various embodiments of the present application.

[0178] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing the hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0179] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0180] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above-mentioned computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing one or more electronic devices to execute all or part of the steps of the method described in each embodiment of the present application.

[0181] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0182] In the several embodiments provided in this application, it should be understood that the disclosed applications can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0183] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0184] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0185] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for managing a multicast group, characterized in that: include: In response to a multicast source device sending a multicast data stream to a target device, obtaining an extended protocol message sent by the multicast source device, wherein a target field carried in the extended protocol message is used to instruct the target device to report multicast group membership to the routing device; suspending updating the membership of the target multicast group where the multicast source device is located, and sending the extended protocol message to the target device; Receive a membership report message returned by the target device, and update the membership of the target multicast group based on the membership report message.

2. The method according to claim 1, characterized in that The step of acquiring the extended protocol message sent by the multicast source device in response to the multicast source device sending the multicast data stream to the target device includes: In response to a multicast source device sending a multicast data stream to a target device, an extended protocol message sent by the multicast source device is obtained, wherein the target field represents a protocol identification field constructed by the multicast source device, and the protocol identification field is used to indicate whether to prohibit or allow triggering a state machine change of the routing device.

3. The method according to claim 2, characterized in that The method further comprises: In response to a multicast source device sending a multicast data stream to a target device, obtaining a first extended protocol message sent by the multicast source device, wherein a trigger field is set in a message header of the first extended protocol message, the trigger field being used to instruct the routing device to forward the first extended protocol message to the target device and prohibit triggering a state machine change of the routing device; In response to a multicast source device sending a multicast data stream to a target device, a second extended protocol message carrying a target field sent by the multicast source device is obtained, wherein the target device, the multicast source device and the routing device all comply with the Internet Group Management Protocol, and the second extended protocol message indicates that a control field is added to the end of the query message of the Internet Group Management Protocol, and the control field is used to instruct the routing device to forward the second extended protocol message to the target device and prohibit triggering a state machine change of the routing device.

4. The method according to claim 1, wherein The step of suspending updating the membership of the target multicast group where the multicast source device is located and sending the extended protocol message to the target device includes: Parsing the route suppression flag in the target field; When the route suppression flag is in an activated state, prohibiting updating the state machine of the querier associated with the target multicast group; Send the extended protocol message to the target device.

5. The method according to claim 1, wherein After receiving the membership report message returned by the target device and updating the membership of the target multicast group based on the membership report message, the method further includes: receiving the multicast data stream sent by the multicast source device; The multicast data stream is sent to the target device.

6. The method according to claim 1, characterized in that The receiving the membership report message returned by the target device and updating the membership of the target multicast group based on the membership report message includes: receiving a membership report message returned by the target device, wherein the membership report message is a message generated based on a modified message that complies with the protocol specification, and the modified message is a message generated after the target device, when receiving the extended protocol message, ignores an initial value of an integrity verification field preset in a message header and recalculates the integrity verification field based on payload data of the extended protocol message; The membership of the target multicast group is updated based on the membership report message.

7. A multicast group management device, characterized in that: include: an acquisition module, configured to, in response to a multicast source device sending a multicast data stream to a target device, acquire an extended protocol message sent by the multicast source device, wherein the target field carried in the extended protocol message is used to instruct the target device to report multicast group membership to the routing device; a forwarding module, configured to suspend updating the membership of the target multicast group where the multicast source device is located, and send the extended protocol message to the target device; The receiving module is configured to receive a membership report message returned by the target device, and update the membership of the target multicast group based on the membership report message.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein the computer program can be executed by an electronic device to perform the method according to any one of claims 1 to 6.

9. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 6 through the computer program.

Images