Announcing method, traffic control method and related devices

Abstract

This application discloses an announcement method, a flow control method, and related apparatus, belonging to the field of network technology. The method includes: a first forwarding node receiving an announcement message carrying a target identifier indicating a target forwarding path; and sending an announcement message to a target node to instruct the target node to control subsequent data packets on the target forwarding path, wherein the target node is an upstream node of the first forwarding node. This application, by having the forwarding node actively announce the status of the forwarding path to the upstream forwarding node or the sender, effectively responds to events such as congestion / failures on the forwarding path. Furthermore, by having the forwarding node actively detect the status of the forwarding path, it comprehensively covers the status of all forwarding paths in the network, maximizing bandwidth utilization. It also allows for direct reporting of the detected status of the forwarding path, reducing feedback latency and improving the speed of event response.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a notification method, a flow control method, and related apparatus. Background Technology

[0002] Flow-based load balancing forwards data packets from the same data stream along the same path, which works well when there are many data streams. However, in artificial intelligence (AI) scenarios, the number of data streams is usually small, but each stream has a large bandwidth. Flow-based load balancing is prone to routing conflicts, mapping different data streams to the same path, causing network congestion and significantly reducing network bandwidth utilization. Compared to flow-based load balancing, packet-based load balancing routes data packets from the same data stream to different paths, achieving more granular load balancing and mitigating routing conflicts. Therefore, AI clusters use packet-based load balancing technology to improve network bandwidth utilization. Accordingly, how to perform event notification and flow control in packet-based load balancing scenarios has become a pressing issue. Summary of the Invention

[0003] This application provides a notification method, a flow control method, and related apparatus, which can comprehensively cover the status of each forwarding path in the network, maximize bandwidth utilization, and reduce communication overhead. The technical solution is as follows:

[0004] In a first aspect, a notification method is provided, the method comprising: a first forwarding node receiving a notification message, the notification message carrying a target identifier, the target identifier indicating a target forwarding path; the first forwarding node sending a notification message to a target node to instruct the target node to control subsequent data packets of the target forwarding path, the target node being an upstream node of the first forwarding node.

[0005] Forwarding nodes proactively send announcement messages about the target forwarding path to upstream nodes. The upstream nodes then control the subsequent data packets sent to the target forwarding path, thereby responding to events such as congestion or failures on that path. This approach does not rely on the state of data packets to reflect the state of the target forwarding path. This method effectively addresses congestion or failures on the target forwarding path. Furthermore, by proactively sending announcement messages to upstream nodes, the status of all forwarding paths in the network is comprehensively covered, maximizing bandwidth utilization.

[0006] The notification message can be generated by the first forwarding node, or it can be received from other forwarding nodes. The notification message can be generated when a congestion / failure event occurs on the target forwarding path, including both actual failure events and early warning failure events that have not yet occurred.

[0007] In one possible implementation, the target node is an upstream forwarding node of the first forwarding node. For example, the target node is an upstream forwarding node adjacent to the first forwarding node; or, the target node is the sender.

[0008] In one possible implementation, the target identifier includes the identifier of the target forwarding path.

[0009] In one possible implementation, the target identifier includes the entropy value of the target data packet and the destination address.

[0010] The target data packet is any data packet forwarded through the target forwarding path. Forwarding nodes forward data packets using routing tables, which include multiple equal-cost multipath routing (ECMP) groups. An ECMP group indicates multiple forwarding paths to the same destination address. Each ECMP group contains multiple entries, each indicating the address information of the outgoing port or next-hop node corresponding to the destination address. The entropy value of the data packet is used for load balancing, and each entry in each ECMP group corresponds to an entropy value. During the forwarding of the target data packet through the load balancing mechanism, the corresponding ECMP group can be determined from the routing table based on the destination address of the target data packet. Then, based on the entropy value of the target data packet, the address information of the corresponding outgoing port or next-hop node can be determined from the entries included in that ECMP group, and the target data packet is then sent. In other words, in a load balancing scenario, a forwarding path can be uniquely determined by the entropy value and destination address of the data packet. Therefore, the entropy value and destination address of the target data packet can uniquely identify the target forwarding path.

[0011] For flow-by-flow load balancing, the entropy values ​​of all data packets within the same data flow are the same, ensuring that all data packets within the same data flow are forwarded through the same forwarding path. For packet-by-packet load balancing, the entropy values ​​of the data packets within the same data flow are different, ensuring that data packets within the same data flow can be forwarded through multiple forwarding paths.

[0012] The entropy value of a data packet includes either a first entropy value or a second entropy value. For flow-based load balancing, the first entropy value is obtained by hashing the data packet's characteristic parameters, or by hashing the data packet's characteristic parameters and a hash seed; the second entropy value is the data packet's hash seed. For packet-based load balancing, the sender determines the first and second entropy values ​​using a load balancing algorithm. Of course, for both flow-based and packet-based load balancing, the first and second entropy values ​​can be determined in other ways, and this application does not limit this approach.

[0013] The characteristic parameters of a data packet can include any one or more parameters from the packet header. For example, the characteristic parameters of a data packet may include a 5-tuple, a 7-tuple, a 4-tuple, a 2-tuple, etc. The hash seed can be obtained by modifying the characteristic parameters of the data packet; for example, by modifying any one or more of the characteristic parameters, or by adding other parameters to the characteristic parameters.

[0014] In one possible implementation, the advertisement message is a UDP message, the payload of which includes a destination identifier; or, the advertisement message is an IP message, the payload of which includes a destination identifier.

[0015] When the target identifier includes the identifier of the target forwarding path, the advertisement message includes a path identifier field, which carries the identifier of the target forwarding path. When the target identifier includes the entropy value of the target data packet and the destination address, the advertisement message includes an entropy value field and a destination address field, where the entropy value field carries the entropy value of the target data packet and the destination address field carries the destination address of the target data packet.

[0016] When the path identifier field carries an identifier of the target forwarding path, if the advertisement message is a UDP message, the payload of the UDP message includes the path identifier field; if the advertisement message is an IP message, the payload of the IP message includes the path identifier field. When the entropy field carries the entropy value of the target data packet and the destination address field carries the destination address of the target data packet, if the advertisement message is a UDP message, the payload of the UDP message includes both the entropy field and the destination address field; if the advertisement message is an IP message, the payload of the IP message includes both the entropy field and the destination address field.

[0017] In one possible implementation, the notification message also carries congestion location information and / or congestion degree information, whereby the congestion location information indicates the location of congestion in the target forwarding path and the congestion degree information indicates the degree of congestion in the target forwarding path.

[0018] The location of congestion in the target forwarding path is the queue of the ingress or egress port of the forwarding node. Congestion location information can be the identifier of the forwarding node, or other information used to indicate the forwarding node. Alternatively, congestion location information can also be the identifier of the link corresponding to the queue of the congested ingress or egress port, the identifiers of the forwarding nodes at both ends of that link, or other information used to indicate the link.

[0019] The degree of congestion in the target forwarding path can be characterized by queue occupancy, congestion level, or available bandwidth, and can also be characterized by other methods, such as the percentage of available bandwidth fully utilized, average packet forwarding delay, and average packet queuing delay. In other words, the degree of congestion in the target forwarding path can be characterized by, but is not limited to, queue occupancy, congestion level, available bandwidth, the percentage of available bandwidth fully utilized, average packet forwarding delay, and average packet queuing delay; this application does not limit this to any particular method.

[0020] If the announcement message is a UDP message, the payload of the UDP message includes congestion location information and / or congestion level information; if the announcement message is an IP message, the payload of the IP message includes congestion location information and / or congestion level information.

[0021] In some embodiments, the notification message includes a congestion location field and a congestion level field, wherein the congestion location field carries congestion location information and the congestion level field carries congestion level information.

[0022] If the advertisement message is a UDP message, the payload of the UDP message includes a congestion location field and a congestion level field. If the advertisement message is an IP message, the payload of the IP message includes a congestion location field and a congestion level field.

[0023] In one possible implementation, the notification message also carries fault location information and / or fault type, whereby the fault location information indicates the location of the fault in the target forwarding path and the fault type indicates the type of fault that occurred in the target forwarding path.

[0024] The location of a failure in the target forwarding path can be a forwarding node or a link between forwarding nodes. That is, the failure could occur at a forwarding node within the target forwarding path, or it could be a failure in the link between forwarding nodes within the target forwarding path. Therefore, if a forwarding node in the target forwarding path fails, the failure location information can be the identifier of that forwarding node, or other information used to indicate that forwarding node. If a link between forwarding nodes in the target forwarding path fails, the failure location information can be the identifier of that link, the identifiers of the forwarding nodes at both ends of that link, or other information used to indicate that link.

[0025] The types of faults occurring in the target forwarding path can include line interruption, optical module flashover, laser failure, optical power below a first power threshold, and optical power above a second power threshold. The first power threshold is less than the second power threshold. The first and second power thresholds are preset thresholds, which can be adjusted according to requirements in practical applications; this application does not impose any limitations on this.

[0026] If the notification message is a UDP message, the payload of the UDP message includes fault location information and / or fault type; if the notification message is an IP message, the payload of the IP message includes fault location information and / or fault type.

[0027] In one possible implementation, the notification message includes a fault location field and a fault type field, whereby the fault location field carries fault location information and the fault type field carries the fault type.

[0028] If the announcement message is a UDP message, the payload of the UDP message includes a fault location field and a fault type field. If the announcement message is an IP message, the payload of the IP message includes a fault location field and a fault type field.

[0029] In one possible implementation, the notification message is used to notify of a fault. In this case, the notification message also carries fault status information, which is used to indicate whether a fault has occurred in the target forwarding path and the severity of the fault, or to indicate whether a fault has not occurred in the target forwarding path and the probability that a fault is about to occur.

[0030] In other words, this notification message can not only notify of faults that have occurred, but also notify of the probability of a fault occurring if no fault has occurred. This can prevent data packets from being sent to faulty or potentially faulty forwarding paths in a timely manner.

[0031] Secondly, a notification method is provided, comprising: a target node receiving a notification message from a first forwarding node, the notification message carrying a target identifier, the target identifier indicating a target forwarding path, the first forwarding node being a downstream forwarding node of the target node; and the target node controlling subsequent data packets of the target forwarding path.

[0032] After receiving the advertisement message from the first forwarding node, the target node can control subsequent data packets on the target forwarding path. This control is not based on the state of the data packets reflecting the state of the target forwarding path. This approach effectively responds to events such as congestion or failures on the target forwarding path. Furthermore, since the advertisement message is proactively reported by the forwarding node, all forwarding nodes in the network can comprehensively cover all forwarding paths, thereby achieving data packet control for each forwarding path and maximizing bandwidth utilization.

[0033] In one possible implementation, the target node is the sender.

[0034] In one possible implementation, the notification message also carries congestion location information, which indicates the location of congestion in the target forwarding path; the target node controls subsequent data packets in the target forwarding path, including: if the congestion location information indicates that a forwarding node connected to the receiver is congested, the target node reduces the rate at which data packets are sent to the receiver.

[0035] If congestion occurs at the forwarding node connected to the receiver (i.e., the last-hop forwarding node is congested), it indicates that the amount of data sent from the sender to the receiver far exceeds the amount of data the receiver can receive. Therefore, when the destination node is the sender, the sender can directly reduce the rate at which it sends data packets to the receiver, thereby reducing the amount of data sent from the sender to the receiver. This reduces the number of data packets buffered by the forwarding nodes connected to the receiver, thus alleviating congestion.

[0036] In one possible implementation, there may be multiple senders sending data packets to the receiver. In this case, the first forwarding node can send a notification message to each or some of the senders, causing each or some of the senders to reduce the speed at which they send data packets to the receiver.

[0037] Before the target node reduces the rate at which it sends data packets to the receiver, it can also receive congestion flow indication information from the receiver. This congestion flow indication information is used to indicate the congested flow being sent to the receiver. In this case, the process of the target node reducing the rate at which it sends data packets to the receiver includes: the target node reducing the rate at which it sends data packets to the congested flow.

[0038] In other words, the target node reduces the sending rate of data packets for the congested flow without reducing the sending rate of data packets for other data flows, thereby selectively reducing the sending rate of data packets and avoiding impacting data packets for other data flows.

[0039] In one possible implementation, the notification message also carries congestion level information, which indicates the degree of congestion in the target forwarding path; the target node reduces the rate at which it sends data packets to the receiver, including: the target node reduces the rate at which it sends data packets to the receiver based on the congestion level information.

[0040] Reducing the data packet sending rate based on congestion level information is one example. In practical applications, other methods can also be used to reduce the data packet sending rate. For example, the data packet sending rate can be reduced in fixed steps each time, or the data packet sending rate can be reduced to 0 directly.

[0041] In one possible implementation, the notification message also carries congestion location information, which indicates the location where congestion occurs in the target forwarding path; the target node controls subsequent data packets in the target forwarding path, including: if the congestion location information indicates that congestion has occurred at an intermediate forwarding node, the target node reduces the proportion of traffic allocated to the target forwarding path.

[0042] Intermediate forwarding nodes refer to all forwarding nodes in the target forwarding path except for the head node and tail node. The head node is the forwarding node connected to the sender in the target forwarding path, also known as the first-hop forwarding node. The tail node is the forwarding node connected to the receiver in the target forwarding path, also known as the last-hop forwarding node.

[0043] If an intermediate forwarding node becomes congested, it indicates that some links in the target forwarding path are still open. Therefore, when the target node is the sender, the sender directly reduces the proportion of traffic allocated to the target forwarding path. In this way, during load balancing, the number of data packets forwarded through the target forwarding path can be reduced, thereby reducing the number of data packets buffered by the congested intermediate node and alleviating the congestion.

[0044] In one possible implementation, the load balancing process is achieved by assigning a load weight to each forwarding path. In this case, the proportion of traffic allocated to the target forwarding path can be characterized by the load weight of the target forwarding path.

[0045] In another possible implementation, the load balancing process is achieved by polling the forwarding path. In this case, the proportion of traffic allocated to the target forwarding path can be characterized by the number of polls on the target forwarding path.

[0046] If the proportion of traffic allocated to the target forwarding path is characterized by load balancing weights, then the load balancing weights of the target forwarding path can be reduced. If the proportion of traffic allocated to the target forwarding path is characterized by the number of polling rounds, then the number of polling rounds of the target forwarding path can be reduced.

[0047] In one possible implementation, the notification message also carries congestion level information, which indicates the degree of congestion in the target forwarding path; the target node reduces the proportion of traffic allocated to the target forwarding path, including: the target node reduces the proportion of traffic allocated to the target forwarding path based on the congestion level information.

[0048] Since congestion information is used to indicate the degree of congestion in the target forwarding path, reducing the proportion of traffic allocated to the target forwarding path based on congestion information can match the distribution ratio of data packets with the degree of congestion, thereby alleviating the congestion in the target forwarding path as quickly as possible and improving the efficiency of congestion control.

[0049] The four implementation methods for reducing the proportion of traffic allocated to the target forwarding path based on congestion level information are just one example. In practical applications, other methods can also be used to reduce the proportion of traffic allocated to the target forwarding path. For example, the proportion of traffic allocated to the target forwarding path can be reduced in fixed steps each time, or the proportion of traffic allocated to the target forwarding path can be reduced to 0 directly.

[0050] In one possible implementation, the notification message is a fault notification message; the target node controls subsequent data packets on the target forwarding path, including: the target node reducing the proportion of traffic allocated to the target forwarding path.

[0051] When the notification message is a fault notification message, it indicates that the target forwarding path is currently faulty or about to fail with a high probability of failure. To avoid sending data packets to the faulty or impending faulty forwarding path, the sender directly reduces the proportion of traffic allocated to the target forwarding path. This minimizes the number of data packets sent to the faulty or impending faulty forwarding path during load balancing.

[0052] In one possible implementation, the target node is the upstream forwarding node of the first forwarding node. For example, the target node is the upstream forwarding node adjacent to the first forwarding node.

[0053] In one possible implementation, the proportion of traffic allocated to the target forwarding path can be reduced to 0. That is, the target forwarding path is no longer used to forward data packets, thus avoiding the impact of existing or impending failures on data forwarding.

[0054] In one possible implementation, the notification message also carries the fault type. If the fault type is a line interruption or optical module flashover, the proportion of traffic allocated to the target forwarding path is reduced to 0. If the fault type is a laser failure and there is no non-failed laser, the proportion of traffic allocated to the target forwarding path is reduced to 0.

[0055] Among them, laser failure and no non-failed lasers include: only one laser and the laser is failed, or multiple lasers and all of them are failed.

