Optical data center network architecture for centralized scheduling

Abstract

The invention relates to the technical field of optical data center networks, in particular to an optical data center network architecture for centralized scheduling. According to the optical data center network architecture disclosed by the invention, during reconfiguration, the architecture fixes a logical topology and performs greedy reconfiguration according to a real-time traffic demand. In this way, on one hand, the complexity of reconfiguration calculation is reduced, and on the other hand, it is ensured that the network is always connected and the diameter is very small, so that the small flow can be rapidly completed in a multi-hop mode. In the period, the centralized arbiter can also carry out limited transfer on the large flow according to the real-time flow requirement and the network topology, so that the overall throughput is further improved. According to the method, small-flow low delay and overall high throughput can be considered.

Description

Technical Field

[0001] The present invention relates to the technical field of optical data center networks, and in particular to an optical data center network architecture oriented to centralized scheduling. Background Art

[0002] In recent years, with the rapid development of short video applications, autonomous driving technology, and large language models, data centers, as infrastructure, have played a vital role in storing, processing, and transmitting massive amounts of data. These data centers are experiencing continuous expansion, diverse application scenarios, and growing data processing demands. However, as Moore's Law gradually breaks down, the growth rate of internal data center traffic has outpaced the increase in computing power. In the future, data center network transmission based on electrical switches will become a major bottleneck.

[0003] To address this challenge, academia and industry have proposed building optical data center networks using optical switching technology. Unlike traditional electrical switching data centers, optical data centers require scheduling before data transmission. However, high scheduling latency poses new challenges to data center networks.

[0004] Network latency in optical data centers is primarily composed of scheduling delay, propagation delay, store-and-forward delay, and queuing delay on both the end-side and network sides. Scheduling delay is the primary contributor to end-to-end latency for latency-sensitive small flows, while the end-to-end latency of bandwidth-sensitive large flows depends primarily on the bandwidth available. Because the sources of end-to-end latency for small and large flows differ, their optimization strategies differ.

[0005] The existing optical data center network architecture is as follows Figure 1 As shown in the figure, under the current architecture, to optimize the transmission of large flows, on-demand scheduling is typically used. This method dynamically adjusts the network topology to adapt to the traffic patterns of the data center, thereby maximizing bandwidth utilization. For optimizing small flows, existing methods typically maintain network connectivity and utilize multi-hop forwarding with the help of ToR to achieve efficient transmission of small flows. However, existing solutions cannot optimize both large and small flows.

[0006] Opera (Expanding across time to deliver bandwidth efficiency and low latency) is a representative work on optimizing small flows. Opera employs a traffic-aware reconfiguration scheme for network reconfiguration. Specifically, when any flow arrives at a Tor of Relay (TR), the Tor of Relay first randomly selects a currently connected Tor of Relay (TR) as a transit Tor of Relay (TR). The transit Tor of Relay then connects to the final destination of the flow and completes the data transmission. In this way, Opera ensures that all flows reach their destination through only one transit.

[0007] Opera mainly optimizes small flows. In order to reduce the end-to-end delay of small flows, Opera distinguishes between large and small flows on the ToR side and processes them separately. In terms of optimizing small flows, Opera adopts two key designs: (1) When reconfiguring, not all optical switches are reconfigured at the same time, but in batches; (2) the topology rotation mode and optical switch reconfiguration batches are carefully designed. Through these two designs, Opera ensures that the network always remains connected and forms a low-diameter expansion graph (i.e., a connectivity graph). On this basis, Opera allows small flows to be transferred through ToR, realizing a packet switching method similar to traditional electrical switches, so that small flows do not need to wait for scheduling, thereby significantly reducing end-to-end delay. As Figure 2 shown.

[0008] Under the Opera architecture, the transmission of large flows adopts the RoToRLB solution (derived from the paper RoToRNet: A Scalable, Low-complexity, Optical Datacenter Network). RoToRLB operates in a distributed manner, and its core is that the transit ToR combines its own remaining buffer size, received requests, and future network topology to dynamically decide on the data forwarding strategy. Its operation process is as follows: (1) At the end of each reconfiguration and the beginning of a new cycle, the source ToR randomly selects a currently connected ToR as a potential transit ToR and sends a request to it; (2) After receiving all requests, the potential transit ToR decides whether to accept the request based on its own remaining buffer capacity to the destination and the total amount of data that can be transmitted, and returns the receivable data size; (3) After receiving the authorization, the source ToR sends data based on the authorization result. Figure 3 shown.

