A method and system for door lock flow scheduling

Abstract

This invention discloses a method and system for door lock traffic scheduling. The method includes: obtaining the actual forwarding path of the video stream based on the transmission of door lock video stream packets on the forwarding path; based on the alarm notification triggered when the outgoing interface is congested, the source gateway negotiates with candidate gateways via multicast, and determines the proxy gateway that can avoid the congestion point based on the comparison result between the default outgoing path of each candidate gateway and the congestion location; based on the processing of the source gateway distributing the congested stream to the proxy gateway, the proxy gateway sets a URPF exemption flag when forwarding the traffic, and enables the upstream router to skip source address verification based on the flag; based on the feedback of the actual path of the proxy stream received by the source gateway, the proxy path and the local remaining traffic path are double-verified, and path correction or renegotiation is triggered when the verification fails. Using the embodiments of this invention, the transmission continuity of door lock video streams and the efficiency of network resource utilization can be improved.

Description

Technical Field

[0001] This invention belongs to the field of smart door lock technology, and in particular to a method and system for door lock traffic scheduling. Background Technology

[0002] With the rapid development of smart homes and the Internet of Things, smart door locks, as core devices for home security, place higher demands on network transmission quality due to their video monitoring and real-time intercom functions. Door lock video streams typically use real-time transmission protocols, making them highly sensitive to bandwidth, latency, and packet loss rates. Existing network scheduling solutions primarily rely on the source gateway selecting transmission paths based on its local routing table, combined with traditional congestion control mechanisms (such as TCP congestion window adjustment and ECN explicit congestion notification) for traffic scheduling.

[0003] However, in real-world network environments, due to factors such as limited uplink bandwidth, wireless channel interference, and concurrent transmission by multiple devices, intermediate nodes along the door lock video stream transmission path are highly susceptible to congestion. Traditional solutions have the following shortcomings: First, the source gateway cannot accurately perceive the actual forwarding path, making it difficult to quickly locate the problem node after congestion occurs; second, congestion mitigation measures are usually limited to source-end speed reduction or passive packet loss, failing to proactively avoid congestion points without interrupting the video stream; third, when using multi-gateway collaborative forwarding, the upstream router's Source Address Verification (URPF) mechanism blocks the forwarding traffic, causing the forwarding scheme to fail; fourth, the lack of a closed-loop verification mechanism means that the new path after forwarding may trigger secondary congestion. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for door lock traffic scheduling to overcome the shortcomings of the prior art and improve the transmission continuity of door lock video streams and the efficiency of network resource utilization.

[0005] One embodiment of this application provides a method for door lock traffic scheduling, the method comprising: Path awareness and state maintenance: Based on the transmission of the door lock video stream packet on the forwarding path, the source gateway inserts a custom path record hop-by-hop option header into the packet. Each network node along the way records its outgoing interface information in the option header in sequence. The last hop node extracts the complete path information and feeds it back to the source gateway to obtain the actual forwarding path of the video stream. Congestion detection and proxy negotiation: Based on the alarm notification triggered when the network node detects congestion on the outgoing interface, the source gateway negotiates with the candidate gateways via multicast and determines the proxy gateway that can avoid the congestion point based on the comparison results of the default outgoing path of each candidate gateway and the congestion location. Cross-gateway forwarding and exemption forwarding: Based on the processing of the source gateway distributing congested traffic to the forwarding gateway, the forwarding gateway sets the URPF exemption flag when forwarding the traffic, and enables the upstream router to skip the source address verification based on the flag, thus realizing the legitimate traversal of the forwarded traffic; Closed-loop adjustment and dynamic optimization: Based on the actual path feedback of the proxy flow received by the source gateway, the proxy path and the local remaining traffic path are double-checked, and if the check fails, path correction or cancellation of renegotiation is triggered to form a closed-loop scheduling to prevent secondary congestion.

[0006] Optionally, the path awareness and state maintenance include: Option header insertion and outgoing interface record: Based on the path record inserted by the source gateway between the IP header and the transport layer header of the video stream packet, the hop-by-hop option header is inserted by each network node along the way when forwarding the packet, and the network node identifier of the node and the outgoing interface identifier of the forwarding interface are written into the outgoing interface record block list of the option header in sequence. Last-hop path extraction: When the packet arrives at the destination edge router, the router identifies itself as the last-hop node, extracts all accumulated outgoing interface record block information in the option header, and generates hop-by-hop path information containing flow identifiers and ordered path lists; Path information feedback: Based on the hop-by-hop path information generated by the last hop node, encapsulate it into a hop-by-hop path feedback message and send it to the source gateway; Mapping table maintenance: Based on the hop-by-hop path feedback messages received by the source gateway, parse and store the mapping relationship between the five-tuple of the video stream and the ordered path list to obtain the locally maintained path mapping table.

[0007] Optionally, the congestion detection and proxy negotiation include: Congestion alarm trigger: When a network node detects that the traffic load of its outgoing interface exceeds a preset threshold, it extracts the five-tuple of the video stream passing through the outgoing interface, determines the first-hop router to the source network segment according to the source network segment-first-hop mapping table, and sends a congestion alarm notification message containing the congested node identifier, the congested outgoing interface identifier, and the list of affected flows to the first-hop router. Then, the first-hop router and subsequent routers along the way forward the congestion alarm notification message back to the source gateway hop by hop according to the matching logic of the source network segment-first-hop mapping table. Multicast negotiation request: Based on the congestion alarm notification received by the source gateway, a negotiation request message containing the current load, congestion information and an initially empty exclusion path list is sent to other gateways via multicast. Candidate gateway response: After receiving the negotiation request message, the candidate gateway parses the destination IP of the affected flow and queries the local routing or path mapping table to determine the default outgoing path to the destination. If the default outgoing path does not contain congestion points, it unicasts a negotiation response message containing available load and representative path information to the source gateway. Data transmission decision and path verification: Based on the negotiation response messages received by the source gateway within a set time, dual path verification is performed by combining the available load and representative path information of each candidate gateway. This includes verifying whether the data transmission path of the candidate gateway avoids congestion points, and verifying whether the tunnel establishment path avoids congestion points when the source gateway and the candidate gateway are in different network segments, thus selecting the optimal data transmission gateway.

[0008] Optionally, the cross-gateway forwarding and exemption forwarding includes: Traffic forwarding on behalf of others: After determining the forwarding gateway and the set of forwarding flows based on the source gateway, a forwarding execution notification message containing a list of forwarding flow identifiers is sent to the forwarding gateway, and the video stream data packets that need to be split are forwarded to the forwarding gateway. Among them, if the source gateway and the forwarding gateway are in the same network segment, the source gateway does not change the source and destination IP of the original IP packet, but only replaces the source and destination MAC before sending it to the forwarding gateway; if the source gateway and the forwarding gateway are in different network segments, the source gateway encapsulates the original IP packet using an IP-in-IP tunnel and sends it to the forwarding gateway. Traffic identification on behalf of others: After receiving the data packet, the gateway on behalf of others extracts its five-tuple and matches it with the traffic on behalf of others policy table generated locally based on the traffic on behalf of others execution notification message. If the match is found, it is confirmed as legitimate traffic on behalf of others. Specifically, for packets in the same network segment, the five-tuple is extracted based on the destination MAC address being the same as the packet but the destination IP address being different from the packet. For packets in different network segments, the inner packet five-tuple is extracted after decapsulation. URPF Exemption Flag Setting: After the proxy gateway confirms the proxy traffic and prepares to forward it upstream, the URPF exemption flag is set in the reserved field of the hop-by-hop option header of the path record to mark the packet as proxy traffic; Exemption forwarding execution: After receiving a packet carrying the URPF exemption flag from the upstream router, the router parses the option header and checks the flag. If the flag is valid, the router skips the unicast reverse path forwarding detection, forwards the packet normally according to the destination IP, and continues to record the outgoing interface information of this node when forwarding on the outgoing interface.

[0009] Optionally, the closed-loop adjustment and dynamic optimization include: Dual verification of the forwarding path: When the forwarding gateway writes its own IP address into the reserved field of the hop-by-hop option header of the path record during forwarding, the last hop node identifies this field and sends hop-by-hop path feedback messages to both the source gateway and the forwarding gateway. After receiving the hop-by-hop path feedback message for the forwarding traffic from the last hop node, the source gateway performs dual verification, including the first verification to check whether the ordered path list of the forwarding path still contains the original congestion point, and the second verification to cross-compare the forwarding path with the ordered path list of other video streams that the source gateway is currently forwarding to check whether there is the same outgoing interface combination. Progressive rescheduling: Based on the result of the double verification failing, the local policy route correction of the proxy gateway is triggered first. That is, the source gateway sends a path redirection message containing a list of conflict paths to be excluded to the proxy gateway. The proxy gateway confirms the current path according to the local path mapping table and issues policy routes to force subsequent messages to bypass the conflict nodes. Cancellation and Renegotiation of Submission: If the policy route correction fails due to the lack of available non-conflicting paths on the local submission gateway, the source gateway sends a cancellation message to the submission gateway to reclaim the submission traffic. The source gateway also carries an exclusion path list in the resent multicast negotiation request, requesting the responding gateway to avoid the original congestion point and overlapping links. Local degradation processing: If no other gateway responds with a negotiation response message, the source gateway reclaims all traffic sent on behalf of the user and forwards it locally using a reduced bitrate method.