[0056] If the fault type is line interruption, optical module flashover, or laser failure and there is no non-failed laser, it indicates that the target forwarding path can no longer transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced to 0 to prevent data packets from being sent to the target forwarding path and affecting the transmission of data packets.

[0057] In one possible implementation, the notification message also carries fault status information. If the fault status information indicates that a fault has occurred in the target forwarding path and the severity of the fault, then if the fault type is a line interruption, optical module flashover, or laser failure with no unfailed lasers, the proportion of traffic allocated to the target forwarding path is reduced to 0. If the fault status information indicates that no fault has occurred in the target forwarding path and the probability of a fault occurring is greater than a first probability threshold, it indicates that the probability of a fault occurring is high and a fault may occur immediately. In this case, if the fault type is a line interruption, optical module flashover, or laser failure with no unfailed lasers, the proportion of traffic allocated to the target forwarding path is reduced to 0.

[0058] The first probability threshold indicates a high probability of failure, suggesting that a failure may occur very soon. This first probability threshold is set, but in practical applications, it can be adjusted according to different needs.

[0059] In one possible implementation, the proportion of traffic allocated to the target forwarding path can be reduced, but not reduced to zero. That is, the number of packets forwarded by the target forwarding path can be reduced.

[0060] In one possible implementation, the notification message also carries the fault type. If the fault type is laser failure and there are still unfailed lasers, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0. If the fault type is optical power below a first power threshold or optical power above a second power threshold, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0.

[0061] If the fault type is laser failure but there are still surviving lasers, it indicates that other lasers are still operational, the optical module is still functional, and the target forwarding path can still transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to zero, and the target forwarding path can still share the load of other equivalent paths. If the fault type is optical power below the first power threshold or optical power above the second power threshold, it indicates that the optical module is still operational, and the target forwarding path can still transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to zero, and the target forwarding path can still share the load of other equivalent paths.

[0062] In one possible implementation, the notification message also carries fault status information. If the fault status information indicates that a fault has occurred in the target forwarding path and the severity of the fault, then if the fault type is laser failure and there are still unfailed lasers, the optical power is lower than a first power threshold, or the optical power is higher than a second power threshold, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is greater than a second probability threshold and less than a first probability threshold, then the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is not greater than the second probability threshold, then the proportion of traffic allocated to the target forwarding path is not reduced.

[0063] If the fault status information indicates a fault has occurred in the target forwarding path and the severity of the fault is specified, then if the fault type is laser failure and there are still unfailed lasers, the optical power is below the first power threshold, or the optical power is above the second power threshold, it indicates that the optical module can still operate, and the target forwarding path can still transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0, and the target forwarding path can still share the load of other equivalent paths. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is greater than the second probability threshold but less than the first probability threshold, it indicates that the probability of a fault occurring is relatively high. In this case, regardless of the fault type, the proportion of traffic allocated to the target forwarding path can be reduced to 0, thereby reducing the impact of the potentially faulty forwarding path on data packets. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is not greater than the second probability threshold, it indicates that the probability of a fault occurring is relatively low, and the proportion of traffic allocated to the target forwarding path is not reduced.

[0064] The second probability threshold is lower than the first probability threshold. The second probability threshold indicates a higher probability of failure, but not an immediate one. The second probability threshold is set, and in practical applications, it can be adjusted according to different needs.

[0065] Based on the above description, the proportion of traffic allocated to the target forwarding path can be characterized by load balancing weights or by the number of polling rounds. When a target node reduces the proportion of traffic allocated to the target forwarding path, it reduces the load balancing weights corresponding to the target forwarding path, or it reduces the number of polling rounds for the target forwarding path.

[0066] In one possible implementation, if the fault status information indicates the severity of a fault, the proportion of traffic allocated to the target forwarding path can be reduced based on the severity of the fault. Similarly, if the fault status information indicates the probability of a fault occurring, the proportion of traffic allocated to the target forwarding path can be reduced based on the probability of a fault occurring.

[0067] In one possible implementation, the notification message also carries fault location information and / or fault type. In this way, the target node can send a fault maintenance message to the network management side, so that the network management side can locate the location of the fault in the target forwarding path based on the fault location information, and then perform fault maintenance based on the fault type.

[0068] In one possible implementation, the notification message also carries fault status information. This allows the target node to determine whether to retransmit the data packet based on this fault status information. For example, if the fault status information indicates that the target forwarding path has failed, or has not failed but the probability of failure is greater than a first probability threshold, then it is determined that the data packet needs to be retransmitted. If the fault status information indicates that the target forwarding path has not failed and the probability of failure is not greater than the first probability threshold, then it is not necessary to retransmit the data packet.

[0069] In one possible implementation, the notification message also carries the header of the target data packet. In this case, the target data packet is determined to be a data packet that needs to be retransmitted, and the target data packet is retransmitted based on the header of the target data packet.

[0070] In one possible implementation, the target node is an upstream forwarding node of the first forwarding node, or the target node is an upstream forwarding node adjacent to the first forwarding node. In this case, the process by which the target node controls subsequent data packets on the target forwarding path includes: if there are multiple forwarding paths between the target node and the receiving end, adjusting the target node's local load balancing strategy and forwarding data packets through the target node's local load balancing strategy.

[0071] There are several ways to adjust the local load balancing strategy of the target node, which will be introduced below.

[0072] The first method involves forwarding each data packet along the multiple forwarding paths through the lightest-loaded path.

[0073] If the target forwarding path becomes congested or fails, the first method is equivalent to adjusting the forwarding path of the data packets, which can reduce the number of data packets on the more congested forwarding path, thus alleviating the congestion, or reduce the number of data packets sent to the failed path.

[0074] The second method is to adjust the traffic allocation ratio of the multiple forwarding paths and forward the data packets on the multiple forwarding paths according to the traffic allocation ratio of the multiple forwarding paths.

[0075] The process of adjusting the traffic allocation ratio of the multiple forwarding paths includes: determining the congestion level of the multiple forwarding paths, and adjusting the traffic allocation ratio of the multiple forwarding paths according to the congestion level, so that the traffic allocation ratio of the forwarding path with severe congestion is less than the traffic allocation ratio of the forwarding path with mild congestion.

[0076] The second method allows data packets on multiple forwarding paths to be matched with their respective path states, thereby improving bandwidth utilization.

[0077] The third approach is to set the target forwarding path to stop sending data packets if the congestion level of the target forwarding path reaches the congestion warning threshold.

[0078] For example, the forwarding table entry corresponding to the target forwarding path in the routing table of the target node is set to expire within the target duration.

[0079] The congestion warning threshold indicates that the congestion level is already very serious. If data packets are continued to be forwarded through this forwarding path at this time, serious events such as packet loss may occur. Therefore, setting the target forwarding path to stop sending data packets can promptly curb such serious events.

[0080] In one possible implementation, the method further includes: if the target node does not have a route to switch to, the target node sends an announcement message to the upstream node to instruct the upstream node to control the forwarding of subsequent data packets of the target path.

[0081] In other words, if the target node cannot control the subsequent data packets of the target forwarding path, the target node can continue to send announcement messages to the upstream node, so that the upstream node can control the subsequent data packets of the target forwarding path.

[0082] When the target node has no alternative path, it means there are no other forwarding paths between the target node and the receiver besides the target forwarding path. Alternatively, multiple forwarding paths exist between the target node and the receiver, but all of these paths have generated advertisement messages, indicating congestion or failure. In this case, the target node sends an advertisement message to upstream nodes, enabling them to promptly alleviate the congestion or failure of the target forwarding path and thus improve bandwidth utilization.

[0083] In one possible implementation, after the target node controls subsequent data packets of the target forwarding path, the method further includes: the target node receiving a release message from the first forwarding node, the release message carrying a target identifier; and the target node releasing control over subsequent data packets of the target forwarding path.

[0084] In other words, after the congestion / fault of the target forwarding path is cleared, the target node can also release control over subsequent data packets of the target forwarding path, thereby allowing the target forwarding path to forward data packets normally.

[0085] Specifically, releasing control over subsequent data packets on the target forwarding path means releasing control over subsequent data packets on the target forwarding path according to the aforementioned notification message. In other words, it restores the state to that before control was exercised over subsequent data packets on the target forwarding path according to the aforementioned notification message. For example, if the aforementioned control operation on subsequent data packets on the target forwarding path was to reduce the rate of data packets sent to the receiving end, then releasing control over subsequent data packets on the target forwarding path is to increase the rate of data packets sent to the receiving end. If the aforementioned control operation on subsequent data packets on the target forwarding path was to reduce the proportion of traffic allocated to the target forwarding path, then releasing control over subsequent data packets on the target forwarding path is to increase the proportion of traffic allocated to the target forwarding path.

[0086] In some cases, after sending a release message, the target node may not receive it. Alternatively, to avoid temporary relief from congestion / failure due to unforeseen circumstances, only to have congestion / failure recur shortly afterward, the first forwarding node can continuously send release messages to the target node within a first time period. If the target node continuously receives release messages within this first time period, it will release control over subsequent data packets on the target forwarding path, thus preventing subsequent data packets on the target forwarding path from being uncontrolled in a timely manner, or from switching back and forth between control and decontrol.

[0087] In some cases, the target node may not receive any packets. In this situation, if the target node does not receive an announcement or cancellation message from the first forwarding node within a second time period, it will release control over subsequent data packets on the target forwarding path. This allows for timely release of control over subsequent data packets on the target forwarding path, improving bandwidth utilization.

[0088] It should be noted that congestion events, failure events, or failure warning events may occur on the target forwarding path. The notification messages corresponding to these events can be sent separately, or multiple notification messages destined for the same end can be combined into one message. This can reduce the number of communications and save communication overhead.

[0089] Thirdly, a flow control method is provided, the method comprising: a second forwarding node obtaining a first code block, the first code block being used to instruct a first forwarding node to perform flow control, the first forwarding node being an upstream forwarding node of the second forwarding node; and the second forwarding node sending the first code block to the first forwarding node.

[0090] The second forwarding node instructs the first forwarding node to perform flow control through the lowest layer (i.e., physical layer) code block, without needing to go through other higher layers, thus reducing overhead.

[0091] The first code block is generated by the second forwarding node, or it can be received from other forwarding nodes.

[0092] In one possible implementation, the first forwarding node is an upstream forwarding node adjacent to the second forwarding node.

[0093] In one possible implementation, the first code block is periodically generated by the second forwarding node and sent to the first forwarding node; or, the first code block is generated by the second forwarding node and sent to the first forwarding node after detecting a congestion or fault event.

[0094] Since the code block belongs to the physical layer, the communication overhead of the physical layer is very low. Therefore, periodically generating the first code block and sending it to the first forwarding node will not cause excessive communication overhead, and it can also ensure that the data forwarding capability of the second forwarding node is synchronized to the first forwarding node in a timely manner. Although the communication overhead of the physical layer is very low, generating the first code block and sending it to the first forwarding node after detecting a congestion event, a fault event, or a fault warning event can further reduce the overhead of flow control.

[0095] In one possible implementation, the first code block carries first capability indication information, which is used to indicate the data reception capability of the ingress port of the second forwarding node.

[0096] In some cases, each ingress port of a forwarding node is configured with a buffer to store data packets received through that ingress port. In this case, the first capability indication information could be the buffer occupancy rate, occupied buffer, and / or remaining buffer of the second forwarding node's ingress port. The ingress port refers to the port that receives data sent by the first forwarding node.

[0097] The data receiving capability of the ingress port of the second forwarding node can also be characterized by other parameters, such as the average length of each queue of the ingress port, the available bandwidth of the ingress port, and the average packet queuing delay of each queue of the ingress port.

[0098] In one possible implementation, the first capability indication information is specifically used to indicate the data reception capability of the target queue at the ingress port of the second forwarding node, and the first code block also carries the priority of the target queue.

[0099] The target queue can be any one of the multiple queues at the ingress port. Of course, it can also be a queue that frequently experiences congestion, but this embodiment of the application does not limit this.

[0100] The data receiving capability of the target queue can be characterized by the length of the target queue and the data packet queuing delay of the target queue.

[0101] In the above description, the first capability indication information carried by the first code block can indicate the data reception capability of the entire ingress port or the data reception capability of the target queue of the ingress port. In this case, the first code block also carries the priority of the target queue. In another possible implementation, the first code block simultaneously carries the first capability indication information, the priority, and a priority enable flag. If the priority enable flag is invalid, it indicates that the first capability indication information is used to indicate the data reception capability of the entire ingress port. If the priority enable flag is valid, it indicates that the first capability indication information is used to indicate the data reception capability of the target queue of the ingress port, and the priority carried by the first code block is the priority of the target queue.

[0102] In one possible implementation, the first code block also carries second capability indication information, which is used to indicate the data reception capability of the shared buffer of multiple ports of the second forwarding node.

[0103] In some cases, multiple ports of a forwarding node are configured with shared buffers to store data packets forwarded through these ports. These multiple ports can be multiple inbound ports, multiple outbound ports, or a combination of both. In this case, the second capability indication information can be the occupancy rate, occupied shared buffer, and / or remaining shared buffer of the shared buffers of the multiple ports of the second forwarding node.

[0104] The data receiving capacity of a shared buffer across multiple ports can also be characterized by other parameters, such as the ratio of the total throughput to the forwarding bandwidth of these ports, and the average packet forwarding time of these ports. The total throughput of these ports refers to the amount of data in the packets forwarded by these ports. The forwarding bandwidth of these ports is the maximum amount of data in the packets that these ports can forward.

[0105] In one possible implementation, the first code block also carries check information, which is used to protect the information carried by the first ordered set code block. For example, this check information can be a CRC code.

[0106] In addition to the parameters mentioned above, the first code block can also carry other parameters, such as the number of microbursts, microburst bandwidth, microburst data volume, number of PFC pause frames, queue establishment time, queue establishment speed, packet loss rate, and queue length change rate. Specifically, the number of microbursts refers to the number of times burst traffic is forwarded. The microburst speed refers to the bandwidth of the burst traffic. The microburst data volume refers to the total data volume of the forwarded burst traffic. The number of PFC pauses refers to the number of times the PFC mechanism determines to pause data transmission; that is, the number of times the PFC mechanism determines congestion and sends PFC frames to upstream nodes. The queue establishment time refers to the time elapsed from when the queue is empty to the current queue status. The packet loss rate can be statistically analyzed according to different situations, such as packet loss rate due to congestion or packet loss rate due to faults.

[0107] In one possible implementation, the first code block carries a fault type, which indicates the type of fault occurring in the second forwarding node, or the type of fault that is about to occur and is being warned.

[0108] Based on the above description, the first code block can be generated and sent periodically, or it can be generated and sent after a fault event has occurred or is about to occur. If the first code block is generated and sent periodically, then in the case where no fault has occurred, the fault type is empty or a specified value; in the case where a fault has occurred or is about to occur, the fault type is the type of the fault that has occurred or the type of the fault that is about to occur.

[0109] The fault types can include line interruption, optical module flashover, laser failure, optical power below the first threshold, or optical power above the second threshold.

[0110] In one possible implementation, the first code block also carries fault status information, which is used to indicate whether the second forwarding node has failed and the severity of the failure, or to indicate whether the second forwarding node has not failed and the probability of failure.

[0111] In one possible implementation, the fault type and fault status information can be determined through the health metrics of the second forwarding node. These health metrics include the frame loss rate (FLR) and bit error rate (BER) determined by CRC, with BER including both pre-forward error correction (Pre-FEC) BER and post-forward error correction (Post-FEC) BER. They also include the optical module's receive / transmit power, bias current, voltage, temperature, status, and signal-to-noise ratio.

[0112] For example, the optical module's receive / emit power, bias current, voltage, temperature, status, signal-to-noise ratio, etc., are used to determine whether the optical module has failed, and in the case where no failure has occurred, these parameters are used to determine the probability of failure.

[0113] In the above description, the fault status information is used to indicate whether the second forwarding node has failed and the severity of the failure, or to indicate whether the second forwarding node has not failed and the probability of failure. That is, the fault status information includes a fault flag and fault severity information. The fault flag indicates whether a fault has occurred. When the fault flag indicates a fault has occurred, the fault severity information indicates the severity of the fault. When the fault flag indicates no fault has occurred, the fault severity information indicates the probability of failure.

[0114] In one possible implementation, the first code block is an ordered set encoded block in 64B / 66B format. Of course, the first code block can also be other code blocks from the physical layer, and this application does not limit this.

[0115] Fourthly, a flow control method is provided, the method comprising: a first forwarding node receiving a first code block sent by a second forwarding node, the second forwarding node being a downstream forwarding node of the first forwarding node; the first forwarding node performing flow control based on the first code block.