[0009] In the current cycle, ToR1 has 0.75 units of data (1 unit is the maximum amount of data sent in a cycle) destined for ToR1 locally and 0.25 units of data sent to ToR2 on behalf of other ToRs. It also has 0.25 units of data destined for ToR2 locally and 0.5 units of data sent to ToR3 on behalf of other ToRs. ToR2 has 1 unit of local traffic destined for ToR3 and 1 unit of traffic destined for ToR4. In the current cycle, ToR1 and ToR2 are interconnected, and ToR2 wants ToR1 to help forward traffic destined for ToR3 and ToR4. Since ToR1 already has 0.75 units of traffic destined for ToR3, it can only accept 0.25 units of traffic from ToR2. Although ToR1 has no local traffic destined for ToR4, it has already authorized ToR2 to forward 0.25 units of traffic, so it can still authorize 0.75 units. Therefore, ToR1 ultimately authorizes ToR2 to forward 0.25 units of traffic destined for ToR3 and 0.75 units of traffic destined for ToR4.

[0010] Opera uses the above approach to handle both large and small flows separately. Because Opera ensures constant network connectivity, it achieves exceptional end-to-end latency for small flows. Distributed processing of large flows also significantly reduces network complexity.

[0011] Opera faced the challenge of insufficient throughput. It used RoToRLB to transmit large flows, but when the network was heavily loaded, almost all large flows required two hops to complete. Consequently, its effective throughput was only 50% under high network load. Furthermore, to ensure consistent network connectivity, Opera performed partial updates during each reconfiguration, which lengthened the cycle. As the network scaled, the cycle increased further, making scheduling latency unbearable for large flows, further reducing throughput.

[0012] In summary, existing optical data center solutions reduce the end-to-end latency of small flows by ensuring constant network connectivity. However, their overall throughput is constrained by the traffic-agnostic RoToRLB (RoToRLB), resulting in an effective throughput of only 50% under high load. Furthermore, their long cycle times make the scheduling latency of large flows unacceptable as the network scales further, further reducing throughput. Summary of the Invention

[0013] Therefore, the technical problem to be solved by the present invention is to overcome the problem in the prior art that it is impossible to take into account both the end-to-end delay of small flows and the overall throughput.

[0014] To solve the above technical problems, the present invention provides an optical data center network architecture, comprising:

[0015] an optical switch layer, comprising multiple optical switches;

[0016] The ToR switch layer includes multiple ToR switches, each connected to an optical switch. These switches periodically send local traffic demand and link status information to the centralized arbitrator, and implement data packet transmission and forwarding based on the centralized arbitrator's scheduling.

[0017] A centralized arbitrator is connected to multiple optical switches and multiple ToR switches, and is used to reconfigure the topology according to the fixed logical topology and real-time traffic demand at the beginning of a new cycle. The fixed logical topology adopts a small diameter expansion graph.

[0018] It is also used to generate large flow transfer result instructions and link fault avoidance instructions based on real-time traffic demand and link status information within a cycle.

[0019] Preferably, the small-diameter expansion graph comprises a De Bruijn graph.

[0020] Preferably, each of the ToR switches has the ability to depacketize and trim packets, and has a destination cache for large flow data packets and a port cache for small flow data packets.

[0021] Preferably, the ToR switch layer is used to periodically send local traffic demand and link status information to the centralized arbitrator, including:

[0022] Each ToR switch is used to:

[0023] Send local traffic demands to the centralized arbitrator in real time;

[0024] At the beginning of each cycle, an empty packet is sent to the remaining ToR switches. When a ToR switch among the remaining ToR switches does not receive the corresponding empty packet, the link status information indicating that the corresponding link is faulty is sent to the centralized arbitrator.

[0025] Preferably, the centralized arbitrator is configured to generate a link failure avoidance instruction according to real-time traffic demand and link status information within a period, including:

[0026] The centralized arbitrator is used to mark the faulty link as an unavailable link according to the link status information, issue updated routing information, and avoid the unavailable link in subsequent topology reconfiguration to generate a new topology configuration.

[0027] Preferably, the centralized arbitrator is used to generate a large flow transfer result instruction according to real-time traffic demand and link status information within a period, including:

[0028] The centralized arbitrator is used to:

[0029] Determine that the links from the port ToR switch to the transit ToR switch and then to the destination ToR switch are all idle links as transit links;

[0030] Count the number of large flow packets that request to be transferred on each idle link on the allowed transit link, and evenly allocate the bandwidth on each idle link on the allowed transit link to the large flow packets that request to be transferred;

[0031] For each large flow data packet requested for transfer, the smaller bandwidth value on the corresponding two idle links is selected as the maximum allowed sending rate for the transfer of the large flow data packet.

[0032] Preferably, the centralized arbitrator is configured to perform topology reconfiguration according to the fixed logical topology and real-time traffic demand at the beginning of a new cycle, including:

[0033] The centralized arbitrator is used to judge the network status based on the preset network objective function and real-time traffic demand. When the preset network objective function value is greater than the preset threshold, the current cycle is ended and the topology is reconfigured according to the fixed logical topology and real-time traffic demand to generate the topology configuration corresponding to the new cycle.

[0034] Preferably, the topology reconfiguration method includes:

[0035] When the computational latency requirement is higher than the first preset condition, topology reconfiguration is performed using a random mapping approach;

[0036] When the computational delay requirement is lower than the second preset condition, topology reconfiguration is performed by iteratively approximating the optimal solution;

[0037] In other cases, a heuristic algorithm is used to perform topology reconfiguration.

[0038] Preferably, the ToR switch layer is used to implement the transmission and transfer of data packets based on the scheduling of the centralized arbitrator, including:

[0039] Each ToR switch is used to:

[0040] Acting as a router in transit according to the network transmission protocol, it reliably transmits small flow data packets;

[0041] Based on the low-diameter characteristics of the small-diameter expansion graph, small flow data packets are forwarded through multiple hops to quickly complete transmission;

[0042] Send large flow packets directly to the destination ToR switch;

[0043] According to the large flow forwarding result instruction, the large flow data packet is sent to the designated forwarding ToR switch at the maximum allowed sending rate.

[0044] Preferably, the order in which each ToR switch sends packets is:

[0045] Send transport layer protocol control packets;

[0046] Send non-local small flow data packets with the current connected ToR switch as the destination;

[0047] Send the local small flow data packet of the port currently connected to the ToR switch;

[0048] Send non-local large flow data packets with the current connected ToR switch as the destination;

[0049] Send the local large flow data packet currently connected to the ToR switch, which is the port;

[0050] According to the large flow forwarding result instruction, the large flow data packet is sent to the designated forwarding ToR switch.

[0051] The above technical solution of the present invention has the following advantages over the prior art:

[0052] The optical data center network architecture described in this invention, during reconfiguration, maintains a fixed logical topology and performs greedy reconfiguration based on real-time traffic demands. This approach reduces the computational complexity of reconfiguration while ensuring a consistently connected network with a small diameter, enabling small flows to complete quickly over multiple hops. Within a cycle, a centralized arbitrator also performs limited relaying of large flows based on real-time traffic demands and network topology, further improving overall throughput. This invention achieves both low latency for small flows and high overall throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to make the content of the present invention more clearly understood, the present invention is further described in detail below based on specific embodiments of the present invention in conjunction with the accompanying drawings, wherein:

[0054] Figure 1 This is a schematic diagram of the architecture of a centrally scheduled data center in the prior art;

[0055] Figure 2 This is a diagram of the Opera architecture;

[0056] Figure 3 This is the RotorLB example diagram;

[0057] Figure 4 This is a diagram of an optical data center network architecture provided by the present invention;

[0058] Figure 5 This is a schematic diagram of De Bruijn;

[0059] Figure 6 This is an example diagram of the large-scale transit flow control algorithm. DETAILED DESCRIPTION

[0060] The core of the present invention is to provide an optical data center network architecture that effectively takes into account both low latency for small flows and high overall throughput.

[0061] In order to enable those skilled in the art to better understand the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0062] Please refer to Figure 4 , Figure 4 This is a diagram of an optical data center network architecture provided by the present invention; specifically including:

[0063] Optical switch layer 1, including multiple optical switches;

[0064] ToR switch layer 2, including multiple ToR switches, is connected to each optical switch and is used to periodically send local traffic demand and link status information to the centralized arbitrator, and realize the transmission and transfer of data packets based on the scheduling of the centralized arbitrator;