[0010] Optionally, the method further includes multi-path parallel proxying and proactive congestion prevention processing based on flow slices: Active congestion risk detection: When each network node along the route writes the real-time load status of the current interface into the outgoing interface record block, the source gateway periodically traverses the ordered path list of each video stream in the local path mapping table to check whether the outgoing interface load status of any hop reaches the warning threshold, i.e. the early soft threshold. If so, the stream is determined to have congestion risk in advance. Multi-gateway slice negotiation: Based on the detection of congestion risk or the absence of a single available proxy gateway, the source gateway sends a slice negotiation request via multicast, triggering candidate gateways to perform deep path investigation. If there is an alternative path that avoids the congestion point or is excluded from the path list, it replies with a negotiation response message, carrying the available load and the expected next hop identifier of the alternative path. Message-level stream slicing and distribution: Based on the negotiation response message received by the source gateway, determine the set of candidate gateways that can be forwarded and their available load, slice the video stream to be forwarded at the IP packet level, and distribute the sliced ​​packets to multiple forwarding gateways according to the available load ratio. Slice packet identification and forwarding: After the proxy gateway receives the slice packet, it reuses the reserved field of the hop-by-hop option header of the path record to set the multi-path aggregation flag and slice sequence number, and writes the proxy gateway's own IP address into the proxy gateway IP address field of the reserved field. Then, according to the alternative path distribution policy determined during negotiation, the slice packet is directed to the non-default outgoing interface for forwarding. Server-side reassembly and dynamic optimization: After receiving the sliced ​​message, the door lock APP server parses the multi-path aggregation flag and slice sequence number in the option header to complete the reassembly of the multi-path sliced ​​message; at the same time, the source gateway dynamically adjusts the proportion of sliced ​​messages distributed to different proxy gateways based on the load status changes of the outgoing interfaces of each sliced ​​flow path fed back by the last hop node, so as to achieve fine-grained smooth traffic migration.

[0011] Another embodiment of this application provides a system for door lock traffic scheduling, the system comprising: The perception module is used for path awareness and status maintenance: based on the transmission of the door lock video stream packet on the forwarding path, the source gateway inserts a custom path record hop-by-hop option header into the packet. Each network node along the way records its outgoing interface information in the option header in sequence. The last hop node extracts the complete path information and feeds it back to the source gateway to obtain the actual forwarding path of the video stream. The detection module is used for congestion detection and proxy negotiation: based on the alarm notification triggered when the network node detects congestion on the outgoing interface, the source gateway negotiates with the candidate gateways in a multicast manner, and determines the proxy gateway that can avoid the congestion point based on the comparison results of the default outgoing path of each candidate gateway and the congestion location. The proxy module is used for cross-gateway proxying and exempt forwarding: based on the processing of the source gateway distributing congested traffic to the proxy gateway, the proxy gateway sets the URPF exempt flag when forwarding the traffic, and enables the upstream router to skip the source address verification based on the flag, so as to realize the legitimate traversal of the proxy traffic; The adjustment module is used for closed-loop adjustment and dynamic optimization: based on the actual path feedback of the proxy flow received by the source gateway, the proxy path and the local remaining traffic path are double-checked, and if the check fails, path correction or cancellation of renegotiation is triggered to form a closed-loop scheduling to prevent secondary congestion.

[0012] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0013] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0014] Compared with existing technologies, the door lock traffic scheduling method provided by this invention can improve the transmission continuity of door lock video streams and the efficiency of network resource utilization. Attached Figure Description

[0015] Figure 1 Hardware structure block diagram of a computer terminal for a door lock traffic scheduling method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a door lock traffic scheduling method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a door lock flow scheduling system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a typical network topology for door lock traffic scheduling provided in an embodiment of the present invention. Detailed Implementation

[0016] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0017] In apartments, communities, and other similar institutions, smart door locks are uniformly installed in all rooms and managed through building and floor gateways. Residents can remotely communicate with their door locks via a video stream through a door lock app in various scenarios, such as security alarm video push notifications, visitors calling the user's door lock app via video, and residents remotely viewing the outdoor video feed from their door locks in real time. When video stream communication is frequent in some rooms, the video stream may concentrate in a certain area, causing congestion.

[0018] This invention first provides a method for door lock traffic scheduling, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0019] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a door lock traffic scheduling method provided in an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0020] See Figure 2 The present invention provides a method for door lock traffic scheduling, which may include the following steps: S201, Path Awareness and State Maintenance: Based on the transmission of the door lock video stream packet along the forwarding path, the source gateway inserts a custom path record hop-by-hop option header into the packet. Each network node along the path sequentially records its outgoing interface information in this option header, and the last hop node extracts the complete path information and feeds it back to the source gateway to obtain the actual forwarding path of the video stream. Specifically, the path awareness and state maintenance includes: Option header insertion and outgoing interface record: Based on the path record inserted by the source gateway between the IP header and the transport layer header of the video stream packet, the hop-by-hop option header is inserted by each network node along the way when forwarding the packet, and the network node identifier of the node and the outgoing interface identifier of the forwarding interface are written into the outgoing interface record block list of the option header in sequence. Last-hop path extraction: When the packet arrives at the destination edge router, the router identifies itself as the last-hop node, extracts all accumulated outgoing interface record block information in the option header, and generates hop-by-hop path information containing flow identifiers and ordered path lists; Path information feedback: Based on the hop-by-hop path information generated by the last hop node, encapsulate it into a hop-by-hop path feedback message and send it to the source gateway; Mapping table maintenance: Based on the hop-by-hop path feedback messages received by the source gateway, parse and store the mapping relationship between the five-tuple of the video stream and the ordered path list to obtain the locally maintained path mapping table.

[0021] S202, Congestion Detection and Delegation Negotiation: Based on the alarm notification triggered when a network node detects congestion at an outgoing interface, the source gateway negotiates with candidate gateways via multicast. Based on the comparison between the default outgoing paths of each candidate gateway and the congestion location, a delegated gateway that can avoid the congestion point is determined. Specifically, the congestion detection and delegation negotiation includes: Congestion alarm trigger: When a network node detects that the traffic load of its outgoing interface exceeds a preset threshold, it extracts the five-tuple of the video stream passing through the outgoing interface, determines the first-hop router to the source network segment according to the source network segment-first-hop mapping table, and sends a congestion alarm notification message containing the congested node identifier, the congested outgoing interface identifier, and the list of affected flows to the first-hop router. Then, the first-hop router and subsequent routers along the way forward the congestion alarm notification message back to the source gateway hop by hop according to the matching logic of the source network segment-first-hop mapping table. Multicast negotiation request: Based on the congestion alarm notification received by the source gateway, a negotiation request message containing the current load, congestion information and an initially empty exclusion path list is sent to other gateways via multicast. Candidate gateway response: After receiving the negotiation request message, the candidate gateway parses the destination IP of the affected flow and queries the local routing or path mapping table to determine the default outgoing path to the destination. If the default outgoing path does not contain congestion points, it unicasts a negotiation response message containing available load and representative path information to the source gateway. Data transmission decision and path verification: Based on the negotiation response messages received by the source gateway within a set time, dual path verification is performed by combining the available load and representative path information of each candidate gateway. This includes verifying whether the data transmission path of the candidate gateway avoids congestion points, and verifying whether the tunnel establishment path avoids congestion points when the source gateway and the candidate gateway are in different network segments, thus selecting the optimal data transmission gateway.