[0116] Because the second forwarding node instructs the first forwarding node to perform flow control through the lowest-level (i.e., physical layer) code blocks, it does not need to go through other higher layers, resulting in lower overhead. Moreover, this method enables the first forwarding node to quickly control the flow of downstream nodes.

[0117] In one possible implementation, the second forwarding node is a downstream forwarding node adjacent to the first forwarding node.

[0118] After receiving the first code block, the first forwarding node can determine whether flow control is needed based on the first code block. If flow control is needed, it will control subsequent data packets sent to the second forwarding node. If flow control is not needed, it will continue to wait to receive subsequent code blocks sent by the second forwarding node.

[0119] When the first code block carries information indicating whether the second forwarding node is congested, the method for determining whether flow control is needed based on the first code block includes: if the first code block carries first capability indication information, and the data receiving capability indicated by the first capability indication information is less than a first capability threshold, then flow control is determined to be needed; otherwise, flow control is not performed. Alternatively, if the first code block carries both first capability indication information and second capability indication information, and the data receiving capability indicated by the first capability indication information is less than the first capability threshold and / or the data receiving capability indicated by the second capability indication information is less than the second capability threshold, then flow control is determined to be needed; otherwise, flow control is not performed.

[0120] For example, the data reception capability indicated by the first capability indication information being less than the first capability threshold includes at least one of the following: the buffer occupancy rate of the ingress port is greater than the occupancy rate threshold, the occupied buffer space is greater than the first space threshold, the remaining buffer space is less than the second space threshold, and the second space threshold is less than the first space threshold. Other examples include: the average length of each queue at the ingress port is greater than the length threshold, the available bandwidth of the ingress port is less than the bandwidth threshold, and the average packet queuing delay of each queue at the ingress port is greater than the delay threshold.

[0121] The second capability indication information indicates that the data reception capability is less than the second capability threshold, including at least one of the following: the ratio of the total throughput of multiple ports to the forwarding bandwidth is less than the proportional threshold, the average forwarding time of data packets of multiple ports is greater than the time threshold, etc.

[0122] When the first code block carries information indicating whether the second forwarding node is faulty, the method for determining whether flow control is needed based on the first code block includes: if the first code block carries fault status information, and the fault status information indicates that a fault has occurred and the fault severity is greater than a second severity threshold, then flow control is determined to be needed; otherwise, flow control is not performed. The second severity threshold is less than the first severity threshold. If the first code block carries fault status information, and the fault status information indicates that a fault has not occurred and the probability of a fault occurrence is greater than a second probability threshold, then flow control is determined to be needed; otherwise, flow control is not performed.

[0123] In one possible implementation, the first forwarding node performs flow control based on the first code block, including: the first forwarding node reducing the proportion of flow sent to the second forwarding node.

[0124] The first forwarding node is an upstream forwarding node of the second forwarding node. Since the data packets received by the second forwarding node were sent by the first forwarding node, the first forwarding node can directly reduce the proportion of traffic sent to the second forwarding node, thus directly reducing the number of data packets received by the second forwarding node. This reduces the number of data packets piling up in the second forwarding node, alleviating congestion or reducing the number of data packets sent to faulty paths. Furthermore, by collecting data receiving capabilities from downstream forwarding nodes and reducing the proportion of traffic sent to downstream forwarding nodes, hop-by-hop flow control can be achieved, offering high flexibility.

[0125] In one possible implementation, the first forwarding node performs flow control based on the first code block, including: the first forwarding node generating a second code block based on local traffic conditions and the first code block, the second code block being used to instruct a third forwarding node to perform flow control, the third forwarding node being an upstream forwarding node of the first forwarding node; the first forwarding node sending the second code block to the third forwarding node; or: the first forwarding node generating an announcement message based on local traffic conditions and the first code block, the announcement message carrying a target identifier indicating a target forwarding path; the first forwarding node sending the announcement message to the third forwarding node to instruct the third forwarding node to control subsequent data packets of the target forwarding path, the third forwarding node being an upstream forwarding node of the first forwarding node.

[0126] The announcement message can be an Ethernet frame, a UDP packet, or an IP packet. Other types of messages are also allowed, but this application does not limit this.

[0127] After receiving the first code block, the first forwarding node can generate a second code block by combining the local traffic situation with the first code block. Then, the upstream third forwarding node can perform traffic control. In this way, the third forwarding node can reduce the traffic on the first and second forwarding nodes at the same time, thus improving the effect of traffic control.

[0128] Fifthly, a notification device is provided, which has the function of implementing the method behavior described in the first aspect. The notification device includes at least one module for implementing the method provided in the first aspect.

[0129] Sixthly, a notification device is provided, which has the function of implementing the method behavior described in the second aspect above. The notification device includes at least one module for implementing the method provided in the second aspect above.

[0130] A seventh aspect provides a flow control device having the function of implementing the method behavior described in the third aspect. The flow control device includes at least one module for implementing the method provided in the third aspect.

[0131] Eighthly, a flow control device is provided, which has the function of implementing the method behavior described in the fourth aspect above. The flow control device includes at least one module for implementing the method provided in the fourth aspect above.

[0132] In a ninth aspect, a notification system is provided, the system comprising a first forwarding node and a target node, the first forwarding node comprising the notification device described in the fifth aspect, and the target node comprising the notification device described in the sixth aspect.

[0133] In a tenth aspect, a flow control system is provided, the system comprising a first forwarding node and a second forwarding node, the second forwarding node comprising the flow control device described in the seventh aspect, and the first forwarding node comprising the flow control device described in the eighth aspect.

[0134] Eleventhly, a node is provided, the node including a processor and a memory, the memory being used to store a computer program for performing the methods provided by any one of the first to fourth aspects. The processor is configured to execute the computer program stored in the memory to implement the methods described above.

[0135] In a twelfth aspect, a chip is provided, the chip including programmable logic circuitry and / or program instructions, which, when the chip is in operation, implement the method described in any one of the first to fourth aspects.

[0136] In a thirteenth aspect, a computer-readable storage medium is provided, the storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in any one of the first to fourth aspects.

[0137] In a fourteenth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, cause the computer to perform the method described in any one of the first to fourth aspects.

[0138] The technical effects achieved by the fifth to fourteenth aspects mentioned above are similar to those achieved by the corresponding technical means in the first to fourth aspects, and will not be repeated here. Attached Figure Description

[0139] Figure 1 This is a schematic diagram of a flow-by-flow forwarding path provided in an embodiment of this application;

[0140] Figure 2 This is a schematic diagram of a packet-by-packet forwarding path provided in an embodiment of this application;

[0141] Figure 3This is a schematic diagram illustrating the correspondence between port queues provided in an embodiment of this application;

[0142] Figure 4 This is a schematic diagram of message passing in a physical layer channel provided in an embodiment of this application;

[0143] Figure 5 This is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0144] Figure 6 This is a schematic diagram of an AI scenario provided in an embodiment of this application;

[0145] Figure 7 This is a flowchart of a notification method provided in an embodiment of this application;

[0146] Figure 8 This is a schematic diagram illustrating data packet control via a sending end, provided in an embodiment of this application.

[0147] Figure 9 This is a schematic diagram illustrating packet control via a local forwarding node or via an upstream forwarding node, provided in an embodiment of this application.

[0148] Figure 10 This is a flowchart of a flow control method provided in an embodiment of this application;

[0149] Figure 11 This is a schematic diagram of the structure of a notification device provided in an embodiment of this application;

[0150] Figure 12 This is a schematic diagram of the structure of a notification device provided in an embodiment of this application;

[0151] Figure 13 This is a schematic diagram of the structure of a flow control device provided in an embodiment of this application;

[0152] Figure 14 This is a schematic diagram of the structure of a flow control device provided in an embodiment of this application;

[0153] Figure 15 This is a schematic diagram of the structure of a forwarding node provided in an embodiment of this application. Detailed Implementation

[0154] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0155] Before providing a detailed explanation of the methods provided in the embodiments of this application, the terms, application scenarios, and implementation environments involved in the embodiments of this application will be introduced first.

[0156] First, the terms used in the embodiments of this application will be introduced.

[0157] 1. Load balancing mechanism

[0158] There are usually multiple equal-cost paths between two servers, and traffic between these servers can be distributed across these paths. The selection of equal-cost paths can be divided into two methods: flow-based load balancing and packet-based load balancing.

[0159] Flow-by-flow load balancing forwards the same data flow along the same path. The effectiveness of flow-by-flow load balancing depends on the number of data flows in the network. It works well when there are many data flows. However, when there are few data flows and each individual flow has a large bandwidth, routing conflicts between multiple flows can easily occur. In such cases, if the data flows are long-lasting, network performance can plummet if congestion occurs due to routing conflicts. Figure 1 As shown, a communication network between multiple servers includes multiple forwarding nodes. If server A sends traffic to server B, and the data packets of this traffic belong to the same data stream, then only one path can be used (e.g., ...). Figure 1 The path indicated by the middle arrow is used for forwarding. When other traffic chooses the same path as this traffic, a routing conflict occurs, and forwarding two data streams through a single path degrades network performance.

[0160] Packet-by-packet load balancing does not distinguish between data streams; instead, after receiving a data packet, it randomly selects an available path for forwarding, resulting in better load balancing performance compared to flow-by-flow load balancing. For example... Figure 2 As shown, server A sends traffic to server B. After receiving the traffic from server A, forwarding node 1 finds that there are two equal-cost paths (e.g., ...). Figure 2 The middle arrows indicate paths 1 and 2, so the packets included in this traffic can be distributed across these two equivalent paths.

[0161] 2. AI Traffic Characteristics

[0162] To meet the computational demands of large-scale AI models, computational tasks are typically distributed across multiple servers in parallel (i.e., distributed parallel computing) to accelerate model computation. These servers interact via a communication network. Ignoring the architecture of this network, the logical topology between these servers can be based on rings, trees, or similar structures. Ring-based logical topologies involve point-to-point communication at any given time, generating one-to-one traffic, with no many-to-one traffic. Furthermore, point-to-point communication usually involves only one or a few data streams, resulting in a small number of streams and a large bandwidth or communication volume per stream. Tree-based logical topologies can experience instantaneous three-to-one traffic. Additionally, many-to-many communication may also occur between these servers, resulting in instantaneous N-to-one traffic.

[0163] In other words, AI scenarios involve fewer data streams, but each stream has a large bandwidth. Stream-based load balancing is prone to routing conflicts, mapping different data streams to the same path, causing network congestion and significantly reducing network bandwidth utilization. Compared to stream-based load balancing, packet-based load balancing can route different packets from the same data stream to different paths, achieving more granular load balancing and mitigating routing conflicts. Therefore, AI clusters employ packet-based load balancing technology to improve network bandwidth utilization.

[0164] 3. Forwarding Node

[0165] A forwarding node is a node in a communication network that has the function of forwarding data. A forwarding node has multiple ports, and it forwards messages through these ports. The port on a forwarding node used to receive messages is called the ingress port, and the port used to send messages is called the egress port.

[0166] The forwarding node is configured with a shared cache, which stores all packets received by the forwarding node. Alternatively, each port of the forwarding node is configured with a port cache, which stores packets that port needs to forward. Or, the forwarding node is configured with a shared cache, and each port is configured with a port cache; when the space in the port cache is insufficient to store the packets that port needs to forward, the packets that port needs to forward can also be stored in the shared cache. In other words, which caches the forwarding node is specifically configured with depends on the architecture of the forwarding node, and this application does not impose any restrictions on this.

[0167] In some cases, each port of a forwarding node has multiple queues, also known as port queues or forwarding queues, each with a corresponding priority. For example, each port might have eight queues, each with a priority level. Taking a forwarding node configured with a shared buffer used to store all packets received by the node as an example, after receiving a packet, the forwarding node stores it in the shared buffer, determines the queue with the corresponding priority in the ingress port (referred to as the ingress queue) and the queue with the corresponding priority in the egress port (referred to as the egress queue), increases the packet data size corresponding to each ingress and egress queue, and then forwards each packet corresponding to the egress queue sequentially. After the packet has been forwarded, the packet data size corresponding to each ingress and egress queue is decreased.

[0168] 4. Priority-based flow control (PFC) mechanism

[0169] PFC (Position Control) is currently the most widely used and effective hop-by-hop flow control technology to avoid packet loss, and it forms the foundation of lossless networks. Queues with PFC enabled are called lossless queues. When a lossless queue at the ingress port of a downstream node becomes congested, the downstream node notifies the upstream node to stop sending traffic from that queue, thus achieving zero-packet-loss transmission.

[0170] like Figure 3 As shown, forwarding node A has 8 queues at its outgoing port, each with a corresponding priority, and forwarding node B has 8 queues at its incoming port, each with a corresponding priority. The priorities of the 8 queues at the outgoing port of forwarding node A correspond one-to-one with the priorities of the 8 queues at the incoming port of forwarding node B. Thus, the 8 queues at the outgoing port of forwarding node A and the 8 queues at the incoming port of forwarding node B form 8 virtualized channels in the network. When queue 7 at the incoming port of forwarding node B becomes congested, i.e., the total data volume of all packets corresponding to queue 7 exceeds a certain threshold, forwarding node B sends a PFC frame to the upstream node (i.e., forwarding node A in the direction the data is entering). After receiving the PFC frame, forwarding node A stops sending packets corresponding to queue 7 at its outgoing port. At this time, all packets corresponding to queue 7 at the outgoing port are buffered in the shared buffer of forwarding node A. The data volume of packets corresponding to queue 7 at the outgoing port gradually increases, and simultaneously, the data volume of packets in the queues at the corresponding incoming port of forwarding node A also gradually increases. If the queue of a certain ingress port in forwarding node A also becomes congested, that is, the data volume of all packets corresponding to the queue of a certain ingress port of forwarding node A also exceeds the threshold, then the back pressure continues to be pushed upstream, and so on, level by level, until the packet sending end, thereby eliminating packet loss caused by forwarding node congestion in the network.

[0171] 5. Physical Layer Message Channel

[0172] Currently, the Institute of Electrical and Electronics Engineers (IEEE) 802.3 uses ordered set coded blocks to transmit information at the physical layer, including two types:

[0173] (1) Sequence ordered set: also known as sequence O code, used to transmit link fault status, namely remote fault, local fault, and link interruption. If the receiving end (RX) detects a link fault locally, it will trigger the local fault signal and transmit the remote fault signal to the transmitting end (TX), thereby notifying the transmitting end to stop sending data until the link is restored.

[0174] (2) Control ordered set: Also known as control O code, it is used to transmit port control messages. For example, the Ultra Ethernet Consortium (UEC) 1.0 extended O code is used to transmit control information for link layer retry (LLR) and credit-based flow control (CBFC), and is used for physical port configuration. This control O code can preempt transmission during normal packet transmission without interrupting packet transmission.

[0175] The following is combined Figure 4 This section describes the message transmission process at the physical layer. Please refer to [link / reference]. Figure 4 Both Node A and Node B include a Media Access Control (MAC) sublayer, a Reconciliation Sublayer (RS) sublayer, and a Physical Layer (PHY). The MAC sublayer is contained within the Data Link Layer, and the RS serves as the interface between the MAC sublayer and the PHY.

[0176] Node A's MAC sublayer sends data to RS TX. RS TX encodes the data sent by the MAC sublayer into data blocks and sends these data blocks to PHY TX. PHY TX then transmits these data blocks to Node B via the link between Node A and Node B. If the link between Node A and Node B fails, Node B's PHY RX cannot receive the data blocks sent by Node A's PHY TX and determines that the link has failed. It then sends a local fault signal to RS RX. RS RX receives the local fault signal and sends a link interruption signal to the MAC sublayer, causing the MAC sublayer to stop transmitting data. Simultaneously, RS RX sends a local fault signal to RS TX, and RS TX sends a remote fault signal to PHY TX. PHY TX transmits this remote fault signal to Node A via the link between Node B and Node A. Node A's PHY RX receives this remote fault signal and sends it to RS RX. RS RX then sends a link interruption signal to the MAC sublayer, causing the MAC sublayer to stop transmitting data. At the same time, RS RX sends a remote fault signal to RS TX, causing RS TX to stop sending data blocks to PHY TX.

[0177] The signals transmitted between the MAC sublayer and the RS are typically ordered sets in Media Independent Interface (MII) format, while the signals transmitted between the RS and the PHY are typically 64B / 66B format encoded blocks. In other words, the RS can convert the MII format signals from the MAC sublayer into 64B / 66B format encoded blocks and send them to the PHY, and it can also convert the PHY's 64B / 66B format encoded blocks into MII format signals and send them to the MAC sublayer.