[0065] The centralized arbitrator 3 is connected to multiple optical switches and multiple ToR switches respectively, and is used to perform topology reconfiguration according to the fixed logical topology and real-time traffic demand at the beginning of a new cycle. The fixed logical topology adopts a small diameter expansion graph.

[0066] It is also used to generate large flow transfer result instructions and link fault avoidance instructions based on real-time traffic demand and link status information within a cycle.

[0067] The present invention uses a centralized arbitrator to collect network traffic requirements and issue routing, large flow forwarding, reconfiguration and other information. The ToR switches are connected by a layer of optical switches to form a flat ToR switch interconnection structure.

[0068] Implementation of this invention requires modifications to the centralized arbitrator and switches. Specifically, the centralized arbitrator must calculate a reasonable new topology based on a fixed logical topology and collected real-time traffic demand. Within a cycle, the centralized arbitrator must also calculate reasonable large flow forwarding. The ToR switches, on the other hand, must be able to buffer small forwarding flows.

[0069] To achieve data packet transfer, each ToR switch has a destination cache for large flow data packets and a port cache for small flow data packets; and has the ability to depacketize and trim packets to implement network transmission protocols.

[0070] Based on the above embodiments, this embodiment uses the ToR (ToR) interconnected flat topology, which is currently the most common structure in optical data centers and expands upon it to maximize compatibility with current implementations. A centralized arbitrator is responsible for topology reconfiguration, routing, and transit flow control.

[0071] This embodiment adopts centralized control and on-demand reconfiguration. In order to ensure that the network topology is always a small-diameter expansion graph to reduce the end-to-end delay of small flows, a fixed logical topology design is adopted.

[0072] In a specific embodiment, the logical topology used is a De Bruijn graph, such as Figure 5As shown in the figure. For a De Bruijn graph with N vertices, where each vertex has a degree of k, the connection method is as follows: Each vertex is numbered. If y = (xd + i) mod N, where i < d, then there is a directed edge from x to y. For a De Bruijn graph with N vertices and each vertex having a degree of k, its diameter is lnN / lnk, which is almost up to the Moore bound (the lower bound of the diameter given by the degree-vertex problem in graph theory). The advantage of using a De Bruijn graph is that the network diameter is small and the network has high robustness. During reconfiguration, the centralized arbiter can adopt the corresponding logical topology according to the corresponding tasks in the data center.

[0073] Based on the above embodiments, the ToR needs to regularly count the traffic information and link status information and send them to the centralized arbiter for scheduling. In order to detect the link status, the present invention requires the ToR to regularly send empty packets, that is, at the beginning of each cycle, send empty packets to the other ToR switches. When there is a certain ToR switch among the other ToR switches that does not receive the corresponding empty packet, the link status information indicating that the corresponding link has a fault is sent to the centralized arbiter.

[0074] Based on the above embodiments, the functions of the centralized arbiter mainly include determining the end of the cycle and generating a new topology configuration, generating a large flow transfer result instruction and a link fault avoidance instruction according to the traffic demand and the network link status;

[0075] In one embodiment, the centralized arbiter judges the network status according to the preset network objective function and the real-time traffic demand. When the value of the preset network objective function is greater than the preset threshold, the current cycle is ended and topology reconfiguration is performed according to the fixed logical topology and the real-time traffic demand to generate the topology configuration corresponding to the new cycle. Since the logical topology is fixed in the present invention, the reconfiguration of the present invention is equivalent to mapping the logical topology to the actual topology according to the traffic demand.

[0076] Based on the above embodiments, the method for the topology reconfiguration includes:

[0077] Reconfiguration method: Reconfigure all optical switches simultaneously;

[0078] When the computing delay requirement is higher than the first preset condition, a random mapping method is adopted for topology reconfiguration;

[0079] When the computing delay requirement is lower than the second preset condition, an iterative approximation of the optimal solution method is adopted for topology reconfiguration;

[0080] In other cases, a heuristic algorithm is adopted for topology reconfiguration.

[0081] In one embodiment, the centralized arbitrator marks the faulty link as an unavailable link based on the link status information, sends updated routing information to prevent the flow from continuing to be sent through the faulty link, and avoids the unavailable link in subsequent topology reconfiguration to generate a new topology configuration.

[0082] In one embodiment, since there are a considerable number of idle links in the optical data center, the present invention utilizes these idle links from the global perspective of the centralized arbitrator for the transfer of large flows. At the same time, in order to avoid affecting the direct flow, the present invention can only transfer when all the links from the source ToR to the transfer ToR to the destination ToR are idle. The specific algorithm is as follows: Figure 6 As shown:

[0083] Determine that the links from the port ToR switch to the transit ToR switch and then to the destination ToR switch are all idle links as transit links;

[0084] Count the number of large flow packets that request to be transferred on each idle link on the allowed transit link, and evenly allocate the bandwidth on each idle link on the allowed transit link to the large flow packets that request to be transferred;

[0085] For each large flow data packet requested for transfer, the smaller bandwidth value on the corresponding two idle links is selected as the maximum allowed sending rate for the transfer of the large flow data packet.

[0086] Based on the above embodiments, the ToR switch in the present invention is mainly responsible for the transmission and transfer of data packets:

[0087] Data packet transmission primarily involves large flows and small flows. Small flows utilize a network transmission protocol, and in one specific embodiment, the NDP routing protocol. Because the ToR switch in the present invention also handles data packet forwarding, the ToR switch in the present invention involves a total of four types of data packets: local small flow data packets, non-local small flow data packets, local large flow data packets, and non-local large flow data packets. In addition, there are control packets corresponding to the transmission protocol.

[0088] For small flows, the transport layer protocol directly adopted by the network treats the ToR as a router in transmission for reliable transmission; and based on the low-diameter characteristics of the small-diameter expansion graph, multi-hop forwarding of small flow data packets is performed to quickly complete the transmission.

[0089] For large flows, the ToR switch will send the large flows with the connected ToR switch as the final destination ToR switch, and will also send the large flows with the connected ToR switch as the transit ToR switch according to the scheduling results of the centralized arbitrator. To prevent large flows from accumulating at the transit ToR, the centralized arbitrator needs to send the routing of the large flows as well as the sending rate.

[0090] Based on the above embodiments, the order of sending packets by ToR in the present invention is:

[0091] Send transport layer protocol control packets;

[0092] Send non-local small flow data packets with the current connected ToR switch as the destination;

[0093] Send the local small flow data packet of the port currently connected to the ToR switch;

[0094] Send non-local large flow data packets with the current connected ToR switch as the destination;

[0095] Send the local large flow data packet currently connected to the ToR switch, which is the port;

[0096] According to the large flow forwarding result instruction, the large flow data packet is sent to the designated forwarding ToR switch.

[0097] In order to solve the problem that existing solutions cannot take into account both the end-to-end latency of small flows and the overall throughput, the present invention designs an optical data center network architecture for centralized scheduling, which can take into account both the low latency of small flows and the overall high throughput. During reconfiguration, the architecture fixes the logical topology and performs greedy reconfiguration based on real-time traffic requirements. In this way, on the one hand, the computational complexity of reconfiguration is reduced, and on the other hand, it ensures that the network is always connected and has a small diameter, so that small flows can be completed quickly through multiple hops. During the cycle, the centralized arbitrator will also perform limited transit on large flows based on real-time traffic requirements and network topology, thereby further improving the overall throughput.

[0098] The core innovation of the present invention is that by fixing the network logical topology as a small-diameter expansion graph, the end-to-end delay of small flows is ensured to be extremely low, while centralized on-demand scheduling ensures overall high throughput.

[0099] Its subordinate innovations include:

[0100] Reconfiguration for different latency requirements: By setting up multiple reconfiguration algorithms for different calculation delays on the centralized arbitrator, the optimal configuration result can be obtained while meeting different latency requirements.

[0101] Large flow transit flow control algorithm: This algorithm is designed to address insufficient link utilization, allowing large flows to be transited fairly through idle links without affecting the direct delivery of existing large flows, thereby significantly improving throughput.

[0102] Link fault detection: This solution detects the network link status by periodically sending empty packets as probes.

[0103] While this invention is designed for data center networks, the techniques involved can be extended to other fields. The fixed logic topology reconfiguration in this invention can be applied to other centralized control systems to address computational complexity that is too high to meet latency requirements.

[0104] Obviously, the above embodiments are merely examples for clarity of explanation and are not intended to limit the implementation methods. Those skilled in the art will appreciate that other variations or modifications can be made based on the above description. It is not necessary and impossible to enumerate all implementation methods here. Obvious variations or modifications arising therefrom remain within the scope of protection of the present invention.

Claims