[0022] S203, Cross-Gateway Forwarding and Exemption Forwarding: Based on the process of the source gateway distributing congested traffic to the forwarding gateway, the forwarding gateway sets a URPF exemption flag when forwarding the traffic, and enables the upstream router to skip source address verification based on this flag, thus achieving legitimate traversal of the forwarded traffic; specifically, the cross-gateway forwarding and exemption forwarding includes: Traffic forwarding on behalf of others: After determining the forwarding gateway and the set of forwarding flows based on the source gateway, a forwarding execution notification message containing a list of forwarding flow identifiers is sent to the forwarding gateway, and the video stream data packets that need to be split are forwarded to the forwarding gateway. Among them, if the source gateway and the forwarding gateway are in the same network segment, the source gateway does not change the source and destination IP of the original IP packet, but only replaces the source and destination MAC before sending it to the forwarding gateway; if the source gateway and the forwarding gateway are in different network segments, the source gateway encapsulates the original IP packet using an IP-in-IP tunnel and sends it to the forwarding gateway. Traffic identification on behalf of others: After receiving the data packet, the gateway on behalf of others extracts its five-tuple and matches it with the traffic on behalf of others policy table generated locally based on the traffic on behalf of others execution notification message. If the match is found, it is confirmed as legitimate traffic on behalf of others. Specifically, for packets in the same network segment, the five-tuple is extracted based on the destination MAC address being the same as the packet but the destination IP address being different from the packet. For packets in different network segments, the inner packet five-tuple is extracted after decapsulation. URPF Exemption Flag Setting: After the proxy gateway confirms the proxy traffic and prepares to forward it upstream, the URPF exemption flag is set in the reserved field of the hop-by-hop option header of the path record to mark the packet as proxy traffic; Exemption forwarding execution: After receiving a packet carrying the URPF exemption flag from the upstream router, the router parses the option header and checks the flag. If the flag is valid, the router skips the unicast reverse path forwarding detection, forwards the packet normally according to the destination IP, and continues to record the outgoing interface information of this node when forwarding on the outgoing interface.

[0023] S204, Closed-loop adjustment and dynamic optimization: Based on the actual path feedback of the proxy flow received by the source gateway, the proxy path and the local remaining traffic path are double-checked. If the check fails, path correction or renegotiation is triggered to form a closed-loop scheduling to prevent secondary congestion. Specifically, the closed-loop adjustment and dynamic optimization includes: Dual verification of the forwarding path: When the forwarding gateway writes its own IP address into the reserved field of the hop-by-hop option header of the path record during forwarding, the last hop node identifies this field and sends hop-by-hop path feedback messages to both the source gateway and the forwarding gateway. After receiving the hop-by-hop path feedback message for the forwarding traffic from the last hop node, the source gateway performs dual verification, including the first verification to check whether the ordered path list of the forwarding path still contains the original congestion point, and the second verification to cross-compare the forwarding path with the ordered path list of other video streams that the source gateway is currently forwarding to check whether there is the same outgoing interface combination. Progressive rescheduling: Based on the result of the double verification failing, the local policy route correction of the proxy gateway is triggered first. That is, the source gateway sends a path redirection message containing a list of conflict paths to be excluded to the proxy gateway. The proxy gateway confirms the current path according to the local path mapping table and issues policy routes to force subsequent messages to bypass the conflict nodes. Cancellation and Renegotiation of Submission: If the policy route correction fails due to the lack of available non-conflicting paths on the local submission gateway, the source gateway sends a cancellation message to the submission gateway to reclaim the submission traffic. The source gateway also carries an exclusion path list in the resent multicast negotiation request, requesting the responding gateway to avoid the original congestion point and overlapping links. Local degradation processing: If no other gateway responds with a negotiation response message, the source gateway reclaims all traffic sent on behalf of the user and forwards it locally using a reduced bitrate method.

[0024] Furthermore, the method also includes multi-path parallel proxying and proactive congestion prevention processing based on flow slices: Active congestion risk detection: When each network node along the route writes the real-time load status of the current interface into the outgoing interface record block, the source gateway periodically traverses the ordered path list of each video stream in the local path mapping table to check whether the outgoing interface load status of any hop reaches the warning threshold, i.e. the early soft threshold. If so, the stream is determined to have congestion risk in advance. Multi-gateway slice negotiation: Based on the detection of congestion risk or the absence of a single available proxy gateway, the source gateway sends a slice negotiation request via multicast, triggering candidate gateways to perform deep path investigation. If there is an alternative path that avoids the congestion point or is excluded from the path list, it replies with a negotiation response message, carrying the available load and the expected next hop identifier of the alternative path. Message-level stream slicing and distribution: Based on the negotiation response message received by the source gateway, determine the set of candidate gateways that can be forwarded and their available load, slice the video stream to be forwarded at the IP packet level, and distribute the sliced ​​packets to multiple forwarding gateways according to the available load ratio. Slice packet identification and forwarding: After the proxy gateway receives the slice packet, it reuses the reserved field of the hop-by-hop option header of the path record to set the multi-path aggregation flag and slice sequence number, and writes the proxy gateway's own IP address into the proxy gateway IP address field of the reserved field. Then, according to the alternative path distribution policy determined during negotiation, the slice packet is directed to the non-default outgoing interface for forwarding. Server-side reassembly and dynamic optimization: After receiving the sliced ​​message, the door lock APP server parses the multi-path aggregation flag and slice sequence number in the option header to complete the reassembly of the multi-path sliced ​​message; at the same time, the source gateway dynamically adjusts the proportion of sliced ​​messages distributed to different proxy gateways based on the load status changes of the outgoing interfaces of each sliced ​​flow path fed back by the last hop node, so as to achieve fine-grained smooth traffic migration.

[0025] To address the issue of localized network congestion caused by concentrated concurrent video streams from smart door locks in apartment and community settings, a path-aware cross-gateway traffic dispatching method is provided to ensure the stability and smooth operation of video services. One technical solution includes: Prerequisites: 1. Smart door locks are uniformly connected to various gateways that are directly connected.

[0026] 2. Gateways support direct Layer 2 connection within the same network segment or Layer 3 communication across network segments.

[0027] 3. The gateway has a multi-path redundancy topology among its upstream routers, ensuring that there are multiple forwarding paths in the network with non-overlapping physical links, providing a physical basis for cross-gateway traffic to bypass the original congestion point.

[0028] 4. All routers participating in path recording are configured to forward IPv4 packets with the options defined in this scheme using either hardware or software, and not to drop them.

[0029] Typical network topology such as Figure 4As shown in the diagram, door locks 1-3 and 4-6 are directly connected to gateway A and gateway B respectively via WiFi modules. The first-hop router uplink for gateway A is R1, and for gateway B it is R3. Following the video stream from the door locks, the next hop for router R1 is R2, the next hop for router R3 is R4, and so on, ultimately reaching the last-hop router RN (the last-hop router closest to the door lock app server). There are reachable links between R1, R2, R3, R4, etc., forming a multi-path redundancy topology. The door lock app server is located on the server area network segment directly connected to router RN or connected to RN via a server area switch / firewall. The resident's door lock app establishes communication with the door locks through the door lock app server.

[0030] Technical implementation process: 1. Path awareness and state maintenance.

[0031] (1) Before the video stream data packet of the door lock (such as door lock 1-3) is prepared to be sent to the door lock APP server by its gateway (such as gateway A), in order to better record the subsequent forwarding path of the packet (for subsequent congestion detection and cross-gateway forwarding path selection), gateway A adds a custom "path record hop-by-hop option header" between the IP header and the transport layer (TCP / UDP) header of the packet (the subsequent network nodes along the way can add information in turn to record the video stream forwarding path, including the identifier of each forwarding network node and its outgoing interface identifier. The reason for recording the outgoing interface information instead of the incoming interface information is because network congestion occurs at the outgoing interface). The content includes: path record hop-by-hop option identifier, total length of option header, number of recorded hops, reserved fields, list of outgoing interface record blocks (each outgoing interface record block contains network node identifier and outgoing interface identifier) ​​and other fields.

[0032] The path record hop-by-hop option identifier (e.g., "11") is used to identify the hop-by-hop option of the path record, which requires routers along the path to recognize and process it; the recorded hop count is used to count the number of outgoing interface record blocks that have been written so far, and is initially 0; the reserved field is 8 bytes, which is used for future expansion (see below), and is set to 0 by default; the outgoing interface record block list is the outgoing interface information written sequentially by the first hop network node, the second hop network node, etc. (excluding the outgoing interface information of the source gateway A). According to the preset hop count (e.g., 8 hops), a sufficient number of blank record block spaces are pre-allocated when the source gateway sends the data. The content of each "outgoing interface record block" in the outgoing interface record block list includes: network node identifier (router ID) and outgoing interface identifier (e.g., the physical port number of the router that sent the packet) fields.

[0033] In the IPv6 protocol, the hop-by-hop options header is a standard specification, and this solution directly utilizes its extension header mechanism. The complete IPv6 video stream packet structure after the addition is as follows: [Ethernet Header] + [IPv6 Basic Header] + [Path Record Hop-by-Hop Options Header] + [TCP / UDP Header] + [Video Stream Payload].

[0034] In the IPv4 protocol, since standard IP options are often discarded by hardware acceleration in backbone networks, this solution utilizes the IPv4 option fields to achieve equivalent functionality in a controllable intranet environment. The complete IPv4 video stream packet structure after the addition is as follows: [Ethernet Header] + [IPv4 Basic Header] (Internet Header Length field added, Option field contains path record options for this solution) + [TCP / UDP Header] + [Video Stream Payload].