[0178] The format of the ordered set in MII format is shown in Table 1 below, and the format of the 64B / 66B coded block is shown in Table 2 below.

[0179] Table 1

[0180]

[0181] Table 2

[0182] bit position 0:1 2:9 10:17 18:25 26:33 34:37 38:41 42:49 50:57 58:65 bit content ‘b10 0x4B D1 D2 D3 O-code D4[4:7] D5 D6 D7

[0183] As can be seen from Table 1 above, the ordered set in MII format includes 8 fields: Lane0-Lane7. For ease of description, these 8 fields are referred to as D0-D7. Table 1 shows the differences between sequence ordered sets and control ordered sets in these 8 fields.

[0184] As shown in Table 2 above, the 64B / 66B format encoding block consists of 66 bits, which are divided into 10 groups. The first group of bits (0-1 bits) is used to encode 'b10. The second group of bits (2-9 bits) is used to encode 0x4B, indicating the type of encoding block. The third group of bits (10-17 bits) is used to encode the content of the D1 field in the MII format. The fourth group of bits (18-25 bits) is used to encode the content of the D2 field in the MII format. The fifth group of bits (26-33 bits) is used to encode the content of the D3 field in the MII format. The sixth group of bits (34-37 bits) is used to encode the content of the O-code. The seventh group of bits (38-41 bits) is used to encode the content of D4[4:7] in the D4 field of the MII format. The eighth group of bits (42-49 bits) is used to encode the content of the D5 field in the MII format. The ninth group of bits (50-57 bits) is used to encode the content of the D6 field in the MII format. The tenth group of bits, 58-65, is used to encode the content of the D7 field in the MII format.

[0185] Based on the relationship between Tables 1 and 2 above, it is possible to convert MII format signals into 64B / 66B format coded blocks, and also to convert 64B / 66B format coded blocks into MII format signals.

[0186] The sequence ordered set is used to transmit link fault status, which includes various fault signals. The control ordered set is used to transmit port control messages, such as the UEC extended O code. The specific content of each bit encoding group in Table 2 is shown in Table 3 below for different signals.

[0187] Table 3

[0188] Signal Synchronization Head type D1 D2 D3 O-code D4[7:4] D5 D6 D7 Local fault ‘b10 0x4B 0 0 1 0 0 0 0 0 Remote fault ‘b10 0x4B 0 0 2 0 0 0 0 0 Link interruption ‘b10 0x4B 0 0 3 0 0 0 0 0 UEC control O code ‘b10 0x4B Msg type D2 D3 0x6 D4[4:7] D5 D6 D7

[0189] In Table 3 above, the value of the Sync Header is 10, indicating that it will be followed by an 8-bit type field and 56 bits of control information / data.

[0190] Secondly, the application scenarios involved in the embodiments of this application will be introduced.

[0191] During traffic forwarding, events such as congestion or failures may occur along the forwarding path. To respond promptly to these events, it's typically necessary to determine the status of each forwarding path. Currently, data center networks primarily use telemetry technologies such as in-situ flow information telemetry (iFiT), in-situ operations, administration, and maintenance (iOAM), and congestion signaling (CSIG) to determine the data flow status, which in turn reflects the status of the forwarding path. Therefore, when congestion or failures occur along a forwarding path, the data flow forwarded by that path can be controlled to respond to these events.

[0192] In traditional flow-by-flow load balancing, data packets within the same data flow pass through the same forwarding path in sequence. Therefore, the state of each data packet within the same data flow effectively reflects the state of the forwarding path. Thus, controlling the data flow forwarded by a forwarding path based on its state allows for effective response to congestion or failure events along that path.

[0193] However, based on the characteristics of AI traffic and the effectiveness of load balancing, per-packet load balancing is typically used to forward AI traffic. In per-packet load balancing scenarios, data packets from the same data stream are split across multiple forwarding paths. The telemetry information of a single data packet within the same data stream only represents the status of the forwarding path it traversed, and does not represent the status of the forwarding paths traversed by other data packets in its data stream. Therefore, using the status of data packets to reflect the status of forwarding paths, and thus controlling the data stream to which the data packets belong, cannot effectively respond to events such as congestion or failures on the forwarding paths.

[0194] Based on this, this application provides a method in which forwarding nodes actively detect the status of forwarding paths and announce the status of forwarding paths to upstream forwarding nodes or senders. The upstream forwarding nodes or senders then control subsequent data packets sent to that forwarding path, thereby responding to congestion / failure events on that forwarding path. This method does not rely on the status of data packets to reflect the status of the forwarding path, and instead controls the data flow to which the data packets belong in response to congestion / failure events on the forwarding path. This approach effectively responds to congestion / failure events on the forwarding path. Furthermore, by actively detecting the status of forwarding paths, the method comprehensively covers the status of all forwarding paths in the network, maximizing bandwidth utilization. It also allows for direct reporting of the detected status, rather than waiting until the data packet reaches the last-hop forwarding node, reducing feedback latency and improving event response speed. Additionally, during the detection of the forwarding path status, communication between forwarding nodes is conducted through the lowest-level (physical layer) code blocks, eliminating the need for higher layers and minimizing overhead.

[0195] Finally, the implementation environment involved in the embodiments of this application will be described.

[0196] Please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating an implementation environment according to an embodiment of this application. The implementation environment includes multiple computing devices 01 and multiple forwarding nodes 02. One computing device 01 establishes a communication connection with one forwarding node 02, and one forwarding node 02 establishes a communication connection with one or more computing devices 01. The multiple forwarding nodes 02 also establish communication connections with each other. To improve communication reliability, although not shown in the figure, it can be understood that one computing device 01 can also establish communication connections with two or more forwarding nodes 02. In this case, the two or more forwarding nodes 02 serve as backup nodes for each other. The communication connection can be wired or wireless; this embodiment of the application does not limit the type of connection.

[0197] The multiple computing devices 01 are devices with deployed services. For example, for an AI model, the multiple computing devices 01 are devices with deployed AI computing tasks. The multiple forwarding nodes 02 are nodes used to realize the interaction between the multiple computing devices 01, that is, the interaction data between the multiple computing devices 01 is forwarded through the multiple forwarding nodes 02.

[0198] The network formed by these multiple forwarding nodes 02 is also called the communication network between these multiple computing devices 01. This communication network can adopt a two-layer network architecture (such as...). Figure 5The network architecture shown can be either a three-layer network architecture or other network architectures, such as DragonFly and Torus. This application does not limit the network architecture of the communication network. The following description uses two-layer and three-layer network architectures as examples.

[0199] This two-layer network consists of a core layer and an access layer. The core layer is the high-speed switching backbone of the communication network, connected to the backbone network (also known as the core network), for example, to the controllers in the backbone network. The access layer is used to connect workstations to the communication network; these workstations can be... Figure 5 The computing device shown can also be a base station, access point, etc. A three-layer network architecture adds a convergence layer to a two-layer network architecture. The convergence layer provides converged connections (such as connecting the access layer and the core layer). Forwarding nodes located in the access layer are called access layer nodes, forwarding nodes located in the convergence layer are called convergence layer nodes, and forwarding nodes located in the core layer are called core layer nodes.

[0200] by Figure 5 Taking the two-layer network architecture shown as an example, the forwarding node 02 connecting computing device 01 is located in the access layer; these forwarding nodes 02 are called access layer nodes. The forwarding node 02 at the top layer is located in the core layer; these forwarding nodes 02 are called core layer nodes. In some cases, Figure 5 The two-layer network architecture shown is also called a spine-leaf architecture. The forwarding node 02 that connects to computing device 01 is called a leaf node, and the forwarding node 02 at the top layer is called a spine node.

[0201] Typically, the process of any two computing devices 01 communicating through the above network architecture is as follows: The first computing device (e.g., Figure 5 The leftmost computing device 01 sends a message to the first forwarding node (e.g., ...). Figure 5 The leftmost forwarding node (02) in the middle layer sends a data packet. After receiving the data packet, the first forwarding node encapsulates it and then sends the encapsulated data packet to the second forwarding node (e.g., ...) through the forwarding path. Figure 5 The rightmost forwarding node in the middle layer (02). After receiving the data packet, the second forwarding node decapsulates the data packet and then sends the decapsulated data packet to the second computing device (e.g., ...). Figure 5The rightmost computing device (01) enables communication between the two computing devices. The first forwarding node establishes a communication connection with the first computing device, and the second forwarding node establishes a communication connection with the second computing device. The first computing device is also called the sender, and the second computing device is also called the receiver. In this case, the first forwarding node is also called the head node, and the second forwarding node is also called the tail node. That is, the head node is the first-hop forwarding node relative to the sender, and the tail node is the first-hop forwarding node relative to the receiver.

[0202] During the communication between the two computing devices 01, the state of the forwarding path can be determined according to the method provided in the embodiments of this application, thereby controlling the subsequent data packets of the forwarding path. For example, forwarding nodes can synchronize link states through physical layer code blocks, and the upstream forwarding node can perform flow control based on the link state. Alternatively, the upstream forwarding node can continue to send announcement messages to the upstream forwarding node or the sending end to instruct the forwarding node or the sending end to control the subsequent data packets of this forwarding path.

[0203] The computing device 01 refers to terminal devices, servers, etc. Terminal devices are any electronic products that allow human-computer interaction through one or more methods such as a keyboard, touchpad, touchscreen, remote control, voice interaction, or handwriting devices, such as personal computers (PCs), mobile phones, and tablets. Servers are virtual machines, bare metal (i.e., machines without an operating system), etc. A server can be a single independent server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or a cloud computing service center.

[0204] Forwarding node 02 can be any device with data forwarding capabilities. Examples include network devices such as switches, routers, gateways (GWs), virtual switches (vSwitch), and virtual routers (vRouter). In other embodiments, forwarding node 02 can also be a chip or network interface card (NIC) with data forwarding capabilities within certain devices. For instance, forwarding node 02 is a chip with data forwarding capabilities in network devices such as switches, routers, and gateways, such as a network processor (NP) chip. As another example, forwarding node 02 is a NIC with data forwarding capabilities in a terminal device or server.

[0205] Those skilled in the art should understand that the above-described computing device 01 and forwarding node 02 are merely examples. Other existing or future computing devices or forwarding nodes that are applicable to the embodiments of this application should also be included within the scope of protection of the embodiments of this application, and are hereby incorporated by reference.

[0206] The following provides an illustrative example of the implementation environment for AI scenarios. Please refer to... Figure 6 The implementation environment includes an AI cluster, a first network cluster, and a second network cluster. The AI ​​cluster comprises multiple computing devices, each deploying an AI model. The first network cluster includes multiple forwarding nodes for communication between the computing devices within the AI ​​cluster. The second network cluster also includes multiple forwarding nodes, also used for communication between the computing devices within the AI ​​cluster.

[0207] In some embodiments, the computing devices in the AI ​​cluster include a first type of processor and a second type of processor, with the second type of processor having higher performance than the first type of processor. The first type of processor is used for low-performance computation of the AI ​​model, while the second type of processor is used for high-performance computation of the AI ​​model. Forwarding nodes in the first network cluster are used to enable communication between the first type of processors included in the multiple computing devices in the AI ​​cluster, or to enable communication between the first type of processors included in the multiple computing devices in the AI ​​cluster and other devices, such as devices providing source data. Forwarding nodes in the second network cluster are used to enable communication between the second type of processors included in the multiple computing devices in the AI ​​cluster. In this case, the first network cluster can also be referred to as a front-end network cluster, and the second network cluster can also be referred to as a back-end network cluster.

[0208] The architecture of the forwarding nodes in the first and second network clusters is similar to the network architecture of the multiple forwarding nodes 02 mentioned above. Please refer to the description above for details; it will not be repeated here.

[0209] It should be noted that the application scenarios and implementation environments described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the emergence of new application scenarios and the evolution of implementation environments, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0210] The method provided in the embodiments of this application will now be explained in detail. The method provided in the embodiments of this application can be applied to packet-by-packet load balancing scenarios as well as flow-by-flow load balancing scenarios; this application does not limit the application to either.

[0211] Figure 7This is a flowchart illustrating a notification method provided in an embodiment of this application. Please refer to it. Figure 7 The method includes the following steps.

[0212] Step 701: The first forwarding node obtains the announcement message, which carries the target identifier and indicates the target forwarding path.

[0213] The notification message can be generated by the first forwarding node, or it can be received from other forwarding nodes. The notification message can be generated when a congestion / failure event occurs on the target forwarding path, including both actual failures and warning events that do not yet occur. In other words, forwarding nodes on the target forwarding path monitor the link status between themselves and downstream nodes in real time, and generate notification messages when a congestion / failure event is determined based on the link status.

[0214] The target identifier includes an identifier of the target forwarding path. Alternatively, the target identifier includes the entropy value of the target data packet and the destination address. Of course, the target identifier can also be other identifiers that can indicate the target forwarding path, and this application embodiment does not limit this.

[0215] The target data packet is any data packet forwarded through the target forwarding path. Forwarding nodes forward data packets using routing tables, which include multiple equal-cost multipath routing (ECMP) groups. An ECMP group indicates multiple forwarding paths to the same destination address. Each ECMP group contains multiple entries, each indicating the address information of the outgoing port or next-hop node corresponding to the destination address. The entropy value of the data packet is used for load balancing, and each entry in each ECMP group corresponds to an entropy value. During the forwarding of the target data packet through the load balancing mechanism, the corresponding ECMP group can be determined from the routing table based on the destination address of the target data packet. Then, based on the entropy value of the target data packet, the address information of the corresponding outgoing port or next-hop node can be determined from the entries included in that ECMP group, and the target data packet is then sent. In other words, in a load balancing scenario, a forwarding path can be uniquely determined by the entropy value and destination address of the data packet. Therefore, the entropy value and destination address of the target data packet can uniquely identify the target forwarding path.

[0216] For flow-by-flow load balancing, the entropy values ​​of all data packets within the same data flow are the same, ensuring that all data packets within the same data flow are forwarded through the same forwarding path. For packet-by-packet load balancing, the entropy values ​​of the data packets within the same data flow are different, ensuring that data packets within the same data flow can be forwarded through multiple forwarding paths.

[0217] The entropy value of a data packet includes either a first entropy value or a second entropy value. For flow-by-flow load balancing, the first entropy value is obtained by hashing the data packet's characteristic parameters, or by hashing the data packet's characteristic parameters and a hash seed; the second entropy value is the data packet's hash seed. For packet-by-packet load balancing, the sender determines the first and second entropy values ​​using a load balancing algorithm. Of course, for both flow-by-flow and packet-by-packet load balancing, the first and second entropy values ​​can be determined in other ways, and this application does not limit this approach.

[0218] The characteristic parameters of a data packet can include any one or more parameters from the packet header. For example, the characteristic parameters of a data packet may include a 5-tuple, a 7-tuple, a 4-tuple, a 2-tuple, etc. The hash seed can be obtained by modifying the characteristic parameters of the data packet; for example, by modifying any one or more of the characteristic parameters, or by adding other parameters to the characteristic parameters.

[0219] The following are common data structures: A 5-tuple includes the source address, destination address, protocol number, source port, and destination port. A 7-tuple includes the source address, destination address, protocol number, source port, destination port, interface index, and type of service (ToS). A 4-tuple includes the source address, destination address, source port, and destination port. A 2-tuple includes the source address and destination address. The source address is the address of the sender of the data packet. The destination address is the address of the receiver of the data packet. The source port is the port used by the sender to transmit the data packet (a logical port). The destination port is the port used by the receiver to receive the data packet (a logical port). The protocol number indicates the protocol used by the sender and receiver to transmit the data packet. The interface index indicates the physical interface used to transmit the data packet; typically, one physical interface corresponds to multiple logical ports. ToS indicates the priority of the data packet.

[0220] In other embodiments, for remote direct memory access (RDMA), the seven-tuple includes the source address, destination address, protocol number, source port, destination port, source queue pair (QP), and destination QP.

[0221] The announcement message can be a User Datagram Protocol (UDP) message or an Internet Protocol (IP) message. Of course, other types of messages are also possible, such as network management plane messages. The following explanation uses UDP and IP as examples.

[0222] If the advertisement message is a UDP message, the payload of the UDP message includes the destination identifier; if the advertisement message is an IP message, the payload of the IP message includes the destination identifier.