1. An optical data center network architecture, characterized in that: include: an optical switch layer, comprising multiple optical switches; The ToR switch layer includes multiple ToR switches, each connected to an optical switch. These switches periodically send local traffic demand and link status information to the centralized arbitrator, enabling data packet transmission and forwarding based on the centralized arbitrator's scheduling. A centralized arbitrator is connected to multiple optical switches and multiple ToR switches, and is used to reconfigure the topology according to the fixed logical topology and real-time traffic demand at the beginning of a new cycle. The fixed logical topology adopts a small diameter expansion graph. It is also used to generate large flow transfer result instructions and link fault avoidance instructions based on real-time traffic demand and link status information within a cycle.

2. The optical data center network architecture according to claim 1, characterized in that: The small diameter expansion graph includes a DeBruijn graph.

3. The optical data center network architecture according to claim 1, wherein: Each of the ToR switches has the ability to depacketize and trim packets, and has a destination cache for large flow data packets and a port cache for small flow data packets.

4. The optical data center network architecture according to claim 1, wherein: The ToR switch layer is used to periodically send local traffic demand and link status information to the centralized arbitrator, including: Each ToR switch is used to: Send local traffic demands to the centralized arbitrator in real time; At the beginning of each cycle, an empty packet is sent to the remaining ToR switches. When a ToR switch among the remaining ToR switches does not receive the corresponding empty packet, the link status information indicating that the corresponding link is faulty is sent to the centralized arbitrator.

5. The optical data center network architecture according to claim 4, characterized in that: The centralized arbiter is configured to generate a link failure avoidance instruction according to real-time traffic demand and link status information within a period, including: The centralized arbitrator is used to mark the faulty link as an unavailable link according to the link status information, issue updated routing information, and avoid the unavailable link in subsequent topology reconfiguration to generate a new topology configuration.

6. The optical data center network architecture according to claim 4, characterized in that: The centralized arbitrator is used to generate a large flow transfer result instruction according to real-time traffic demand and link status information within a period, including: The centralized arbitrator is used to: Determine that the links from the port ToR switch to the transit ToR switch and then to the destination ToR switch are all idle links as transit links; Count the number of large flow packets that request to be transferred on each idle link on the allowed transit link, and evenly allocate the bandwidth on each idle link on the allowed transit link to the large flow packets that request to be transferred; For each large flow data packet requested for transfer, the smaller bandwidth value on the corresponding two idle links is selected as the maximum allowed sending rate for the transfer of the large flow data packet.

7. The optical data center network architecture according to claim 4, characterized in that: The centralized arbiter is configured to perform topology reconfiguration according to the fixed logical topology and real-time traffic requirements at the beginning of a new cycle, including: The centralized arbitrator is used to judge the network status based on the preset network objective function and real-time traffic demand. When the preset network objective function value is greater than the preset threshold, the current cycle is ended and the topology is reconfigured according to the fixed logical topology and real-time traffic demand to generate the topology configuration corresponding to the new cycle.

8. The optical data center network architecture according to claim 1 or 7, characterized in that: The topology reconfiguration method includes: When the computational latency requirement is higher than the first preset condition, topology reconfiguration is performed using a random mapping approach; When the computational delay requirement is lower than the second preset condition, topology reconfiguration is performed by iteratively approximating the optimal solution; In other cases, a heuristic algorithm is used to perform topology reconfiguration.

9. The optical data center network architecture according to claim 1, wherein: The ToR switch layer is used to implement data packet transmission and transfer based on the scheduling of the centralized arbitrator, including: Each ToR switch is used to: Acting as a router in transit according to the network transmission protocol, it reliably transmits small flow data packets; Based on the low-diameter characteristics of the small-diameter expansion graph, small flow data packets are forwarded through multiple hops to quickly complete transmission; Send large flow packets directly to the destination ToR switch; According to the large flow forwarding result instruction, the large flow data packet is sent to the designated forwarding ToR switch at the maximum allowed sending rate.

10. The optical data center network architecture according to claim 9, wherein: The order in which each ToR switch sends packets is: Send transport layer protocol control packets; Send non-local small flow data packets with the current connected ToR switch as the destination; Send the local small flow data packet of the port currently connected to the ToR switch; Send non-local large flow data packets with the current connected ToR switch as the destination; Send the local large flow data packet currently connected to the ToR switch, which is the port; According to the large flow forwarding result instruction, the large flow data packet is sent to the designated forwarding ToR switch.

Images