[0035] (2) When each network node (such as routers R1 and R2) forwards the packet, it recognizes the path record hop-by-hop option identifier, and then sequentially adds its own outgoing interface record block information (its own router ID + the physical port number that sent the packet) to the "outgoing interface record block list" in the option header, increments the count of the recorded hops by one, and then forwards the packet from the outgoing interface.

[0036] (3) When the video stream data packet arrives at the last-hop router (i.e., the edge router near the door lock APP server, such as the RN), the router RN checks its local routing table and finds that the destination IP of the packet matches the directly connected route, thus confirming itself as the last-hop router. At this time, the router RN extracts all the outgoing interface information accumulated in the data packet and generates "hop-by-hop path information" containing the five-tuple information of the data packet (source IP, destination IP, source port, destination port, protocol type). This information includes fields such as: flow identifier, hop count, and ordered path list (including [path node item 1], [path node item 2]...[path node item N]).

[0037] The stream identifier, or 5-tuple information, uniquely identifies the video stream. The hop count is the total number of network nodes the video stream traverses from the source gateway to the router RN (excluding the source gateway), which is the number of extracted outgoing interface record blocks. The ordered path list consists of multiple "path node entries" arranged in the order the packet passed through. The first entry is the first hop node (i.e., the R1+R1 forwarding interface), and the last entry is the last hop node (i.e., the RN+RN forwarding interface). The number of "path node entries" is the hop count. Each "path node entry" contains: a network node identifier and an outgoing interface identifier field, corresponding to the network node identifier extracted from the packet header and the outgoing interface identifier when the node forwards this stream, respectively.

[0038] (4) The router RN will send the generated 5-tuple hop-by-hop path information back to the source gateway (such as gateway A) via a "hop-by-hop path feedback message". This message contains fields such as message type and hop-by-hop path information (including flow identifier, hop count, and ordered path list).

[0039] Among them, the message type is represented by "01" to indicate "hop-by-hop path feedback"; the hop-by-hop path information carries the "hop-by-hop path information" data structure defined above, including: stream identifier (i.e. video stream quintuple), hop count, and ordered path list.

[0040] (5) After receiving the hop-by-hop path feedback message, Gateway A parses out the hop-by-hop path information and saves and maintains the “five-tuple-hop-by-hop path mapping table” locally (the table uses the five-tuple as the primary key and the ordered path list as the value).

[0041] 2. Congestion detection and gateway negotiation.

[0042] (1) Each network node (such as routers R1, R2, etc.) monitors the traffic status of each outgoing interface in real time. Each router automatically generates and periodically updates the "source network segment - first hop mapping table" by resolving the local routing table and ARP / ND neighbor table (recording the correspondence between the source network segment and the first hop router IP and the outgoing interface, where the first hop router IP is the first hop IP address of the router to the source network segment, that is, the next hop IP address corresponding to the source network segment in the routing table). When the traffic load on a certain outgoing interface of a network node (such as router R2) exceeds a preset threshold, R2 extracts the source IP (such as the IP of door lock 1) of the video stream data packets passing through that interface, determines the IP of the first-hop router to the source network segment according to the "source network segment-first-hop mapping table", and sends a "congestion alarm notification message" to the first-hop router. The router that receives the message determines the source network segment by extracting the source IP of the affected flow in the message, and queries the local "source network segment-first-hop mapping table" to obtain the IP of the next-hop router that is closer to the source network segment. Thus, the congestion alarm notification message is forwarded hop by hop along the direction to the source network segment until it reaches the source gateway (such as gateway A). The source gateway is responsible for subsequent cross-gateway negotiation and forwarding scheduling.

[0043] The congestion alarm notification message includes fields such as: message type, congestion node identifier, congestion egress interface identifier, number of affected flows, and list of affected flows (including the 5-tuple of the video streams that triggered the alarm). This informs gateway A of the specific physical location where congestion occurred and the affected video streams. Specifically, the message type is represented by "02" to indicate "congestion alarm notification"; the congestion node identifier is the router ID that sent the message (e.g., the ID of R2); the congestion egress interface identifier is the specific egress interface identifier where congestion occurred (e.g., the physical port number of R2), allowing for precise location of the congestion using "congestion node identifier + congestion egress interface identifier"; the number of affected flows is the number of video streams that have passed through the congested interface and triggered the alarm (determined by counting the number of video streams with path record hop-by-hop option headers passing through the egress interface), which is the number of 5-tuples in the affected flows list field; each flow identifier in the affected flows list is a 5-tuple, used to inform the gateway which specific video streams are affected by congestion.

[0044] (2) After receiving the congestion alarm from R2, Gateway A saves the information locally and negotiates with other gateways (such as Gateway B, Gateway C, etc.) via multicast. Gateway A sends a "negotiation request message" via multicast (each gateway has pre-added this multicast address to realize multicast communication), thereby announcing its current video access traffic load and R2's congestion information. Specifically, the negotiation request message contains fields such as message type, source gateway identifier, current load, congestion information, and exclusion path list. Among them, the message type, such as "03", indicates "negotiation request"; the current load is the total bandwidth or number of video access traffic of Gateway A; the congestion information carries the core content of the congestion alarm received from R2, including congestion node identifier + congestion outgoing interface identifier + number of affected flows + list of affected flows; the exclusion path list is filled in by Gateway A during dynamic renegotiation of path avoidance (see step 4), which includes a combination list of "network node identifier + outgoing interface identifier" of the currently occupied local paths, used to request the responding gateway to exclude these links, and is 0 during the initial negotiation.

[0045] Upon receiving the negotiation request message, other gateways parse the affected flow list to extract the destination IP of the video stream (i.e., the destination of the affected video stream). They then query their locally maintained "five-tuple-hop-by-hop path mapping table" or routing table to determine the default outgoing path to that destination (i.e., the default forwarding path determined by the local routing table and path record policy when no proxy scheduling occurs). They compare the "network node identifier + outgoing interface identifier" in this default outgoing path with the congestion information (congested node identifier + congested outgoing interface identifier) ​​carried in the negotiation request. If their default outgoing path still passes through the congestion point, they determine that they cannot provide congestion avoidance proxy service and remain silent, not sending a negotiation response message to reduce invalid interactions. If their default outgoing path avoids the congestion point, they unicast a negotiation response message to gateway A, thus providing feedback on their load status and available path resources. Specifically, the negotiation response message includes fields such as message type, responding gateway identifier, available load, and representative path information. Among them, message type such as "04" indicates "unicast negotiation response"; available load is the remaining traffic bandwidth or number of flows that gateway B can currently handle; representative path information is an "ordered path list" of several typical flows extracted from the local mapping table by gateway B, which is used by gateway A to verify that it has indeed avoided the congested interface of R2 (the purpose of designing the representative path information field is that, since there may be multiple path load sharing in actual forwarding, the default outgoing path avoiding the congestion point does not absolutely mean that all actual flows have avoided it. Gateway A needs to parse the representative actual flow path to confirm that its actual forwarding trajectory has indeed avoided the congested interface of R2).

[0046] (3) Gateway A receives negotiation response messages from other gateways within a set time, comprehensively evaluates them, and makes a proxy decision. The specific logic is as follows: First, gateway A compares the available load in each response gateway message and selects the candidate gateway (such as gateway B) with the largest available load (i.e., the least idle).

[0047] Next, gateway A performs dual path verification: 1) Gateway A checks the representative path information in the candidate gateway response message to confirm that the "ordered path list" of its data transmission path (i.e. the path from the candidate gateway to the destination) does not contain the combination of "congested node R2 + congested outgoing interface". 2) If gateway A and the candidate gateway belong to different network segments and an IP-in-IP tunnel needs to be established (i.e., scenario two in step 3), gateway A also needs to verify the "tunnel establishment path" (i.e., the transport path from gateway A to the proxy gateway): gateway A queries its local routing table or local "five-tuple-hop-by-hop path mapping table" for the outgoing path to the candidate gateway IP, and checks whether the path contains the combination of "congested node + congested outgoing interface". If it does, it means that the outer tunnel packets of the proxy traffic will get congested during the process of being sent to the proxy gateway, and the candidate gateway will also be unavailable.

[0048] If the candidate gateway meets the conditions of sufficient load, data transmission path avoiding congestion points, and tunnel establishment path also avoiding congestion points, gateway A will decide to forward part of the video stream causing congestion to this gateway for forwarding; otherwise, gateway A will continue to evaluate the next candidate gateway (such as gateway C) in order of available load size until the optimal forwarding node is found.

[0049] (4) After determining the proxy gateway (such as gateway B) and the proxy flow set, gateway A sends a "proxy execution notification message" to the proxy gateway (such as gateway B). This message contains fields such as message type (such as "05"), source gateway identifier, proxy gateway identifier, and proxy flow identifier list (a list of five-tuples corresponding to a subset of the affected flow list decided by gateway A). After receiving the notification message, gateway B generates a local "proxy flow policy table", which contains fields such as video flow five-tuple, source gateway identifier, proxy status (typical values ​​are ACTIVE: normal proxy, REDIRECTING: policy route correction, PENDING_DELETE: waiting to be revoked and deleted; initially set to ACTIVE). The above proxy flow identifiers are recorded as legitimate proxy traffic, and are used as the basis for identifying proxy traffic and setting URPF (unicast reverse path forwarding) exemption flags in step 3(2).