[0223] In some embodiments, when the target identifier includes an identifier of the target forwarding path, the advertisement message includes a path identifier field, which carries the identifier of the target forwarding path. When the target identifier includes the entropy value of the target data packet and the destination address, the advertisement message includes an entropy value field and a destination address field, whereby the entropy value field carries the entropy value of the target data packet and the destination address field carries the destination address of the target data packet.

[0224] When the path identifier field carries an identifier of the target forwarding path, if the advertisement message is a UDP message, the payload of the UDP message includes the path identifier field; if the advertisement message is an IP message, the payload of the IP message includes the path identifier field. When the entropy field carries the entropy value of the target data packet and the destination address field carries the destination address of the target data packet, if the advertisement message is a UDP message, the payload of the UDP message includes both the entropy field and the destination address field; if the advertisement message is an IP message, the payload of the IP message includes both the entropy field and the destination address field.

[0225] In some embodiments, the notification message is used to make a congestion notification. In this case, the notification message also carries congestion location information and / or congestion degree information. The congestion location information indicates the location where congestion occurs in the target forwarding path, and the congestion degree information is used to indicate the degree of congestion in the target forwarding path.

[0226] The location of congestion in the target forwarding path is the queue of the ingress or egress port of the forwarding node. Congestion location information can be the identifier of the forwarding node, or other information used to indicate the forwarding node. Alternatively, congestion location information can also be the identifier of the link corresponding to the queue of the congested ingress or egress port, the identifiers of the forwarding nodes at both ends of that link, or other information used to indicate the link.

[0227] The degree of congestion in the target forwarding path can be characterized by queue occupancy, congestion level, or available bandwidth. It can also be characterized by other methods, such as the percentage of available bandwidth at full capacity, average packet forwarding delay, and average packet queuing delay. In other words, the degree of congestion in the target forwarding path can be characterized by, but is not limited to, queue occupancy, congestion level, available bandwidth, the percentage of available bandwidth at full capacity, average packet forwarding delay, and average packet queuing delay. This application embodiment does not limit this to any particular method.

[0228] If the announcement message is a UDP message, the payload of the UDP message includes congestion location information and / or congestion level information; if the announcement message is an IP message, the payload of the IP message includes congestion location information and / or congestion level information.

[0229] In some embodiments, the notification message includes a congestion location field and a congestion level field, wherein the congestion location field carries congestion location information and the congestion level field carries congestion level information.

[0230] If the advertisement message is a UDP message, the payload of the UDP message includes a congestion location field and a congestion level field. If the advertisement message is an IP message, the payload of the IP message includes a congestion location field and a congestion level field.

[0231] As an example, the format of the notification message used for congestion notification is shown in Table 4 below;

[0232] Table 4

[0233] Message Type Link ID Signal value Entropy value Dest IP 0x01(1B) 2B 3B 2B 4B

[0234] The message type field occupies 1 byte and has a value of 0x01; the Link ID is the congestion location field, which occupies 2 bytes; the Signal value is the congestion level field, which occupies 3 bytes; the Entropy value is the entropy value field, which occupies 2 bytes; and the Destination IP is the destination address field, which occupies 4 bytes.

[0235] If the advertisement message is a UDP or IP message, the message type can be indicated by the destination port field in the UDP message or by the protocol field in the IP message. That is, the destination port field in the UDP message is reused as the message type field, or the protocol field in the IP message is reused as the message type field. The Link ID, Signal value, Entropy value, and Destination IP are included in the payload portion of the UDP or IP message.

[0236] It should be noted that Table 4 above is only an example. In actual applications, the message format can be flexibly changed, and the field types included in the notification message can be fields of any data used for notification of the smoothness of the target forwarding path. The number of bits occupied by each field can also be flexibly designed. This application embodiment does not limit this.

[0237] In other embodiments, the notification message is used to notify of a fault. In this case, the notification message also carries fault location information and / or fault type. The fault location information indicates the location of the fault in the target forwarding path, and the fault type indicates the type of fault that occurred in the target forwarding path. The fault refers to a fault that has already occurred or a fault that is about to occur.

[0238] The location of a failure in the target forwarding path can be a forwarding node or a link between forwarding nodes. That is, the failure could occur at a forwarding node within the target forwarding path, or it could be a failure in the link between forwarding nodes within the target forwarding path. Therefore, if a forwarding node in the target forwarding path fails, the failure location information can be the identifier of that forwarding node, or other information used to indicate that forwarding node. If a link between forwarding nodes in the target forwarding path fails, the failure location information can be the identifier of that link, the identifiers of the forwarding nodes at both ends of that link, or other information used to indicate that link.

[0239] The types of faults occurring in the target forwarding path can include line interruption, optical module flashover, laser failure, optical power below a first power threshold, and optical power above a second power threshold. The first power threshold is less than the second power threshold. The first and second power thresholds are preset thresholds, which can be adjusted according to requirements in practical applications. This application does not limit this.

[0240] If the notification message is a UDP message, the payload of the UDP message includes fault location information and / or fault type; if the notification message is an IP message, the payload of the IP message includes fault location information and / or fault type.

[0241] In some embodiments, the notification message includes a fault location field and a fault type field, wherein the fault location field carries fault location information and the fault type field carries the fault type.

[0242] If the announcement message is a UDP message, the payload of the UDP message includes a fault location field and a fault type field. If the announcement message is an IP message, the payload of the IP message includes a fault location field and a fault type field.

[0243] As an example, the format of the notification message used for fault notification is shown in Table 5 below;

[0244] Table 5

[0245] Message Type Link ID Signal value Entropy value Dest IP 0x02(1B) 2B 3B 2B 4B

[0246] The message type field occupies 1 byte and has a value of 0x02; the Link ID is the fault location field, which occupies 2 bytes; the Signal value is the fault type field, which occupies 3 bytes; the Entropy value is the entropy value field, which occupies 2 bytes; and the Dest IP is the destination address field, which occupies 4 bytes.

[0247] If the advertisement message is a UDP or IP message, the message type can be indicated by the destination port field in the UDP message or by the protocol field in the IP message. That is, the destination port field in the UDP message is reused as the message type field, or the protocol field in the IP message is reused as the message type field. The Link ID, Signal value, Entropy value, and Destination IP are included in the payload portion of the UDP or IP message.

[0248] It should be noted that Table 5 above is only an example. In practical applications, the message format can be flexibly varied, and the field types included in the announcement message can be any data fields used for health announcements of the target forwarding path. For example, as another example, the Entropy value and Dest IP in Table 5 can be replaced with the header of the target data packet. In addition, the number of bits occupied by each field can also be flexibly designed, and this application embodiment does not limit this.

[0249] In other embodiments, the notification message is used to notify of a fault. In this case, the notification message also carries fault status information, which is used to indicate whether a fault has occurred in the target forwarding path and the severity of the fault, or to indicate whether a fault has not occurred in the target forwarding path and the probability that a fault is about to occur.

[0250] In other words, this notification message can not only notify of faults that have occurred, but also notify of the probability of a fault occurring if no fault has occurred. This can prevent data packets from being sent to faulty or potentially faulty forwarding paths in a timely manner.

[0251] Step 702: The first forwarding node sends an announcement message to the target node, which is the upstream node of the first forwarding node.

[0252] In some embodiments, the target node is an upstream forwarding node of the first forwarding node. That is, the target node is any forwarding node upstream of the first forwarding node. For example, the target node is an upstream forwarding node adjacent to the first forwarding node.

[0253] In other embodiments, the target node is the sender. That is, the target node is one end of the network used to send data packets. For example, the target node is any sender that sends data packets through a target forwarding path.

[0254] Step 703: The target node receives the announcement message from the first forwarding node and controls the subsequent data packets of the target forwarding path.

[0255] Based on the above description, the target node can be either the sender or an upstream forwarding node. The way the target node controls subsequent data packets along the target forwarding path differs depending on the situation, and these will be described separately below.

[0256] In the first scenario, the target node is the sender. The announcement message also carries congestion location information. In this case, the process by which the target node controls subsequent data packets on the target forwarding path includes: if the congestion location information indicates that a forwarding node connected to the receiver is congested, the target node reduces the speed at which data packets are sent to the receiver.

[0257] If congestion occurs at the forwarding node connected to the receiver (i.e., the last-hop forwarding node is congested), it indicates that the amount of data sent from the sender to the receiver far exceeds the amount of data the receiver can receive. Therefore, when the destination node is the sender, the sender can directly reduce the rate at which it sends data packets to the receiver, thereby reducing the amount of data sent from the sender to the receiver. This reduces the number of data packets buffered by the forwarding nodes connected to the receiver, thus alleviating congestion.

[0258] In some embodiments, there may be multiple senders sending data packets to the receiver. In this case, the first forwarding node may send a notification message to each or some of the multiple senders, so that each sender or some of the senders reduces the speed at which they send data packets to the receiver.

[0259] Before the target node reduces the rate at which it sends data packets to the receiver, it can also receive congestion flow indication information from the receiver. This congestion flow indication information is used to indicate the congested flow being sent to the receiver. In this case, the process of the target node reducing the rate at which it sends data packets to the receiver includes: the target node reducing the rate at which it sends data packets to the congested flow.

[0260] In other words, the target node reduces the sending rate of data packets for the congested flow without reducing the sending rate of data packets for other data flows, thereby selectively reducing the sending rate of data packets and avoiding impacting data packets for other data flows.

[0261] Congestion flow indication information can be an identifier of the congested flow, or other information indicating the congested flow.

[0262] In some embodiments, the notification message also carries congestion level information; in this case, the process of the target node reducing the speed of data packets sent to the receiver includes: the target node reducing the speed of data packets sent to the receiver based on the congestion level information. The process of the target node reducing the speed of data packets from a congested flow sent to the receiver includes: the target node reducing the speed of data packets from a congested flow sent to the receiver based on the congestion level information.

[0263] Based on the above description, the degree of congestion in the target forwarding path is characterized, but is not limited to, by queue occupancy, congestion level, available bandwidth, the proportion of available bandwidth to full bandwidth, average packet forwarding delay, and average packet queuing delay. The methods for reducing the speed of packets sent to the receiving end based on congestion level information differ under different circumstances. The following sections will describe several of these scenarios.

[0264] In the first implementation, the congestion information carried in the notification message is the target queue occupancy status. In this case, based on the target queue occupancy status, the corresponding packet transmission speed is obtained from the stored correspondence between queue occupancy status and packet transmission speed as the target packet transmission speed, thereby reducing the speed at which the sending end transmits data packets to the receiving end to the target packet transmission speed.

[0265] The target queue occupancy status refers to the occupancy status of queues corresponding to data packets forwarded through the target forwarding path. This can be expressed as the percentage of queues occupied or unoccupied. A higher occupied percentage indicates more severe congestion, while a lower occupied percentage indicates less congestion. Conversely, a lower unoccupied percentage indicates more severe congestion, and a higher unoccupied percentage indicates less congestion.

[0266] The second implementation method involves using the congestion level information carried in the notification message as the target congestion level. In this case, based on the target congestion level, the corresponding packet transmission speed is obtained from the stored correspondence between congestion levels and packet transmission speeds as the target packet transmission speed, thereby reducing the speed at which the sending end sends data packets to the receiving end to the target packet transmission speed.

[0267] Congestion levels are used to classify the degree of congestion. The higher the congestion level, the more severe the congestion; the lower the congestion level, the less severe the congestion.

[0268] The third implementation method involves using the target available bandwidth as the congestion level information carried in the notification message. In this case, based on the target available bandwidth, the corresponding packet transmission speed is obtained from the stored correspondence between available bandwidth and packet transmission speed as the target packet transmission speed, thereby reducing the speed at which the sending end sends data packets to the receiving end to the target packet transmission speed.

[0269] Available bandwidth indicates the amount of data that the target forwarding path can still send. The smaller the available bandwidth, the more severe the congestion; the larger the available bandwidth, the less severe the congestion.

[0270] The fourth implementation method involves using the congestion level information carried in the announcement message as the target bandwidth ratio, which is the proportion of the target available bandwidth that is fully utilized. In this case, based on the target bandwidth ratio, the corresponding packet transmission speed is obtained from the stored correspondence between bandwidth ratios and packet transmission speeds as the target packet transmission speed, thereby reducing the speed at which the sending end sends data packets to the receiving end to the target packet transmission speed.

[0271] The percentage of available bandwidth used to fill the full bandwidth indicates the proportion of data that the target forwarding path can still send. The smaller the percentage of available bandwidth used to fill the full bandwidth, the more severe the congestion; the larger the percentage of available bandwidth used to fill the full bandwidth, the less severe the congestion.

[0272] The method for reducing the speed of data packets sent to the receiving end based on congestion level information is similar to the method for reducing the speed of data packets sent to the receiving end described above, and will not be repeated here.

[0273] Since congestion information is used to indicate the degree of congestion in the target forwarding path, reducing the speed of data packets sent to the receiving end based on congestion information can make the data packet sending speed match the congestion level, thereby alleviating the congestion in the target forwarding path as quickly as possible and improving the efficiency of congestion control.

[0274] The method described above for reducing data packet transmission speed based on congestion level information is one example. In practical applications, other methods can also be used to reduce data packet transmission speed. For example, the transmission speed can be reduced in fixed steps each time, or the transmission speed can be reduced to 0 directly.

[0275] In the second scenario, the target node is the sender. The announcement message also carries congestion location information. In this case, the process by which the target node controls subsequent data packets on the target forwarding path includes: if the congestion location information indicates that an intermediate forwarding node is congested, the target node reduces the proportion of traffic allocated to the target forwarding path.

[0276] Intermediate forwarding nodes refer to all forwarding nodes in the target forwarding path except for the head node and tail node. The head node is the forwarding node connected to the sender in the target forwarding path, also known as the first-hop forwarding node. The tail node is the forwarding node connected to the receiver in the target forwarding path, also known as the last-hop forwarding node.

[0277] If an intermediate forwarding node becomes congested, it indicates that some links in the target forwarding path are still open. Therefore, when the target node is the sender, the sender directly reduces the proportion of traffic allocated to the target forwarding path. In this way, during load balancing, the number of data packets forwarded through the target forwarding path can be reduced, thereby reducing the number of data packets buffered by the congested intermediate node and alleviating the congestion.

[0278] In some embodiments, the load balancing process is achieved by assigning a load weight to each forwarding path. In this case, the proportion of traffic allocated to the target forwarding path can be characterized by the load weight of the target forwarding path.

[0279] In other embodiments, the load balancing process is achieved by polling the forwarding path, in which case the proportion of traffic allocated to the target forwarding path can be characterized by the number of polls on the target forwarding path.

[0280] If the proportion of traffic allocated to the target forwarding path is characterized by load balancing weights, then the load balancing weights of the target forwarding path can be reduced. If the proportion of traffic allocated to the target forwarding path is characterized by the number of polling rounds, then the number of polling rounds of the target forwarding path can be reduced.

[0281] In some embodiments, the notification message also carries congestion level information; in this case, the process of the target node reducing the proportion of traffic allocated to the target forwarding path includes: the target node reducing the proportion of traffic allocated to the target forwarding path based on the congestion level information.

[0282] Based on the above description, the degree of congestion in the target forwarding path is characterized, but is not limited to, by queue occupancy, congestion level, available bandwidth, the percentage of available bandwidth fully utilized, average packet forwarding delay, and average packet queuing delay. The implementation methods for reducing the proportion of traffic allocated to the target forwarding path based on congestion level information differ under different circumstances. Furthermore, the implementation method for reducing the proportion of traffic allocated to the target forwarding path based on congestion level information is similar to the implementation method for reducing the speed of data packets sent to the receiving end based on congestion level information, as described above. Please refer to the above description for details; it will not be repeated here.

[0283] Since congestion information is used to indicate the degree of congestion in the target forwarding path, reducing the proportion of traffic allocated to the target forwarding path based on congestion information can match the distribution ratio of data packets with the degree of congestion, thereby alleviating the congestion in the target forwarding path as quickly as possible and improving the efficiency of congestion control.

[0284] The four methods described above for reducing the proportion of traffic allocated to the target forwarding path based on congestion level information are just examples. In practical applications, other methods can also be used to reduce the proportion of traffic allocated to the target forwarding path. For example, the proportion of traffic allocated to the target forwarding path can be reduced in fixed steps each time, or the proportion of traffic allocated to the target forwarding path can be reduced to 0 directly.

[0285] In the third scenario, the target node is the sender. The notification message is a fault notification message. In this case, the process by which the target node controls subsequent data packets on the target forwarding path includes: the target node reducing the proportion of traffic allocated to the target forwarding path.