[0050] 3. Cross-gateway forwarding and URPF exemption.

[0051] (1) Gateway A forwards the video stream data packets that need to be split to the proxy gateway (such as gateway B). The forwarding mechanism includes the following two cases: Scenario 1: Gateway A and Gateway B belong to the same local area network segment. Gateway A does not change the source IP (door lock IP) and destination IP (door lock APP server IP) of the original IP packet, but only replaces the destination MAC address with the internal MAC address of Gateway B and the source MAC address with the internal MAC address of Gateway A, thereby directly forwarding the packet to Gateway B through the Layer 2 switch.

[0052] Scenario 2: Gateway A and Gateway B belong to different network segments. Gateway A uses IP-in-IP tunnel encapsulation technology, encapsulating the original IP packet (source IP is the door lock IP, destination IP is the door lock APP server IP), which has already been inserted into the hop-by-hop header of the path record by Gateway A (a blank path record), as the inner payload, within an outer unicast IP packet (source IP is Gateway A, destination IP is Gateway B), and sending it to Gateway B. During forwarding to Gateway B, routers along the way only process the outer IP header, unaware of and not writing into the inner hop-by-hop header of the path record. After receiving the packet, Gateway B strips off the outer encapsulation header, restores the inner IP packet, and then performs the next step.

[0053] (2) After receiving the data packet forwarded by gateway A, gateway B needs to accurately identify whether it is traffic sent on behalf of others. The specific logic is as follows: First, gateway B extracts the 5-tuple from the packet. For case one (same network segment): gateway B detects that the Ethernet layer destination MAC is itself, but the IP layer destination IP is not itself (but rather the door lock APP server). In this case, gateway B extracts the 5-tuple from the packet. For case two (cross network segments): gateway B detects that the IP layer destination IP is itself, performs IP-in-IP decapsulation to restore the original inner IP header, and then extracts the 5-tuple from the inner packet.

[0054] Next, gateway B will match the extracted 5-tuple with the "delegated flow policy table" generated in step 2(4) based on the delegated flow execution notification message. If a match is found, it is confirmed that the message is delegated flow legally authorized and forwarded by gateway A; if no match is found, the message will be processed as a normal route forwarding message (the subsequent URPF exemption operation will not be performed).

[0055] (3) After confirming that the traffic is being forwarded on behalf of another user, Gateway B prepares to forward it to the first-hop upstream router (such as R3). At this time, since the source IP of the data packet still belongs to the network segment of Gateway A, if it is forwarded normally, the upstream router (such as Router R3 and its subsequent routers) will perform URPF detection by default to avoid receiving attack packets with spoofed source addresses. Under normal circumstances, the router (such as R3) will check whether the incoming interface of the packet is consistent with the "outgoing interface to the source IP" found in its local routing table. Only if they are consistent will it be considered a legitimate packet. For this traffic being forwarded on behalf of another user, if URPF detection is performed, Router R3 will find in its table that the outgoing interface to the network segment where the source IP is located points to Gateway A, while the packet is actually received from the incoming interface in the direction of Gateway B. The incoming interface does not match the outgoing interface of the source IP, so it will be judged as having a spoofed source address and the packet will be discarded. Therefore, Gateway B sets a URPF exemption flag in the header of this part of the traffic being forwarded on behalf of another user, so that the upstream router can cancel the URPF detection for this traffic being forwarded on behalf of another user. To avoid additional message overhead, this solution reuses the "Path Record Hop-by-Hop Options Header" defined in step 1, defining bit 0 of its "Reserved Field" as the URPF Bypass Flag. When forwarding traffic, Gateway B sets this URPF Bypass Flag to 1 (the default value is 0 for normal traffic).

[0056] (4) Due to the unified deployment of exemption policies on network devices within the organization, gateway B sends data packets with URPFBypass Flag=1 to the upstream router (such as R3) according to the normal routing table entry. In the ingress interface processing flow, each upstream router (R3 to RN) first parses the path record hop-by-hop option header in the IP header, checks the URPF Bypass Flag in the reserved field. If the flag is 1, no URPF detection is performed, and the data is forwarded normally according to the destination IP (if the flag is 0, a regular URPF detection is performed). Subsequently, in the outgress interface forwarding process, the outgress interface identifier of this node is written into the packet according to the mechanism in step 1 (to realize path awareness of the traffic being forwarded). This ensures that the traffic forwarded across gateways can successfully reach the router RN and the door lock APP server.

[0057] (5) After successful proxy transmission, Gateway B also sends a "successful proxy transmission feedback message" to Gateway A, which includes: message type (e.g., "06") and proxy transmission flow identifier list. After receiving the message, Gateway A updates the corresponding 5-tuple record in the 5-tuple-hop-by-hop path mapping table (adding fields such as proxy transmission label and pending gateway ID, and clearing the ordered path list for subsequent feedback).

[0058] 4. Further improvements: Path conflict detection and closed-loop avoidance for proxy traffic.

[0059] The above scheme achieves one-time traffic scheduling after a congestion alarm, but the forwarding path and network routing are dynamically changing. To achieve accurate dynamic scheduling of proxy traffic, prevent proxy traffic from causing secondary congestion or path backtracking, and support adaptive rerouting under dynamic network status changes, further improvements are made as follows: (1) The video stream forwarded by gateway B also goes through the process in step 1: the routers along the way (such as R3, etc.) write outgoing interface information, and the last hop router RN extracts the hop-by-hop path information of the traffic forwarded by gateway B. In order to improve feedback efficiency and avoid secondary synchronization between gateways, when gateway B performs forwarding, the reserved field (bits 18-49, a total of 32 bits) of the "Path Record Hop-by-Hop Option Header" of the packet is newly written with the "Hop-by-Hop Gateway IP Address" (fill in the IP address of gateway B itself). When RN extracts the hop-by-hop path information and generates the "Hop-by-Hop Path Feedback Message", in addition to sending feedback to gateway A according to the source IP of the message (door lock IP), it also identifies the "Hop-by-Hop Gateway IP Address" in the option header and directly sends a "Hop-by-Hop Path Feedback Message" to gateway B.

[0060] After receiving direct feedback from the RN, Gateway A and Gateway B independently update their local "5-tuple-hop-by-hop path mapping table" (Gateway B, in addition to recording the 5-tuple and ordered path list fields, also adds fields such as proxy label and source gateway ID) to complete the actual perception of the proxy path.

[0061] (2) Gateway A retrieves the "ordered path list" of traffic forwarded by Gateway B from the updated mapping table and performs double verification: First verification (congestion recurrence check): Traverse the ordered path list after gateway B forwards traffic and check if it still contains the combination of "congested node identifier + congested outgoing interface identifier" recorded in step 2. If it does, it means that the forwarded traffic has been rolled back to the congested link, and the forwarding is invalid.

[0062] The second layer of verification (path overlap check): The ordered path list after gateway B forwards the video streams is cross-referenced with the ordered path list of other video streams currently being forwarded locally by gateway A to check for the existence of the same "network node identifier + outgoing interface identifier" combination. If this exists, it indicates that the forwarded traffic and the remaining traffic of gateway A are competing for the link, which may cause new congestion.

[0063] (3) If the above double verification fails (i.e., a recurrence of congestion in the proxy traffic is detected, or a path overlap occurs with the remaining local traffic), gateway A determines that there is a path conflict in the current proxy scheduling and triggers a dynamic closed-loop adjustment mechanism. The adjustment strategy includes the following two methods with progressively higher priority: Method 1: Local policy route correction in Gateway B. Gateway A sends a "path redirection message" to Gateway B. This message contains: message type (e.g., "08"), source gateway identifier, proxy gateway identifier, redirection flow identifier list (i.e., the list of conflicting proxy flow 5-tuples), and exclusion path list (i.e., the combination of "network node identifier + outgoing interface identifier" that needs to be avoided, which are overlapping points or congestion points). After receiving the message, Gateway B uses the "5-tuple-hop-by-hop path mapping table" synchronously obtained and updated in step 4(1) to confirm the current actual forwarding path of the flow, and issues a policy route for the 5-tuple locally, forcing subsequent proxy messages to bypass conflicting nodes (e.g., the default route points to R3, and because R3 causes overlap, the policy route forces its next hop to point to R4), attempting to correct the path locally in Gateway B. Afterwards, in the local proxy flow policy table, the proxy status of the video stream is changed to "policy route correction"; and a successful path redirection response message (message type, e.g., "09") is sent to Gateway A.

[0064] Method 2: Cancellation and Renegotiation of Submission. If Gateway B has no other available non-conflicting paths locally (i.e., policy route correction fails), it sends a failed path redirection response message to Gateway A and changes the submission status of the video stream to "awaiting cancellation and deletion" in its local submission stream policy table. Gateway A then sends a "submission cancellation message" to Gateway B, containing fields such as: message type (e.g., "10"), source gateway identifier, submission gateway identifier, and adjusted submission stream identifier list (setting the video stream identifier to be cancelled, i.e., the 5-tuple), to reclaim the submitted traffic. Upon receiving this message, Gateway B deletes the corresponding video stream from its submission stream policy table. Simultaneously, Gateway A re-initiates the multicast negotiation request from step 2 (explicitly carrying the conflicting interface identifier in the excluded path list of the request) to reassess the availability of other gateways (such as Gateway C). Upon receiving a renegotiation request, other gateways not only verify whether their own paths avoid the original congestion point, but also cross-compare their default outgoing paths with the "excluded path list." If their own paths fall entirely within the excluded path list (i.e., still causing overlap), they remain silent and do not respond. Only when they possess an available path that does not contain any combination from the excluded path list do they unicast a negotiation response message to gateway A. If no other gateway responds with a negotiation response message, gateway A reclaims all forwarded traffic and reduces its forwarding speed locally using methods such as bitrate reduction.

[0065] (4) Subsequently, after each local update of the five-tuple-hop-by-hop path mapping table, gateway A repeatedly performs double checks (whether it passes through a congestion point again, whether it overlaps with other flows). Once a problem is found, it first notifies the proxy gateway (such as gateway B) to perform local policy route correction. If it still fails, it performs proxy cancellation and renegotiation (carrying the "excluded path list") to achieve dynamic optimization of traffic scheduling.

[0066] 5. Further improvements: Multi-path parallel proxying and proactive congestion prevention based on stream slices.

[0067] If the router triggers a congestion alarm notification in step 2, congestion has actually occurred, affecting video streaming services. Furthermore, in the dynamic closed loop of step 4, when path conflicts occur and no single gateway can provide a non-overlapping path, the existing mechanism can only reduce the bitrate and speed, sacrificing video quality.

[0068] To address this, this improved solution introduces a stream slicing and multi-path parallel transmission mechanism. This mechanism can aggregate the bandwidth of multiple gateways before congestion occurs, or when no suitable single transmission gateway is available during transmission, and avoid single-point congestion recurrence and link contention issues by using a multi-path transmission method, while also eliminating bit rate degradation. Specific improvements are as follows: (1) In the "Outgoing Interface Record Block" of the "Path Record Hop-by-Hop Option Header" defined in step 1, in addition to recording the "Network Node Identifier" and "Outgoing Interface Identifier", a new "Outgoing Interface Load Status" field is added (e.g., 00=Idle, 01=Normal, 10=Warning, 11=Blocked). In order to form a gradient defense with the passive congestion alarm in step 2, the judgment threshold of this field is strictly decoupled from step 2: the judgment basis of state 10 (warning) is the early soft threshold (e.g., the short-term average bandwidth utilization of the outgoing interface exceeds 70% or the instantaneous queue depth exceeds 30%), indicating that there is a risk of congestion in the link but it has not yet affected the service; the alarm trigger basis of state 11 (congestion) and step 2 is the late hard threshold (e.g., tail packet loss occurs or the continuous queue depth exceeds 85%), indicating that the link has experienced substantial congestion.

[0069] In addition, in order to distinguish the slice streams corresponding to different proxy gateways in the multi-path parallel proxy scenario, and to provide addressing basis for the last hop router RN to directly feed back path information to the proxy gateway, when the gateway forwards the packet as a proxy node, it writes its own IP address into the reserved field of the "Proxy Gateway IP Address" field of the "Path Record Hop-by-Hop Option Header" (as defined and explained in step 4 (1)). For example, all 0s indicate that the source gateway is sending the packet on its own, and writing the IP of gateway B indicates that it is sent by gateway B. This is to identify which proxy gateway the packet is actually forwarded by.

[0070] When routers along the path (such as R1 and R2) write the outgoing interface record block, they simultaneously map the current real-time queue depth or bandwidth utilization of that interface to a load status value and write it into the field. When the last-hop router RN feeds back "hop-by-hop path information" to the source gateway A and the proxy gateway, it not only feeds back the path topology, but also the early risk prediction for each hop on the path.

[0071] (2) When Gateway A maintains the “five-tuple-hop-by-hop path mapping table”, it periodically traverses the mapping table and actively checks the “outgoing interface load status” in the ordered path list of each video stream. When it finds that the load status of any hop on a certain path is “warning (10)”, even if it has not received the router’s “congestion alarm notification message”, Gateway A will determine in advance that the stream has a congestion risk and actively trigger the multi-gateway negotiation and stream slice delivery process (see step 5 (4)).

[0072] (3) In step 4, after gateway A re-initiates the multicast negotiation request in step 2, if no other gateway successfully replies with the negotiation response message, it means that there is currently no single-generation gateway with a default outgoing path that can avoid the congestion point. Gateway A will also trigger the multi-gateway negotiation and flow slice generation process (see step 5 (4)).

[0073] (4) When gateway A triggers the multi-gateway negotiation and flow slicing proxy process, regardless of whether the flow has entered the proxy state, the following flow slicing parallel proxy logic is executed: 1) Gateway A sends a "slice negotiation request message" to other gateways via multicast (the message type can be defined separately to distinguish it from the regular negotiation request in step 2, and carries a list of pre-congestion risk flows, congestion information, or exclusion path list, etc.) to query the available paths and remaining load of each gateway to the destination of the affected video stream; after receiving the request, other gateways perform deep path investigation: not only checking the default outgoing path to the destination, but also traversing the equal-cost multipath and available non-equal-cost paths in the local routing table. As long as there is any path (whether it is the default path or not) that can avoid the forwarding next hop of the congestion point / exclusion path, it is considered to have slice forwarding capability, and unicasts a "negotiation response message" to reply, carrying the available load and the expected next hop identifier of the alternative path (i.e., the next hop IP and outgoing interface corresponding to the non-default path in the local routing table).

[0074] 2) Gateway A determines the set of other gateways that can be forwarded based on the "available load" feedback from each gateway. It then performs packet-granularity distribution of the video streams to be forwarded at the IP packet level (allocating them to these different gateways in integer multiples of the number of packets), and determines the number of packets each gateway will handle according to the load ratio. In order for the door lock APP server to reassemble packets from different gateways, which may arrive out of order, into a coherent video stream, Gateway A reuses the reserved fields in the "Path Record Hop-by-Hop Option Header". The first bit is defined as the "Multi-Path Aggregation Identifier", and bits 2-17 (a total of 16 bits) are defined as the "Slice Sequence Number" (the 0th reserved byte is defined as the URPF Exemption Identifier, bits 18-49 are defined as the forwarding gateway IP address, and the other bits are still reserved). The multi-path aggregation flag is set to 1, indicating that the flow is a slice parallel forwarding flow; the slice sequence number is incremented according to the order of message sending; when the forwarding gateway (such as gateway B or gateway C) forwards these slice messages, since the slice forwarding may be forwarded through the non-default path of the forwarding gateway, the forwarding gateway needs to force the policy route to be issued locally according to the alternative path fed back in step 5 (4) 1) when forwarding the corresponding slice message, and direct the slice message to the next hop of the congestion avoidance point, and write its own IP address into the "forwarding gateway IP address" field according to the path that the slice message is planned to be forwarded (such as writing the IP address of gateway B when forwarding by gateway B, and writing the IP address of gateway C when forwarding by gateway C), so as to identify which forwarding gateway the message is actually forwarded by.

[0075] 3) Gateway A distributes the sliced ​​data packets proportionally to multiple proxy gateways (such as gateway B and gateway C). For example, if gateway B has a remaining bandwidth of X and gateway C has a remaining bandwidth of Y, then gateway A will alternately forward the sliced ​​packets to gateway B and gateway C in a ratio of X:Y. The forwarding mechanism follows the same network segment / cross network segment rules in step 3(1) and the URPF exemption flag in step 3(3).

[0076] 4) At the last-hop router RN, the RN extracts the path information from the hop-by-hop option header of the path record for feedback and transmits it along with the original packet to the door lock APP server. After receiving the packet, the door lock APP server parses the "multipath aggregation flag" and "slice sequence number" in the IP option header to complete the reassembly of the multipath slice packet.

[0077] (5) During the multi-path parallel delivery, gateway A continuously receives the "hop-by-hop path information" (including outgoing interface load status + delivery gateway identification information) of each slice stream (forwarded by gateway B and gateway C) fed back by RN. If gateway A finds that the load of a certain hop in the slice stream path allocated to gateway B becomes "blocked (11)" while the path load of gateway C is "idle (00)", gateway A does not need to initiate a complex step 4 negotiation. It only needs to dynamically adjust the ratio of slice packets distributed to gateway B and gateway C locally (such as adjusting X:Y to 0:1, that is, smoothly migrating all streams to gateway C) to achieve fast fine-grained traffic shaping and avoid bit rate reduction.