[0286] When the notification message is a fault notification message, it indicates that the target forwarding path is currently faulty or about to fail with a high probability of failure. To avoid sending data packets to the faulty or impending faulty forwarding path, the sender directly reduces the proportion of traffic allocated to the target forwarding path. This minimizes the number of data packets sent to the faulty or impending faulty forwarding path during load balancing.

[0287] In some embodiments, the proportion of traffic allocated to the target forwarding path can be reduced to 0. That is, the target forwarding path is no longer used to forward data packets, thus avoiding the impact of existing or impending failures on data forwarding.

[0288] In some embodiments, the notification message also carries the fault type. If the fault type is a line interruption or optical module intermittent failure, the proportion of traffic allocated to the target forwarding path is reduced to 0. If the fault type is a laser failure and there is no non-failed laser, the proportion of traffic allocated to the target forwarding path is reduced to 0.

[0289] Among them, laser failure and no non-failed lasers include: only one laser and the laser is failed, or multiple lasers and all of them are failed.

[0290] If the fault type is line interruption, optical module flashover, or laser failure and there is no non-failed laser, it indicates that the target forwarding path can no longer transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced to 0 to prevent data packets from being sent to the target forwarding path and affecting the transmission of data packets.

[0291] In some embodiments, the notification message also carries fault status information. If the fault status information indicates that a fault has occurred in the target forwarding path and the severity of the fault, then if the fault type is a line interruption, optical module flashover, or laser failure with no unfailed lasers, the proportion of traffic allocated to the target forwarding path is reduced to 0. If the fault status information indicates that no fault has occurred in the target forwarding path and the probability of a fault occurring is greater than a first probability threshold, it indicates that the probability of a fault occurring is high and a fault may occur soon. In this case, if the fault type is a line interruption, optical module flashover, or laser failure with no unfailed lasers, the proportion of traffic allocated to the target forwarding path is reduced to 0.

[0292] The first probability threshold indicates a high probability of failure, suggesting that a failure may occur very soon. This first probability threshold is set, but in practical applications, it can be adjusted according to different needs.

[0293] In other embodiments, the proportion of traffic allocated to the target forwarding path can be reduced, but not reduced to zero. That is, the number of packets forwarded by the target forwarding path is reduced.

[0294] In some embodiments, the notification message also carries the fault type. If the fault type is laser failure and there are still unfailed lasers, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0. If the fault type is optical power below a first power threshold or optical power above a second power threshold, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0.

[0295] If the fault type is laser failure but there are still surviving lasers, it indicates that other lasers are still operational, the optical module is still functional, and the target forwarding path can still transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to zero, and the target forwarding path can still share the load of other equivalent paths. If the fault type is optical power below the first power threshold or optical power above the second power threshold, it indicates that the optical module is still operational, and the target forwarding path can still transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to zero, and the target forwarding path can still share the load of other equivalent paths.

[0296] In other embodiments, the notification message also carries fault status information. If the fault status information indicates that a fault has occurred in the target forwarding path and the severity of the fault, then if the fault type is laser failure and there are still unfailed lasers, optical power is lower than a first power threshold, or optical power is higher than a second power threshold, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is greater than a second probability threshold and less than a first probability threshold, then the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is not greater than a second probability threshold, then the proportion of traffic allocated to the target forwarding path is not reduced.

[0297] If the fault status information indicates a fault has occurred in the target forwarding path and the severity of the fault is specified, then if the fault type is laser failure and there are still unfailed lasers, the optical power is below the first power threshold, or the optical power is above the second power threshold, it indicates that the optical module can still operate, and the target forwarding path can still transmit data packets. In this case, the proportion of traffic allocated to the target forwarding path is reduced, but not reduced to 0, and the target forwarding path can still share the load of other equivalent paths. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is greater than the second probability threshold but less than the first probability threshold, it indicates that the probability of a fault occurring is relatively high. In this case, regardless of the fault type, the proportion of traffic allocated to the target forwarding path can be reduced to 0, thereby reducing the impact of the potentially faulty forwarding path on data packets. If the fault status information indicates that no fault has occurred in the target forwarding path, and the probability of a fault occurring is not greater than the second probability threshold, it indicates that the probability of a fault occurring is relatively low, and the proportion of traffic allocated to the target forwarding path is not reduced.

[0298] The second probability threshold is lower than the first probability threshold. The second probability threshold indicates a higher probability of failure, but not an immediate one. The second probability threshold is set, and in practical applications, it can be adjusted according to different needs.

[0299] Based on the above description, the proportion of traffic allocated to the target forwarding path can be characterized by load balancing weights or by the number of polling rounds. When a target node reduces the proportion of traffic allocated to the target forwarding path, it reduces the load balancing weights corresponding to the target forwarding path, or it reduces the number of polling rounds for the target forwarding path.

[0300] In some embodiments, when the fault status information indicates the severity of a fault, the proportion of traffic allocated to the target forwarding path can be reduced based on the severity of the fault. When the fault status information indicates the probability of a fault occurring, the proportion of traffic allocated to the target forwarding path can be reduced based on the probability of a fault occurring.

[0301] In some embodiments, the notification message also carries fault location information and / or fault type, so that the target node can send a fault maintenance message to the network management side, enabling the network management side to locate the location of the fault in the target forwarding path based on the fault location information, and then perform fault maintenance based on the fault type.

[0302] In other embodiments, the notification message also carries fault status information. This allows the target node to determine whether to retransmit data packets based on the fault status information. For example, if the fault status information indicates that the target forwarding path has failed, or has not failed but the probability of failure is greater than a first probability threshold, then it is determined that data packets need to be retransmitted. If the fault status information indicates that the target forwarding path has not failed and the probability of failure is not greater than the first probability threshold, then data packets do not need to be retransmitted.

[0303] In some embodiments, the notification message also carries the header of the target data packet. In this case, the target data packet is determined to be a data packet that needs to be retransmitted, and the target data packet is retransmitted based on the header of the target data packet.

[0304] The third scenario described above involves reducing the proportion of traffic allocated to the target forwarding path. In other embodiments, the transmission rate of data packets on the target forwarding path can also be reduced. Alternatively, if the ECMP group includes route-switching paths, the paths of subsequent data packets can be adjusted.

[0305] In all three scenarios described above, the sending end controls subsequent data packets along the target forwarding path. Next, we will... Figure 8 Here is a general explanation of these three situations. Please refer to [link / reference]. Figure 8 , Figure 8 It includes 2 sending ends, 2 receiving ends, and 6 forwarding nodes. Each forwarding node actively monitors the link status between itself and downstream nodes. If forwarding node S1 determines that there is congestion or failure in the link between itself and the downstream forwarding node eL1, forwarding node S1 generates an announcement message. For any data packet sent by forwarding node S1 to forwarding node eL1, if the data packet comes from sending end 1, forwarding node S1 sends an announcement message to sending end 1, so that sending end 1 controls the subsequent data packets sent.

[0306] In the fourth scenario, the target node is an upstream forwarding node of the first forwarding node, or the target node is an upstream forwarding node adjacent to the first forwarding node. In this case, the process by which the target node controls subsequent data packets on the target forwarding path includes: if there are multiple forwarding paths between the target node and the receiving end, adjusting the target node's local load balancing strategy and forwarding data packets through the target node's local load balancing strategy.

[0307] There are several ways to adjust the local load balancing strategy of the target node, which will be introduced below.

[0308] The first method involves forwarding each data packet along the multiple forwarding paths through the lightest-loaded path.

[0309] If the target forwarding path becomes congested or fails, the first method is equivalent to adjusting the forwarding path of the data packets, which can reduce the number of data packets on the more congested forwarding path, thus alleviating the congestion, or reduce the number of data packets sent to the failed path.

[0310] The second method is to adjust the traffic allocation ratio of the multiple forwarding paths and forward the data packets on the multiple forwarding paths according to the traffic allocation ratio of the multiple forwarding paths.

[0311] The process of adjusting the traffic allocation ratio of the multiple forwarding paths includes: determining the congestion level of the multiple forwarding paths, and adjusting the traffic allocation ratio of the multiple forwarding paths according to the congestion level, so that the traffic allocation ratio of the forwarding path with severe congestion is less than the traffic allocation ratio of the forwarding path with mild congestion.

[0312] The second method allows data packets on multiple forwarding paths to be matched with their respective path states, thereby improving bandwidth utilization.

[0313] The third approach is to set the target forwarding path to stop sending data packets if the congestion level of the target forwarding path reaches the congestion warning threshold.

[0314] For example, the forwarding table entry corresponding to the target forwarding path in the routing table of the target node is set to expire within the target duration.

[0315] The congestion warning threshold indicates that the congestion level is already very serious. If data packets are continued to be forwarded through this forwarding path at this time, serious events such as packet loss may occur. Therefore, setting the target forwarding path to stop sending data packets can promptly curb such serious events.

[0316] It should be noted that the above three methods are just examples. In actual applications, the local load balancing strategy of the target node can be adjusted in other ways, and this application embodiment does not limit this.

[0317] The four scenarios described above involve controlling subsequent data packets on the target forwarding path through the sending end or upstream forwarding nodes. In other embodiments, if the first forwarding node detects congestion / failure on the target forwarding path, it can also directly control subsequent data packets on the target forwarding path. The method by which the first forwarding node directly controls subsequent data packets on the target forwarding path is similar to the three methods described above.

[0318] Please refer to Figure 9 , Figure 9 It includes 2 sending ends, 2 receiving ends, and 6 forwarding nodes. Each forwarding node actively monitors the link status between itself and downstream nodes. If forwarding node S1 determines that the link between itself and the downstream forwarding node eL1 is congested, forwarding node S1 adjusts its local load balancing strategy and forwards data packets according to the local load balancing strategy. Alternatively, forwarding node S1 generates an announcement message. For any data packet sent by forwarding node S1 to forwarding node eL1, if the data packet was sent by the upstream forwarding node iL1, forwarding node S1 sends an announcement message to forwarding node iL1, enabling forwarding node iL1 to control the subsequent data packets sent.

[0319] If the target node is an upstream forwarding node of the first forwarding node, or if the target node is an upstream forwarding node adjacent to the first forwarding node, and the target node has no alternative route, then the target node sends an announcement message to the upstream node to instruct the upstream node to control subsequent data packets on the target forwarding path. In other words, even if the target node cannot control subsequent data packets on the target forwarding path, it can still continue to send announcement messages to the upstream node, enabling the upstream node to control subsequent data packets on the target forwarding path.

[0320] When the target node has no alternative path, it means there are no other forwarding paths between the target node and the receiver besides the target forwarding path. Alternatively, multiple forwarding paths exist between the target node and the receiver, but all of these paths have generated advertisement messages, indicating congestion or failure. In this case, the target node sends an advertisement message to upstream nodes, enabling them to promptly alleviate the congestion or failure of the target forwarding path and thus improve bandwidth utilization.

[0321] After the target node controls subsequent data packets on the target forwarding path according to the four scenarios described above, the target node can also receive a release message from the first forwarding node. The release message carries the target identifier. At this time, the target node releases control over subsequent data packets on the target forwarding path. In other words, after the congestion / fault on the target forwarding path is cleared, the target node can also release control over subsequent data packets on the target forwarding path, thereby allowing the target forwarding path to forward data packets normally.

[0322] Specifically, releasing control over subsequent data packets on the target forwarding path means releasing control over subsequent data packets on the target forwarding path according to the aforementioned notification message. In other words, it restores the state to that before control was exercised over subsequent data packets on the target forwarding path according to the aforementioned notification message. For example, if the aforementioned control operation on subsequent data packets on the target forwarding path was to reduce the rate of data packets sent to the receiving end, then releasing control over subsequent data packets on the target forwarding path is to increase the rate of data packets sent to the receiving end. If the aforementioned control operation on subsequent data packets on the target forwarding path was to reduce the proportion of traffic allocated to the target forwarding path, then releasing control over subsequent data packets on the target forwarding path is to increase the proportion of traffic allocated to the target forwarding path.

[0323] In some cases, after sending a release message, the target node may not receive it. Alternatively, to avoid temporary relief from congestion / failure due to unforeseen circumstances, only to have congestion / failure recur shortly afterward, the first forwarding node can continuously send release messages to the target node within a first time period. If the target node continuously receives release messages within this first time period, it will release control over subsequent data packets on the target forwarding path, thus preventing subsequent data packets on the target forwarding path from being uncontrolled in a timely manner, or from switching back and forth between control and decontrol.

[0324] In some cases, the target node may not receive any packets. In this situation, if the target node does not receive an announcement or cancellation message from the first forwarding node within a second time period, it will release control over subsequent data packets on the target forwarding path. This allows for timely release of control over subsequent data packets on the target forwarding path, improving bandwidth utilization.

[0325] It should be noted that the target forwarding path may experience congestion events, failure events, or even failure warning events. The notification messages for these events can be sent individually, or multiple notification messages destined for the same end can be combined into a single message. This reduces the number of communications and saves communication overhead. Furthermore, in some cases, if at least two of these events occur simultaneously, a single notification message can be used to notify all of these events at once, and these events can be handled according to the corresponding implementation methods described above.

[0326] In this embodiment, the forwarding node actively announces the status of the forwarding path to the upstream forwarding node or sender. The upstream forwarding node or sender then controls subsequent data packets sent to that forwarding path, thereby responding to congestion / failure events on that forwarding path. This approach does not rely on the status of data packets to reflect the status of the forwarding path, nor does it control the data flow to respond to congestion / failure events on the forwarding path. This method effectively responds to congestion / failure events on the forwarding path. Furthermore, by actively detecting the status of the forwarding path, the forwarding node comprehensively covers the status of all forwarding paths in the network, maximizing bandwidth utilization. It also reports the status directly after detection, rather than waiting until the data packet reaches the last-hop forwarding node, reducing feedback latency and improving event response speed.

[0327] Figure 10 This is a flowchart of a flow control method provided in an embodiment of this application. Please refer to it. Figure 10 The method includes the following steps.

[0328] Step 1001: The second forwarding node obtains the first code block, which is used to instruct the first forwarding node to perform flow control. The first forwarding node is the upstream forwarding node of the second forwarding node.

[0329] The first forwarding node is any forwarding node upstream of the second forwarding node. For example, the first forwarding node is an upstream forwarding node adjacent to the second forwarding node.

[0330] The first code block is generated by the second forwarding node, or it can be received from other forwarding nodes.

[0331] In some embodiments, the first code block is periodically generated by the second forwarding node and sent to the first forwarding node. In this way, the first forwarding node can periodically learn about the data forwarding capabilities of the second forwarding node.

[0332] Since the code block belongs to the physical layer, the communication overhead of the physical layer is very low. Therefore, periodically generating the first code block and sending it to the first forwarding node will not cause excessive communication overhead, and it can also enable the data forwarding capability of the second forwarding node to be synchronized to the first forwarding node in a timely manner.

[0333] In other embodiments, the first code block is generated and sent to the first forwarding node by the second forwarding node after detecting a congestion or fault event. The fault event includes either an actual fault or a fault warning event (i.e., an impending fault). In other words, the second forwarding node can detect in real time whether a congestion event, fault event, or fault warning event (i.e., an impending fault) has occurred. If such an event occurs, the second forwarding node generates the first code block and sends it to the first forwarding node, enabling the first forwarding node to promptly learn of the second forwarding node's data forwarding capabilities.

[0334] Although the communication overhead of the physical layer is low, the overhead of flow control can be further reduced by generating the first code block and sending it to the first forwarding node after detecting a congestion event, a fault event, or a fault warning event.

[0335] The second forwarding node may experience congestion, failure, or impending failure. Under different circumstances, the information carried by the first code block will differ. These will be discussed separately below.

[0336] In the first case, the first code block carries information indicating whether the second forwarding node is congested.

[0337] In some embodiments, the first code block carries first capability indication information, which is used to indicate the data reception capability of the ingress port of the second forwarding node.

[0338] In some cases, each ingress port of a forwarding node is configured with a buffer to store data packets received through that ingress port. In this case, the first capability indication information could be the buffer occupancy rate, occupied buffer, and / or remaining buffer of the second forwarding node's ingress port. The ingress port refers to the port that receives data sent by the first forwarding node.

[0339] The data receiving capability of the ingress port of the second forwarding node can also be characterized by other parameters, such as the average length of each queue of the ingress port, the available bandwidth of the ingress port, and the average packet queuing delay of each queue of the ingress port.

[0340] Based on the preceding description, each port of a forwarding node has multiple queues, and each queue corresponds to a priority. The data packets received by a forwarding node typically correspond to one of these queues. Therefore, the first capability indication information specifically indicates the data reception capability of the target queue at the ingress port of the second forwarding node, and the first code block also carries the priority of the target queue.