[0078] Beneficial effects: 1. By accurately sensing the hop-by-hop forwarding path of the video stream, other idle gateways are dynamically scheduled to forward the traffic when congestion occurs, guiding the traffic to bypass the congested nodes.

[0079] 2. By combining URPF exemption, closed-loop avoidance of path conflicts and multi-path slicing mechanism, it ensures that the traffic sent on behalf of others can safely cross the network and dynamically avoids secondary congestion, thus eliminating video stuttering and bitrate reduction.

[0080] Protection point: 1. A distributed direct feedback mechanism based on outgoing interface-level path awareness and proxy identification. A hop-by-hop option header for path records is added to the video stream packets. Routers along the path sequentially record the outgoing interface record block information for traffic forwarding, i.e., their own network node identifier + outgoing interface identifier. The last-hop router extracts this outgoing interface-level path information to generate a hop-by-hop path feedback packet. At the same time, it also identifies the "proxy gateway IP address" field written by the proxy gateway itself in the option header. In addition to feeding back to the source gateway, it also directly unicasts a feedback packet to the proxy gateway. This enables the source gateway to accurately obtain the forwarding path of the video stream, including both direct forwarding and proxy traffic packets, while the proxy gateway can independently obtain the proxy traffic forwarding path without secondary synchronization with the source gateway.

[0081] 2. Reliable Decision Verification and URPF Exemption Mechanism for Cross-Gateway Transmission. During the transmission decision phase, the source gateway performs dual path verification on candidate gateways: first, it extracts representative actual flow paths from the candidate gateways for cross-comparison to eliminate invalid false congestion avoidance caused by load balancing across equivalent multi-paths; second, for cross-segment tunnel transmission, it verifies whether the tunnel establishment path avoids congestion points to prevent the outer encapsulation from getting stuck in secondary congestion during transport. During the transmission execution phase, to address the URPF detection failure issue caused by retaining the original source IP in the transmission traffic packets, the transmission gateway reuses the 0th bit of the reserved field in the "Path Record Hop-by-Hop Options Header" as the URPF exemption flag and sets it to 1; routers along the route parse this flag, and if it is 1, they skip the URPF detection, thus achieving secure traversal of cross-gateway transmission traffic.

[0082] 3. Dynamic closed-loop path conflict avoidance and progressive rescheduling mechanism based on dual verification. After receiving the actual path feedback from the last-hop router for the traffic being sent, the source gateway performs dual verification: first, it verifies whether the sent path still contains the original congestion point; second, it cross-compares the sent path with the remaining local traffic paths to see if link contention occurs. If the verification fails, the local policy route correction of the sending gateway is triggered first. That is, the source gateway sends a path redirection message containing a list of conflicting paths to be excluded to the sending gateway. The sending gateway confirms the current path according to its local mapping table and issues a policy route to force the next hop to bypass the conflicting node. If there is no available non-conflicting path locally, the sending is withdrawn and renegotiation is triggered. That is, the source gateway sends a sending withdrawal message to the sending gateway to reclaim the sent traffic and carries the "excluded path list" in the resent multicast negotiation request, requiring the responding gateway to avoid not only the original congestion point but also overlapping links. This progressively achieves dynamic closed-loop scheduling to prevent secondary congestion.

[0083] 4. Multi-path parallel forwarding and proactive congestion prevention mechanism based on packet-level stream slicing. When at least one of the following conditions is met (① a warning is detected that the outgoing interface load status on the video stream path is in a state of alert; ② after congestion occurs, there is no single forwarding gateway with a default outgoing path that can avoid the congestion point), the source gateway triggers a multi-gateway slice negotiation request: The source gateway sends a slice negotiation request, triggering candidate gateways to traverse local equal-cost and non-equal-cost routes for deep path investigation. After confirming the existence of a non-default alternative path that avoids the congestion point, the single video stream is sliced ​​at the IP packet level, and the sliced ​​packets are distributed to multiple forwarding gateways proportionally according to the available load of the candidate gateways; after receiving the sliced ​​packets, the forwarding gateways forcibly issue policy routes according to the alternative paths, directing the sliced ​​packets to... The packet is redirected to a non-default outgoing interface for forwarding. Simultaneously, the proxy gateway reuses a reserved field in the "Path Record Hop-by-Hop Options Header," defining its first bit as a multi-path aggregation identifier and bits 2-17 as a slice sequence number. The proxy gateway writes its own IP address into the proxy gateway's IP address field during forwarding, enabling the server to reassemble out-of-order packets based on the aggregation identifier and sequence number. Routers along the route add an "Outgoing Interface Load Status" entry to the outgoing interface record block. Furthermore, during proxying, the source gateway dynamically adjusts the proportion of sliced ​​packets distributed to different proxy gateways locally based on changes in the load status of each path reported by the last-hop router, achieving fine-grained, second-level smooth traffic migration and avoiding bitrate degradation.

[0084] Another embodiment of the present invention provides a system for door lock flow scheduling, see [link to relevant documentation]. Figure 3 The system may include: The perception module 301 is used for path perception and status maintenance: based on the transmission of the door lock video stream packet on the forwarding path, the source gateway inserts a custom path record hop-by-hop option header into the packet, and each network node along the way records its outgoing interface information in the option header in sequence. The last hop node extracts the complete path information and feeds it back to the source gateway to obtain the actual forwarding path of the video stream. The detection module 302 is used for congestion detection and proxy negotiation: based on the alarm notification triggered when the network node detects congestion at the outgoing interface, the source gateway negotiates with the candidate gateways in a multicast manner, and determines the proxy gateway that can avoid the congestion point based on the comparison results of the default outgoing path of each candidate gateway and the congestion location. The proxy module 303 is used for cross-gateway proxying and exempt forwarding: based on the processing of the source gateway distributing the congested flow to the proxy gateway, the proxy gateway sets the URPF exempt flag when forwarding the traffic, and enables the upstream router to skip the source address verification according to the flag, so as to realize the legitimate traversal of the proxy traffic. The adjustment module 304 is used for closed-loop adjustment and dynamic optimization: based on the actual path feedback of the proxy flow received by the source gateway, the proxy path and the local remaining traffic path are double-checked, and if the check fails, path correction or cancellation of renegotiation is triggered to form a closed-loop scheduling to prevent secondary congestion.

[0085] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0086] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0087] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0088] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for door lock flow scheduling, characterized in that, The method includes: Path awareness and state maintenance: Based on the transmission of the door lock video stream packet on the forwarding path, the source gateway inserts a custom path record hop-by-hop option header into the packet. Each network node along the way records its outgoing interface information in the option header in sequence. The last hop node extracts the complete path information and feeds it back to the source gateway to obtain the actual forwarding path of the video stream. Congestion detection and proxy negotiation: Based on the alarm notification triggered when the network node detects congestion on the outgoing interface, the source gateway negotiates with the candidate gateways via multicast and determines the proxy gateway that can avoid the congestion point based on the comparison results of the default outgoing path of each candidate gateway and the congestion location. Cross-gateway forwarding and exemption forwarding: Based on the processing of the source gateway distributing congested traffic to the forwarding gateway, the forwarding gateway sets the URPF exemption flag when forwarding the traffic, and enables the upstream router to skip the source address verification based on the flag, thus realizing the legitimate traversal of the forwarded traffic; Closed-loop adjustment and dynamic optimization: Based on the actual path feedback of the proxy flow received by the source gateway, the proxy path and the local remaining traffic path are double-checked, and if the check fails, path correction or cancellation of renegotiation is triggered to form a closed-loop scheduling to prevent secondary congestion.

2. The method according to claim 1, characterized in that, The path awareness and state maintenance include: Option header insertion and outgoing interface record: Based on the path record inserted by the source gateway between the IP header and the transport layer header of the video stream packet, the hop-by-hop option header is inserted by each network node along the way when forwarding the packet, and the network node identifier of the node and the outgoing interface identifier of the forwarding interface are written into the outgoing interface record block list of the option header in sequence. Last-hop path extraction: When the packet arrives at the destination edge router, the router identifies itself as the last-hop node, extracts all accumulated outgoing interface record block information in the option header, and generates hop-by-hop path information containing flow identifiers and ordered path lists; Path information feedback: Based on the hop-by-hop path information generated by the last hop node, encapsulate it into a hop-by-hop path feedback message and send it to the source gateway; Mapping table maintenance: Based on the hop-by-hop path feedback messages received by the source gateway, parse and store the mapping relationship between the five-tuple of the video stream and the ordered path list to obtain the locally maintained path mapping table.

3. The method according to claim 2, characterized in that, The congestion detection and proxy negotiation include: Congestion alarm trigger: When a network node detects that the traffic load of its outgoing interface exceeds a preset threshold, it extracts the five-tuple of the video stream passing through the outgoing interface, determines the first-hop router to the source network segment according to the source network segment-first-hop mapping table, and sends a congestion alarm notification message containing the congested node identifier, the congested outgoing interface identifier, and the list of affected flows to the first-hop router. Then, the first-hop router and subsequent routers along the way forward the congestion alarm notification message back to the source gateway hop by hop according to the matching logic of the source network segment-first-hop mapping table. Multicast negotiation request: Based on the congestion alarm notification received by the source gateway, a negotiation request message containing the current load, congestion information and an initially empty exclusion path list is sent to other gateways via multicast. Candidate gateway response: After receiving the negotiation request message, the candidate gateway parses the destination IP of the affected flow and queries the local routing or path mapping table to determine the default outgoing path to the destination. If the default outgoing path does not contain a congestion point, it unicasts a negotiation response message containing available load and representative path information to the source gateway. Data transmission decision and path verification: Based on the negotiation response messages received by the source gateway within a set time, dual path verification is performed by combining the available load and representative path information of each candidate gateway. This includes verifying whether the data transmission path of the candidate gateway avoids congestion points, and verifying whether the tunnel establishment path avoids congestion points when the source gateway and the candidate gateway are in different network segments, thus selecting the optimal data transmission gateway.

4. The method according to claim 3, characterized in that, The cross-gateway forwarding and exemption forwarding include: Traffic forwarding on behalf of others: After determining the forwarding gateway and the set of forwarding flows based on the source gateway, a forwarding execution notification message containing a list of forwarding flow identifiers is sent to the forwarding gateway, and the video stream data packets that need to be split are forwarded to the forwarding gateway. Among them, if the source gateway and the forwarding gateway are in the same network segment, the source gateway does not change the source and destination IP of the original IP packet, but only replaces the source and destination MAC before sending it to the forwarding gateway; if the source gateway and the forwarding gateway are in different network segments, the source gateway encapsulates the original IP packet using an IP-in-IP tunnel and sends it to the forwarding gateway. Traffic identification on behalf of others: After receiving the data packet, the gateway on behalf of others extracts its five-tuple and matches it with the traffic on behalf of others policy table generated locally based on the traffic on behalf of others execution notification message. If the match is found, it is confirmed as legitimate traffic on behalf of others. Specifically, for packets in the same network segment, the five-tuple is extracted based on the destination MAC address being the same as the packet but the destination IP address being different from the packet. For packets in different network segments, the inner packet five-tuple is extracted after decapsulation. URPF Exemption Flag Setting: After the proxy gateway confirms the proxy traffic and prepares to forward it upstream, the URPF exemption flag is set in the reserved field of the hop-by-hop option header of the path record to mark the packet as proxy traffic; Exemption forwarding execution: After receiving a packet carrying the URPF exemption flag from the upstream router, the router parses the option header and checks the flag. If the flag is valid, the router skips the unicast reverse path forwarding detection, forwards the packet normally according to the destination IP, and continues to record the outgoing interface information of this node when forwarding on the outgoing interface.

5. The method according to claim 4, characterized in that, The closed-loop adjustment and dynamic optimization include: Dual verification of the forwarding path: When the forwarding gateway writes its own IP address into the reserved field of the hop-by-hop option header of the path record during forwarding, the last hop node recognizes this field and sends hop-by-hop path feedback messages to both the source gateway and the forwarding gateway. After receiving the hop-by-hop path feedback message for the forwarding traffic from the last hop node, the source gateway performs dual verification, including the first verification to check whether the ordered path list of the forwarding path still contains the original congestion point, and the second verification to cross-compare the forwarding path with the ordered path list of other video streams that the source gateway is currently forwarding to check whether there is the same outgoing interface combination. Progressive rescheduling: Based on the result of the double verification failing, the local policy route correction of the proxy gateway is triggered first. That is, the source gateway sends a path redirection message containing a list of conflict paths to be excluded to the proxy gateway. The proxy gateway confirms the current path according to the local path mapping table and issues policy routes to force subsequent messages to bypass the conflict nodes. Cancellation and Renegotiation of Submission: If the policy route correction fails due to the lack of available non-conflicting paths on the local submission gateway, the source gateway sends a cancellation message to the submission gateway to reclaim the submission traffic. The source gateway also carries an exclusion path list in the resent multicast negotiation request, requesting the responding gateway to avoid the original congestion point and overlapping links. Local degradation processing: If no other gateway responds with a negotiation response message, the source gateway reclaims all traffic sent on behalf of the user and forwards it locally using a reduced bitrate method.

6. The method according to claim 5, characterized in that, The method also includes multi-path parallel proxying and proactive congestion prevention based on stream slices: Active congestion risk detection: When each network node along the route writes the real-time load status of the current interface into the outgoing interface record block, the source gateway periodically traverses the ordered path list of each video stream in the local path mapping table to check whether the outgoing interface load status of any hop reaches the warning threshold, i.e. the early soft threshold. If so, the stream is determined to have congestion risk in advance. Multi-gateway slice negotiation: Based on the detection of congestion risk or the absence of a single available proxy gateway, the source gateway sends a slice negotiation request via multicast, triggering candidate gateways to perform deep path investigation. If there is an alternative path that avoids the congestion point or is excluded from the path list, it replies with a negotiation response message, carrying the available load and the expected next hop identifier of the alternative path. Message-level stream slicing and distribution: Based on the negotiation response message received by the source gateway, determine the set of candidate gateways that can be forwarded and their available load, slice the video stream to be forwarded at the IP packet level, and distribute the sliced ​​packets to multiple forwarding gateways according to the available load ratio. Slice packet identification and forwarding: After the proxy gateway receives the slice packet, it reuses the reserved field of the hop-by-hop option header of the path record to set the multi-path aggregation flag and slice sequence number, and writes the proxy gateway's own IP address into the proxy gateway IP address field of the reserved field. Then, according to the alternative path distribution policy determined during negotiation, the slice packet is directed to the non-default outgoing interface for forwarding. Server-side reassembly and dynamic optimization: After receiving the sliced ​​message, the door lock APP server parses the multi-path aggregation flag and slice sequence number in the option header to complete the reassembly of the multi-path sliced ​​message; at the same time, the source gateway dynamically adjusts the proportion of sliced ​​messages distributed to different proxy gateways based on the load status changes of each sliced ​​flow path outgoing interface fed back by the last hop node, so as to achieve fine-grained smooth traffic migration.

7. A system for door lock flow scheduling, characterized in that, The system includes: The perception module is used for path awareness and status maintenance: based on the transmission of the door lock video stream packet on the forwarding path, the source gateway inserts a custom path record hop-by-hop option header into the packet. Each network node along the way records its outgoing interface information in the option header in sequence. The last hop node extracts the complete path information and feeds it back to the source gateway to obtain the actual forwarding path of the video stream. The detection module is used for congestion detection and proxy negotiation: based on the alarm notification triggered when the network node detects congestion on the outgoing interface, the source gateway negotiates with the candidate gateways in a multicast manner, and determines the proxy gateway that can avoid the congestion point based on the comparison results of the default outgoing path of each candidate gateway and the congestion location. The proxy module is used for cross-gateway proxying and exempt forwarding: based on the processing of the source gateway distributing congested traffic to the proxy gateway, the proxy gateway sets the URPF exempt flag when forwarding the traffic, and enables the upstream router to skip the source address verification based on the flag, so as to realize the legitimate traversal of the proxy traffic; The adjustment module is used for closed-loop adjustment and dynamic optimization: based on the actual path feedback of the proxy flow received by the source gateway, the proxy path and the local remaining traffic path are double-checked, and if the check fails, path correction or cancellation of renegotiation is triggered to form a closed-loop scheduling to prevent secondary congestion.

8. The system according to claim 7, characterized in that, The sensing module is specifically used for: Option header insertion and outgoing interface record: Based on the path record inserted by the source gateway between the IP header and the transport layer header of the video stream packet, the hop-by-hop option header is inserted by each network node along the way when forwarding the packet, and the network node identifier of the node and the outgoing interface identifier of the forwarding interface are written into the outgoing interface record block list of the option header in sequence. Last-hop path extraction: When the packet arrives at the destination edge router, the router identifies itself as the last-hop node, extracts all accumulated outgoing interface record block information in the option header, and generates hop-by-hop path information containing flow identifiers and ordered path lists; Path information feedback: Based on the hop-by-hop path information generated by the last hop node, encapsulate it into a hop-by-hop path feedback message and send it to the source gateway; Mapping table maintenance: Based on the hop-by-hop path feedback messages received by the source gateway, parse and store the mapping relationship between the five-tuple of the video stream and the ordered path list to obtain the locally maintained path mapping table.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images