[0341] The target queue can be any one of the multiple queues at the ingress port. Of course, it can also be a queue that frequently experiences congestion, but this embodiment of the application does not limit this.

[0342] The data receiving capability of the target queue can be characterized by the length of the target queue and the data packet queuing delay of the target queue.

[0343] In the above description, the first capability indication information carried by the first code block can indicate the data reception capability of the entire ingress port or the data reception capability of the target queue of the ingress port. In this case, the first code block also carries the priority of the target queue. In other embodiments, the first code block simultaneously carries the first capability indication information, the priority, and a priority enable flag. If the priority enable flag is invalid, it indicates that the first capability indication information is used to indicate the data reception capability of the entire ingress port. If the priority enable flag is valid, it indicates that the first capability indication information is used to indicate the data reception capability of the target queue of the ingress port, and the priority carried by the first code block is the priority of the target queue.

[0344] In other embodiments, the first code block also carries second capability indication information, which is used to indicate the data reception capability of the shared buffer of multiple ports of the second forwarding node.

[0345] In some cases, multiple ports of a forwarding node are configured with shared buffers to store data packets forwarded through these ports. These multiple ports can be multiple inbound ports, multiple outbound ports, or a combination of both. In this case, the second capability indication information can be the occupancy rate, occupied shared buffer, and / or remaining shared buffer of the shared buffers of the multiple ports of the second forwarding node.

[0346] The data receiving capacity of a shared buffer across multiple ports can also be characterized by other parameters, such as the ratio of the total throughput to the forwarding bandwidth of these ports, and the average packet forwarding time of these ports. The total throughput of these ports refers to the amount of data in the packets forwarded by these ports. The forwarding bandwidth of these ports is the maximum amount of data in the packets that these ports can forward.

[0347] In other embodiments, the first code block also carries verification information used to protect the information carried by the first ordered set code block. For example, this verification information may be a cyclic redundancy check (CRC) code.

[0348] In addition to the parameters mentioned above, the first code block can also carry other parameters, such as the number of microbursts, microburst bandwidth, microburst data volume, number of PFC pause frames, queue establishment time, queue establishment speed, packet loss rate, and queue length change rate. Specifically, the number of microbursts refers to the number of times burst traffic is forwarded. The microburst speed refers to the bandwidth of the burst traffic. The microburst data volume refers to the total data volume of the forwarded burst traffic. The number of PFC pauses refers to the number of times the PFC mechanism determines to pause data transmission; that is, the number of times the PFC mechanism determines congestion and sends PFC frames to upstream nodes. The queue establishment time refers to the time elapsed from when the queue is empty to the current queue status. The packet loss rate can be statistically analyzed according to different situations, such as packet loss rate due to congestion or packet loss rate due to faults.

[0349] In some embodiments, the first code block is an ordered set encoded block in 64B / 66B format. Of course, the first code block can also be other code blocks of the physical layer, and this application embodiment does not limit this.

[0350] As an example, the first code block is a code block obtained by expanding the control ordered set and encoding it in 64B / 66B format. The format of the expanded control ordered set is shown in Table 6 below:

[0351] Table 6

[0352]

[0353]

[0354] For ease of understanding, Table 6 above lists not only the control ordered set but also the extended control ordered set according to the embodiments of this application. The first code block can be obtained by encoding the extended control ordered set according to the embodiments of this application using the 64B / 66B format.

[0355] It should be noted that in Table 6 above, the first capability indication information is carried through fields D2 and D3, the priority is carried through D4[7:4] in field D4, the second capability indication information is carried through fields D5 and D6, and the verification information is carried through field D7. Table 6 is merely an example; in actual applications, the fields used to carry this information are not limited. For example, the second capability indication information can be carried through fields D2 and D3, and the first capability indication information can be carried through fields D5 and D6. Alternatively, the first capability indication information can be carried through field D2, and the second capability indication information through field D3. Or, the first capability indication information can be carried through field D3, and the second capability indication information through field D2. Or, the first capability indication information can be carried through field D5, and the second capability indication information through field D6. Or, the first capability indication information can be carried through field D6, and the second capability indication information through field D5.

[0356] Based on the above description, the first code block can also carry a priority enable flag. Since queue priority is usually represented by 3 bits, and the priority part in Table 6 above occupies 4 bits, the priority and the priority enable flag can occupy all 4 bits. The priority enable flag can occupy any one of these 4 bits, and this application embodiment does not limit this.

[0357] In the second scenario, the first code block carries information indicating whether the second forwarding node is faulty.

[0358] In some embodiments, the first code block carries a fault type, which indicates the type of fault that occurred in the second forwarding node, or the type of fault that is about to occur and is being warned.

[0359] Based on the above description, the first code block can be generated and sent periodically, or it can be generated and sent after a fault event has occurred or is about to occur. If the first code block is generated and sent periodically, then in the case where no fault has occurred, the fault type is empty or a specified value; in the case where a fault has occurred or is about to occur, the fault type is the type of the fault that has occurred or the type of the fault that is about to occur.

[0360] The fault types can include line interruption, optical module flashover, laser failure, optical power below the first threshold, or optical power above the second threshold.

[0361] In other embodiments, the first code block also carries fault status information, which is used to indicate whether the second forwarding node has failed and the severity of the failure, or to indicate whether the second forwarding node has not failed and the probability of failure.

[0362] In some embodiments, fault type and fault status information can be determined through the health indicators of the second forwarding node. These health indicators include the frame loss rate (FLR) and bit error rate (BER) determined by CRC, with BER including pre-forward error correction (Pre-FEC) BER and post-forward error correction (Post-FEC) BER. They also include the optical module's receive / transmit power, bias current, voltage, temperature, status, signal-to-noise ratio, etc.

[0363] For example, the optical module's receive / emit power, bias current, voltage, temperature, status, signal-to-noise ratio, etc., are used to determine whether the optical module has failed, and in the case where no failure has occurred, these parameters are used to determine the probability of failure.

[0364] In the above description, the fault status information is used to indicate whether the second forwarding node has failed and the severity of the failure, or to indicate whether the second forwarding node has not failed and the probability of failure. That is, the fault status information includes a fault flag and fault severity information. The fault flag indicates whether a fault has occurred. When the fault flag indicates a fault has occurred, the fault severity information indicates the severity of the fault. When the fault flag indicates no fault has occurred, the fault severity information indicates the probability of failure.

[0365] In some embodiments, the first code block is an ordered set encoded block in 64B / 66B format. Of course, the first code block can also be other code blocks of the physical layer, and this application embodiment does not limit this.

[0366] As an example, the first code block is a code block obtained by extending the control ordered set and encoding it in 64B / 66B format. The format of the extended control ordered set is shown in Table 7 below:

[0367] Table 7

[0368]

[0369]

[0370] For ease of understanding, Table 7 above lists not only the control ordered set but also the extended control ordered set according to the embodiments of this application. The first code block can be obtained by encoding the extended control ordered set according to the embodiments of this application using the 64B / 66B format.

[0371] It should be noted that in Table 7 above, the fault type is carried by fields D2 and D3, and the fault severity information is carried by fields D5 and D6. Table 7 is merely an example; in actual applications, the fields used to carry this information are not limited. For example, fault severity information can be carried by fields D2 and D3, and fault type by fields D5 and D6. Alternatively, fault type can be carried by fields D2 and D3, and fault severity information by fields D6 and D7. Or, fault severity information can be carried by fields D2 and D3, and fault type by fields D6 and D7. Alternatively, fault type can be carried by field D2, and fault status information by field D3. Alternatively, fault type can be carried by field D5, and fault status information by field D6. Alternatively, fault type can be carried by field D3, and fault status information by field D2. Alternatively, fault type can be carried by field D6, and fault status information by field D5.

[0372] Based on the above description, the fault status information may include a fault flag bit and fault severity information. The fault flag bit may occupy some bits in fields D5 and D6, and the fault severity information may occupy the remaining bits in fields D5 and D6. Alternatively, the fault flag bit may occupy field D5, and the fault severity information may occupy field D6. This application embodiment does not limit this.

[0373] Step 1002: The second forwarding node sends the first code block to the first forwarding node.

[0374] Step 1003: The first forwarding node receives the first code block sent by the second forwarding node and performs flow control based on the first code block.

[0375] After receiving the first code block, the first forwarding node can determine whether flow control is needed based on the first code block. If flow control is needed, it will control subsequent data packets sent to the second forwarding node. If flow control is not needed, it will continue to wait to receive subsequent code blocks sent by the second forwarding node.

[0376] When the first code block carries information indicating whether the second forwarding node is congested, the method for determining whether flow control is needed based on the first code block includes: if the first code block carries first capability indication information, and the data receiving capability indicated by the first capability indication information is less than a first capability threshold, then flow control is determined to be needed; otherwise, flow control is not performed. Alternatively, if the first code block carries both first capability indication information and second capability indication information, and the data receiving capability indicated by the first capability indication information is less than the first capability threshold and / or the data receiving capability indicated by the second capability indication information is less than the second capability threshold, then flow control is determined to be needed; otherwise, flow control is not performed.

[0377] For example, the data reception capability indicated by the first capability indication information being less than the first capability threshold includes at least one of the following: the buffer occupancy rate of the ingress port is greater than the occupancy rate threshold, the occupied buffer space is greater than the first space threshold, the remaining buffer space is less than the second space threshold, and the second space threshold is less than the first space threshold. Other examples include: the average length of each queue at the ingress port is greater than the length threshold, the available bandwidth of the ingress port is less than the bandwidth threshold, and the average packet queuing delay of each queue at the ingress port is greater than the delay threshold.

[0378] The second capability indication information indicates that the data reception capability is less than the second capability threshold, including at least one of the following: the ratio of the total throughput of multiple ports to the forwarding bandwidth is less than the proportional threshold, the average forwarding time of data packets of multiple ports is greater than the time threshold, etc.

[0379] The thresholds mentioned above are based on experience and can be adjusted in practice. This application does not limit this.

[0380] When the first code block carries information indicating whether the second forwarding node is faulty, the method for determining whether flow control is needed based on the first code block includes: if the first code block carries fault status information, and the fault status information indicates that a fault has occurred and the fault severity is greater than a second severity threshold, then flow control is determined to be needed; otherwise, flow control is not performed. The second severity threshold is less than the first severity threshold. If the first code block carries fault status information, and the fault status information indicates that a fault has not occurred and the probability of a fault occurrence is greater than a second probability threshold, then flow control is determined to be needed; otherwise, flow control is not performed.

[0381] There are several ways to control traffic sent to the second forwarding node, which will be introduced in detail below.

[0382] In the first implementation, the first forwarding node reduces the proportion of traffic sent to the second forwarding node.

[0383] The first forwarding node is an upstream forwarding node of the second forwarding node. Since the data packets received by the second forwarding node were sent by the first forwarding node, the first forwarding node can directly reduce the proportion of traffic sent to the second forwarding node, thus directly reducing the number of data packets received by the second forwarding node. This reduces the number of data packets piling up in the second forwarding node, alleviating congestion or reducing the number of data packets sent to faulty paths. Furthermore, by collecting data receiving capabilities from downstream forwarding nodes and reducing the proportion of traffic sent to downstream forwarding nodes, hop-by-hop flow control can be achieved, offering high flexibility.

[0384] When there are multiple forwarding paths between the first forwarding node and the receiving end, the link between the first forwarding node and the second forwarding node may be a link on one of the forwarding paths. In this case, the method of reducing the proportion of traffic sent to the second forwarding node is similar to the method of reducing the proportion of traffic allocated to the target forwarding path by the target node in step 703 above, and will not be described again here.

[0385] In the second implementation, the first forwarding node generates a second code block based on the local traffic situation and the first code block. The second code block is used to instruct the third forwarding node to perform traffic control. The third forwarding node is the upstream forwarding node of the first forwarding node, and the first forwarding node sends the second code block to the third forwarding node.

[0386] The first forwarding node can not only perform traffic control directly based on the first code block, but also generate a second code block based on local traffic conditions, which will then be controlled by the upstream third forwarding node.

[0387] In cases where the first forwarding node may have poor data reception capabilities, traffic control via a third forwarding node can simultaneously reduce traffic on both the first and second forwarding nodes, thus improving the effectiveness of traffic control.

[0388] The third forwarding node can be any upstream node of the first forwarding node. For example, the third forwarding node is an upstream forwarding node adjacent to the first forwarding node.

[0389] In the third implementation, the first forwarding node generates an announcement message based on local traffic conditions and the first code block. The announcement message carries a target identifier, which indicates the target forwarding path. The first forwarding node sends the announcement message to the third forwarding node to instruct the third forwarding node to control subsequent data packets on the target forwarding path. The third forwarding node is the upstream forwarding node of the first forwarding node.

[0390] The announcement message can be an Ethernet frame, a UDP packet, or an IP packet. Other types of messages are also possible, but this application embodiment does not limit this.

[0391] In this embodiment, after the second forwarding node detects its own connectivity or health status, it synchronizes its connectivity or health status with the first forwarding node through the lowest-level (i.e., physical layer) code block, without needing to go through other higher layers, thus minimizing overhead. Furthermore, after receiving the first code block, the first forwarding node can combine its local traffic situation with the first code block to generate a second code block, which is then used by the upstream third forwarding node for traffic control. This allows the third forwarding node to simultaneously reduce traffic on both the first and second forwarding nodes, improving the effectiveness of traffic control.

[0392] It should be noted that the above Figure 7 The illustrated embodiments and Figure 10 The illustrated embodiments can be combined with each other. For example, the second forwarding node generates a first code block and sends it to the first forwarding node. The first forwarding node generates an announcement message based on the first code block and sends the announcement message to the target node to instruct the target node to control subsequent data packets on the target forwarding path. Alternatively, the first forwarding node generates an announcement message based on local traffic conditions and the first code block and sends the announcement message to the target node to instruct the target node to control subsequent data packets on the target forwarding path. For detailed implementation details, please refer to the preceding description; they will not be repeated here.

[0393] The apparatus provided in the embodiments of this application will now be described.

[0394] Figure 11 This is a schematic diagram of a notification device provided in an embodiment of this application. This device can be implemented as part or all of a forwarding node by software, hardware, or a combination of both. See also... Figure 11 The device includes a message acquisition module 1101 and a message sending module 1102.

[0395] The message acquisition module 1101 is used to acquire the announcement message, which carries the target identifier and indicates the target forwarding path.

[0396] The message sending module 1102 is used to send an announcement message to the target node to instruct the target node to control the subsequent data packets of the target forwarding path. The target node is the upstream node of the first forwarding node.

[0397] In one possible implementation, the target node is an upstream forwarding node adjacent to the first forwarding node; or, the target node is the sender.

[0398] In one possible implementation, the target identifier includes the identifier of the target forwarding path.

[0399] In one possible implementation, the target identifier includes the entropy value of the target data packet and the destination address.

[0400] In one possible implementation, the advertisement message is a User Data Protocol (UDP) message, the payload of which includes a destination identifier; or, the advertisement message is a Network Protocol (IP) message, the payload of which includes a destination identifier.

[0401] In one possible implementation, the notification message also carries congestion location information and / or congestion degree information, whereby the congestion location information indicates the location of congestion in the target forwarding path and the congestion degree information indicates the degree of congestion in the target forwarding path.

[0402] In one possible implementation, the notification message also carries fault location information and / or fault type, whereby the fault location information indicates the location of the fault in the target forwarding path and the fault type indicates the type of fault that occurred in the target forwarding path.

[0403] It should be noted that the notification device provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the notification device and notification method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0404] Figure 12 This is a schematic diagram of a notification device provided in an embodiment of this application. This device can be implemented as part or all of a forwarding node by software, hardware, or a combination of both. See also... Figure 12 The device includes a message receiving module 1201 and a data packet control module 1202.

[0405] The message receiving module 1201 is used to receive an announcement message from the first forwarding node. The announcement message carries a target identifier, which indicates the target forwarding path. The first forwarding node is a downstream forwarding node of the target node.

[0406] The packet control module 1202 is used to control subsequent packets on the target forwarding path.

[0407] In one possible implementation, the target node is the sender.

[0408] In one possible implementation, the notification message also carries congestion location information, which indicates the location where congestion occurs in the target forwarding path;

[0409] The data packet control module 1202 is specifically used for:

[0410] If the congestion location information indicates that the forwarding node connected to the receiver is congested, the speed at which data packets are sent to the receiver is reduced.

[0411] In one possible implementation, the notification message also carries congestion level information, which is used to indicate the degree of congestion in the target forwarding path;

[0412] The packet control module 1202 is specifically used to reduce the speed of data packets sent to the receiving end based on congestion information.

[0413] In one possible implementation, the notification message also carries congestion location information, which indicates the location where congestion occurs in the target forwarding path;

[0414] The data packet control module 1202 is specifically used for:

[0415] If the congestion location information indicates that an intermediate forwarding node is congested, the proportion of traffic allocated to the target forwarding path is reduced.

[0416] In one possible implementation, the notification message also carries congestion level information, which is used to indicate the degree of congestion in the target forwarding path; the packet control module 1202 is specifically used to: reduce the proportion of traffic allocated to the target forwarding path based on the congestion level information.

[0417] In one possible implementation, the notification message is a fault notification message;

[0418] The packet control module 1202 is specifically used to: reduce the proportion of traffic allocated to the target forwarding path.

[0419] In one possible implementation, the target node is the upstream forwarding node adjacent to the first forwarding node.

[0420] In one possible implementation, the device further includes:

[0421] The message sending module is used to send an announcement message to the upstream node if the target node does not have a route to switch to, instructing the upstream node to control the subsequent data packets of the target forwarding path.

[0422] In one possible implementation, the device further includes:

[0423] The message receiving module is used to receive the release message from the first forwarding node. The release message carries the target identifier.

[0424] The control release module is used to release control over subsequent data packets on the target forwarding path.

[0425] It should be noted that the notification device provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the notification device and notification method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0426] Figure 13This is a schematic diagram of a flow control notification device provided in an embodiment of this application. This device can be implemented as part or all of a forwarding node by software, hardware, or a combination of both. See also... Figure 13 The device includes a code block acquisition module 1301 and a code block transmission module 1302.

[0427] The code block acquisition module 1301 is used to acquire a first code block, which is used to instruct the first forwarding node to perform flow control. The first forwarding node is the upstream forwarding node of the second forwarding node.

[0428] The code block sending module 1302 is used to send the first code block to the first forwarding node.

[0429] In one possible implementation, the first forwarding node is an upstream forwarding node adjacent to the second forwarding node.

[0430] In one possible implementation, the first code block is periodically generated by the second forwarding node and sent to the first forwarding node; or, the first code block is generated by the second forwarding node and sent to the first forwarding node after detecting a congestion or fault event.

[0431] In one possible implementation, the first code block carries first capability indication information, which is used to indicate the data reception capability of the ingress port of the second forwarding node.

[0432] In one possible implementation, the first capability indication information is specifically used to indicate the data reception capability of the target queue at the ingress port of the second forwarding node, and the first code block also carries the priority of the target queue.

[0433] In one possible implementation, the first code block also carries second capability indication information, which is used to indicate the data reception capability of the shared buffer of multiple ports of the second forwarding node.

[0434] In one possible implementation, the first code block is an ordered set encoded block in 64B / 66B format.

[0435] It should be noted that the flow control device provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the flow control device and the flow control method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0436] Figure 14This is a schematic diagram of a flow control device provided in an embodiment of this application. This device can be implemented as part or all of a forwarding node by software, hardware, or a combination of both. See also... Figure 14 The device includes a code block receiving module 1401 and a flow control module 1402.

[0437] The code block receiving module 1401 is used to receive the first code block sent by the second forwarding node, which is a downstream forwarding node of the first forwarding node;

[0438] The flow control module 1402 is used for flow control based on the first code block.

[0439] In one possible implementation, the second forwarding node is a downstream forwarding node adjacent to the first forwarding node.

[0440] In one possible implementation, the flow control module is specifically used for:

[0441] A second code block is generated based on local traffic conditions and the first code block. This second code block instructs a third forwarding node to perform traffic control; the third forwarding node is an upstream forwarding node of the first forwarding node. The first forwarding node sends the second code block to the third forwarding node; or...

[0442] Based on local traffic conditions and the first code block, an announcement message is generated. The announcement message carries a target identifier, which indicates the target forwarding path. The first forwarding node sends an announcement message to the third forwarding node to instruct the third forwarding node to control the subsequent data packets of the target forwarding path. The third forwarding node is the upstream forwarding node of the first forwarding node.

[0443] In one possible implementation, the flow control module is specifically used for:

[0444] The proportion of traffic sent to the second forwarding node is reduced based on the first code block.

[0445] It should be noted that the flow control device provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the flow control device and the flow control method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0446] Figure 15 This is a schematic diagram of the structure of a forwarding node provided in an embodiment of this application. For example... Figure 15As shown, the forwarding node 1500 includes a processor 1501, a forwarding chip 1502, and at least one network interface 1503. Optionally, combined with Figure 5 Let's take a look. Figure 15 Forwarding node 1500 is Figure 5 Any of the forwarding nodes shown.

[0447] Optionally, the processor 1501 includes a central processing unit (CPU) and / or a dedicated hardware chip. The CPU refers to a general-purpose CPU with high scalability and flexibility. A CPU can be, for example, a single-core processor or a multi-core processor. The dedicated hardware chip is a high-performance processing hardware module. The dedicated hardware chip includes at least one of an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a network processor (NP).

[0448] The forwarding chip 1502 is used to forward requests and data. For example, the forwarding chip 1502 is used to forward messages sent and received by node 1500.

[0449] At least one network interface 1503 includes, for example, Figure 15 Network interface 1, network interface 2, network interface 3... network interface n. Network interface 1503 uses any transceiver-like device for communicating with other devices or communication networks. For example, Figure 15 Network interface 1 communicates with the control device. Figure 15 Network interface 2 communicates with other forwarding nodes. Optionally, network interface 1503 includes at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a wireless protected local area networks (WLAN) interface, a cellular network interface, or a combination thereof.

[0450] At least one network interface 1503 is connected to a forwarding chip 1502, and the forwarding chip 1502 is connected to a processor 1501 via an internal connection 1504. The internal connection 1504 includes a path for transmitting data between the network interface 1503, the forwarding chip 1502, and the processor 1501. Optionally, the internal connection 1504 is a single board or a bus. For example, the internal connection 1504 is Ethernet, Fibre Channel, PCI-E (Peripheral Component Interconnect Express, PCI Express, a high-speed serial computer bus), RapidIO (a high-performance, low-pin-count, packet-switched interconnect architecture), InfiniBand, or XAUI bus (an interface extender characterized by connecting the Ethernet media access control (MAC) layer to the physical layer).

[0451] Optionally, the forwarding node 1500 also includes a content addressable memory (CAM) 1505. CAM 1505 may be, for example, a ternary content addressable memory (TCAM). CAM 1505 is used, for example, to store the mapping between record service flow identifiers and flow control requirements. Optionally, CAM 1505 exists independently and is connected to the forwarding chip 1502 via the aforementioned internal connection 1504. Alternatively, CAM 1505 and the forwarding chip 1502 are integrated, i.e., CAM 1505 serves as the internal memory of the forwarding chip 1502.

[0452] Optionally, the forwarding node 1500 also includes a memory 1506. The memory 1506 may be, for example, a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions; a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions; an electrically erasable programmable read-only memory (EEPROM); a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.); a magnetic disk storage medium; or any other medium capable of carrying or storing desired program code 1508 in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 1506 may exist independently and be connected to the processor 1501 via an internal connection 1504. Alternatively, the memory 1506 and the processor 1501 may be integrated together.

[0453] The memory 1506 stores an operating system 1507 and program code 1508. Optionally, the processor 1501 reads the operating system 1507 from the memory 1506 and runs the operating system 1507. The processor 1501 also reads the program code 1508 from the memory 1506 and runs the program code 1508 on the operating system 1507 to implement the actions performed by any of the forwarding nodes in the above-described methods provided in the embodiments of this application.

[0454] Optionally, the aforementioned devices are disposed on separate chips, or at least partially or entirely on the same chip. Whether the devices are disposed independently on different chips or integrated on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0455] This application embodiment also provides a notification system, the system including a first forwarding node and a target node. The first forwarding node and the target node are used to implement the above. Figure 7 The method described in the embodiment.

[0456] This application embodiment also provides a traffic control system, the system including a first forwarding node and a second forwarding node, the first and second forwarding nodes being used to implement the above. Figure 10 The method described in the embodiment.

[0457] This application also provides a chip, which includes programmable logic circuitry and / or program instructions. When the chip is running, it implements the above-described functionality. Figure 7 or Figure 10 The steps performed by the forwarding node in the illustrated embodiment.

[0458] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the aforementioned notification method or flow control method.

[0459] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the above-described notification method or flow control method.

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

[0461] It should be understood that "multiple" as mentioned herein refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., do not necessarily imply that they are different.

[0462] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0463] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A notification method, characterized in that, The method includes: The first forwarding node receives an announcement message, which carries a target identifier and indicates the target forwarding path. The first forwarding node sends the notification message to the target node to instruct the target node to control the subsequent data packets of the target forwarding path. The target node is the upstream node of the first forwarding node.

2. The method as described in claim 1, characterized in that, The target node is an upstream forwarding node adjacent to the first forwarding node; or, the target node is a sending end.

3. The method as described in claim 1 or 2, characterized in that, The target identifier includes the identifier of the target forwarding path.

4. The method as described in claim 1 or 2, characterized in that, The target identifier includes the entropy value of the target data packet and the destination address.

5. The method according to any one of claims 1-4, characterized in that, The notification message is a User Data Protocol (UDP) message, and the payload of the UDP message includes the target identifier; or, the notification message is a Network Protocol (IP) message, and the payload of the IP message includes the target identifier.

6. The method according to any one of claims 1-5, characterized in that, The notification message also carries congestion location information and / or congestion degree information. The congestion location information indicates the location of congestion in the target forwarding path, and the congestion degree information indicates the degree of congestion in the target forwarding path.

7. The method according to any one of claims 1-5, characterized in that, The notification message also carries fault location information and / or fault type, wherein the fault location information indicates the location where the fault occurred in the target forwarding path, and the fault type indicates the type of fault that occurred in the target forwarding path.

8. A notification method, characterized in that, The method includes: The target node receives an announcement message from the first forwarding node. The announcement message carries a target identifier, which indicates the target forwarding path. The first forwarding node is a downstream forwarding node of the target node. The target node controls subsequent data packets along the target forwarding path.

9. The method as described in claim 8, characterized in that, The target node is the sending end.

10. The method as described in claim 9, characterized in that, The notification message also carries congestion location information, which indicates the location where congestion occurs in the target forwarding path; The target node controls subsequent data packets along the target forwarding path, including: If the congestion location information indicates that a forwarding node connected to the receiving end is congested, the target node reduces the rate at which it sends data packets to the receiving end.

11. The method as described in claim 10, characterized in that, The notification message also carries congestion level information, which is used to indicate the degree of congestion in the target forwarding path; The target node reduces the rate at which it sends data packets to the receiving end, including: Based on the congestion information, the target node reduces the speed at which it sends data packets to the receiving end.

12. The method as described in claim 9, characterized in that, The notification message also carries congestion location information, which indicates the location where congestion occurs in the target forwarding path; The target node controls subsequent data packets along the target forwarding path, including: If the congestion location information indicates that an intermediate forwarding node is congested, the target node reduces the proportion of traffic allocated to the target forwarding path.

13. The method as described in claim 12, characterized in that, The notification message also carries congestion level information, which is used to indicate the degree of congestion in the target forwarding path; The target node reduces the proportion of traffic allocated to the target forwarding path, including: Based on the congestion information, the target node reduces the proportion of traffic allocated to the target forwarding path.

14. The method as described in claim 9, characterized in that, The notification message is a fault notification message; The target node controls subsequent data packets along the target forwarding path, including: The target node reduces the proportion of traffic allocated to the target forwarding path.

15. The method as described in claim 8, characterized in that, The target node is an upstream forwarding node adjacent to the first forwarding node.

16. The method as described in claim 15, characterized in that, The method further includes: If the target node does not have a route to switch to, the target node sends the notification message to the upstream node to instruct the upstream node to control the subsequent data packets of the target forwarding path.

17. The method according to any one of claims 8-16, characterized in that, After the target node controls subsequent data packets of the target forwarding path, the method further includes: The target node receives a release message from the first forwarding node, the release message carrying the target identifier; The target node releases control over subsequent data packets on the target forwarding path.

18. A flow control method, characterized in that, The method includes: The second forwarding node obtains the first code block, which is used to instruct the first forwarding node to perform flow control. The first forwarding node is the upstream forwarding node of the second forwarding node. The second forwarding node sends the first code block to the first forwarding node.

19. The method as described in claim 18, characterized in that, The first forwarding node is an upstream forwarding node adjacent to the second forwarding node.

20. The method as described in claim 18 or 19, characterized in that, The first code block is generated periodically by the second forwarding node and sent to the first forwarding node; or, the first code block is generated by the second forwarding node after detecting a congestion or fault event and sent to the first forwarding node.

21. The method according to any one of claims 18-20, characterized in that, The first code block carries first capability indication information, which is used to indicate the data reception capability of the ingress port of the second forwarding node.

22. The method as described in claim 21, characterized in that, The first capability indication information is specifically used to indicate the data reception capability of the target queue at the ingress port of the second forwarding node, and the first code block also carries the priority of the target queue.

23. The method as described in claim 21 or 22, characterized in that, The first code block also carries second capability indication information, which is used to indicate the data receiving capability of the shared buffer of multiple ports of the second forwarding node.

24. The method according to any one of claims 18-23, characterized in that, The first code block is an ordered set encoded block in 64B / 66B format.

25. A flow control method, characterized in that, The method includes: The first forwarding node receives the first code block sent by the second forwarding node, where the second forwarding node is a downstream forwarding node of the first forwarding node; The first forwarding node performs flow control based on the first code block.

26. The method as described in claim 25, characterized in that, The second forwarding node is a downstream forwarding node adjacent to the first forwarding node.

27. The method as described in claim 25 or 26, characterized in that, The first forwarding node performs flow control based on the first code block, including: The first forwarding node generates a second code block based on local traffic conditions and the first code block. This second code block instructs a third forwarding node to perform traffic control. The third forwarding node is an upstream forwarding node of the first forwarding node. The first forwarding node sends the second code block to the third forwarding node; or... The first forwarding node generates an announcement message based on local traffic conditions and the first code block. The announcement message carries a target identifier, which indicates a target forwarding path. The first forwarding node sends the announcement message to a third forwarding node to instruct the third forwarding node to control subsequent data packets of the target forwarding path. The third forwarding node is an upstream forwarding node of the first forwarding node.

28. The method as described in claim 25 or 26, characterized in that, The first forwarding node performs flow control based on the first code block, including: The first forwarding node reduces the proportion of traffic sent to the second forwarding node based on the first code block.

29. A notification device, characterized in that, Included in a first forwarding node, the device includes at least one module, the at least one module being used to implement the notification method according to any one of claims 1-7.

30. A notification device, characterized in that, The device, contained in the target node, includes at least one module for implementing the notification method according to any one of claims 8-17.

31. A flow control device, characterized in that, Included in a second forwarding node, the device includes at least one module for implementing the notification method according to any one of claims 18-24.

32. A flow control device, characterized in that, Included in a first forwarding node, the device includes at least one module for implementing the notification method according to any one of claims 25-29.

33. A notification system, characterized in that, The system includes a first forwarding node and a target node; The first forwarding node includes the notification device of claim 29, and the target node includes the notification device of claim 30.

34. A flow control system, characterized in that, The system includes a first forwarding node and a second forwarding node; The second forwarding node includes the flow control device of claim 31, and the first forwarding node includes the flow control device of claim 32.

35. A node, characterized in that, The node includes a memory and a processor; The memory is used to store a computer program, and the processor is used to execute the computer program to implement the notification method according to any one of claims 1-7, or the notification method according to any one of claims 8-17, or the flow control method according to any one of claims 18-24, or the flow control method according to any one of claims 25-29.

36. A chip, characterized in that, The chip includes programmable logic circuits and / or program instructions, which, when the chip is running, implement the notification method according to any one of claims 1-7, or the notification method according to any one of claims 8-17, or the flow control method according to any one of claims 18-24, or the flow control method according to any one of claims 25-29.

37. A computer-readable storage medium, characterized in that, The storage medium stores instructions that, when executed on the computer, cause the computer to perform the notification method according to any one of claims 1-7, or the notification method according to any one of claims 8-17, or the flow control method according to any one of claims 18-24, or the flow control method according to any one of claims 25-29.

38. A computer program product containing instructions, characterized in that, When the instructions are executed on a computer, the computer performs the notification method according to any one of claims 1-7, or the notification method according to any one of claims 8-17, or the flow control method according to any one of claims 18-24, or the flow control method according to any one of claims 25-29.

Images