Lossless ethernet emulation model
By designing a lossless Ethernet simulation model and adopting a collaborative control mechanism of PFC and ECN, the problems of model fragmentation and low simulation efficiency in existing technologies are solved, achieving high-precision and high-efficiency lossless network simulation and providing reliable design and optimization tools.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINESE AERONAUTICAL RADIO ELECTRONICS RES INST
- Filing Date
- 2026-04-02
- Publication Date
- 2026-07-14
AI Technical Summary
Existing simulation models cannot effectively simulate the collaborative operation of lossless Ethernet technologies, and it is difficult to improve simulation efficiency while ensuring simulation accuracy, thus failing to accurately reflect key phenomena in lossless networks.
A lossless Ethernet simulation model was designed, including a terminal simulation model and a switch simulation model. It adopts a collaborative control mechanism of PFC and ECN to achieve high-precision and high-efficiency simulation, supports multi-priority queues and RoCEv2 protocol, and combines port binding control, flow control and ECN congestion notification functions.
It achieves high-fidelity simulation of lossless networks, accurately reflects complex dynamic phenomena, reduces hardware simulation costs, and provides reliable design and optimization tools.
Smart Images
Figure CN122395066A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer network simulation technology, specifically involving a high-fidelity lossless Ethernet simulation model. This model can accurately simulate the collaborative working behavior of various lossless network technologies (such as PFC and ECN) used to ensure applications such as RDMA (Remote Direct Memory Access) in scenarios such as data centers and high-performance computing, as well as their impact on network performance. Background Technology
[0002] Lossless Ethernet achieves near-zero packet loss transmission by introducing a series of flow control and congestion management techniques (such as Priority-Based Flow Control (PFC) in IEEE 802.1Qbb and IP-based Explicit Congestion Notification (ECN)) to meet the stringent requirements of RDMA technology. Before designing, deploying, and optimizing lossless networks, verification using simulation is crucial. However, existing network simulation techniques face the following significant challenges:
[0003] 1. Fragmented Models and Lack of Synergy: Existing simulation models can typically only independently simulate a single lossless technology (such as simulating only PFC or only ECN), lacking the ability to simulate their complex interactions and collaborative work within a unified framework. In real networks, PFC (link-level, reactive) and ECN (end-to-end, proactive) work collaboratively, and the lack of this synergy leads to significant deviations between simulation results and real network performance.
[0004] 2. Difficulty in balancing accuracy and efficiency: In pursuit of simulation accuracy, detailed models are required, but this leads to a sharp increase in computational complexity, making it difficult to support the simulation of large-scale network topologies. On the other hand, simplifying models comes at the cost of accuracy, failing to accurately reflect key phenomena in lossless networks such as micro-burst traffic, queue backlog, and congestion propagation.
[0005] Therefore, there is an urgent need in this field for a new and systematic simulation model that can solve the above problems and achieve high-precision and high-efficiency lossless Ethernet simulation. Summary of the Invention
[0006] The purpose of this invention is to provide a lossless Ethernet simulation model that can accurately simulate the collaborative working mechanism of lossless technologies such as PFC and ECN. While ensuring simulation accuracy, it also takes into account operational efficiency and provides an effective model verification method, thus providing a reliable tool for the design and optimization of lossless networks.
[0007] The objective of this invention is achieved through the following technical solution:
[0008] A lossless Ethernet simulation model includes a terminal simulation model, characterized in that the terminal simulation model includes a port binding control model, a terminal switching model, an RDMA model, an Ethernet protocol model, and an APP application model;
[0009] The port binding control model is used to control Ethernet interfaces and send and receive frames.
[0010] The terminal switching model is used to support Layer 2 switching of Ethernet and RDMA data frames and to support PFC flow control.
[0011] The RDMA model is used to implement RDMA message sending and receiving via the RDMA RoCEv2 protocol and ECN congestion notification functionality.
[0012] The Ethernet protocol model is used to implement TCP / IP, UDP protocols, and ECN congestion notification functions for Ethernet messages;
[0013] The APP application model is used to generate RDMA messages and Ethernet messages based on the configuration file content, and to define the priority of each message.
[0014] Based on the above characteristics, the PFC flow control process during reception in the terminal switching model is as follows:
[0015] (1) After the terminal switching model receives the Ethernet frame forwarded by the port binding control model, it parses the frame header information. If it is a PAUSE frame of PFC, it continues to parse the payload content and obtains the backpressure enable vector priority_enable_vector and the backpressure timer time[priority] corresponding to each priority queue.
[0016] If the bit corresponding to priority_enable_vector is 1, it indicates that flow control is required, and the allowed transmission time of the next data frame is set according to the value of the time [priority] timer; if the bit corresponding to priority_enable_vector is 0, no action is taken, indicating that the timer is invalid.
[0017] (2) If the frame header is not a PFC PAUSE frame, then it is another data frame and is processed according to the normal forwarding logic to proceed to the next step;
[0018] (3) First, parse the priority of the data frame, put the payload data packet into the receiving sub-queue mapped to the priority, determine the length of the receiving sub-queue, if it is greater than the set flow control threshold XOFF, set the back pressure enable vector of the sub-queue to 1 and the value of time[priority]; then call the PFC frame sending function to put this flow control information into the next PFC PAUSE frame sent.
[0019] (4) Forward the payload data packets in the receiving sub-queue to the upper layer. If the length of the receiving sub-queue is less than the set flow control recovery threshold XON, set the bit corresponding to the back pressure enable vector to 0, the value of time[priority] to 0, and then call the PFC frame sending function to put this flow control information into the next PFC PAUSE frame sent.
[0020] (5) First, update the backpressure enable vector and backpressure timer of each sub-queue, and then determine whether the transmission interval has been reached. If the interval has been reached, encapsulate the current backpressure enable vector and backpressure timer status of each sub-queue into a PFC PAUSE frame and hand it over to the port binding control model for transmission.
[0021] Based on the above characteristics, the PFC flow control process during transmission in the terminal switching model is as follows:
[0022] (1) The terminal switching model receives the upper-layer data packet and puts it into the sending sub-queue according to the priority information;
[0023] (2) Determine the length of the sending sub-queue. If it is greater than the set flow control threshold XOFF, reduce the terminal service rate.
[0024] (3) Select the sending subqueue and check whether the corresponding timer allows sending. If yes, start sending Ethernet frames; otherwise, select the next sending subqueue.
[0025] (4) After completing the Ethernet frame transmission, check whether the length of all transmission sub-queues is less than the set flow control recovery threshold XON. If so, restore the terminal service rate.
[0026] Based on the above characteristics, the ECN congestion notification function of the Ethernet protocol model is as follows: when the Ethernet protocol model receives a data frame, it parses the IP protocol header. If the ECN bit indicates congestion, it updates the congestion mapping table. Then, it creates and sends CNP packets according to the congestion mapping table at regular intervals. When the Ethernet protocol model receives CNP packets, it limits the sending rate of the corresponding data stream.
[0027] Based on the above characteristics, the Ethernet protocol model includes a UDP module, a TCP module, an IP_encap module, an IP module, an ARP module, a MAC module, and an ECN module. The UDP module implements the User Datagram Protocol (UDP) for connectionless data transmission. The TCP module implements the Transmission Control Protocol (TCP) for connection-oriented data transmission. The IP_encap module is the interface layer between the transport layer and the IP module, performing IP packet encapsulation and decapsulation operations. The IP module implements routing and forwarding functions, as well as data packet fragmentation and reassembly operations. The ARP module maps IP addresses to physical MAC addresses; the address translation table is automatically generated by the ARP protocol and can also be read from static configurations. The MAC module provides send / receive interfaces for links with different transmission rates, receiving upper-layer protocol packets, encapsulating them into Ethernet frames, and sending them to the physical link; it also receives physical link data packets, decapsulates them, and forwards them to the upper layer. The ECN module parses the parameter identifiers in the TCP header and limits the transmission rate of the corresponding data stream.
[0028] Based on the above characteristics, the ECN congestion notification function of the RDMA model is as follows: After receiving the congestion notification, the RDMA model parses the parameter identifier in BTH and performs rate limiting on the problem QP for network data packets.
[0029] Based on the above characteristics, the RDMA model includes an RDMA module and a BTH module. The RDMA module establishes a QP connection to control the data transmission process; the BTH module uses the IP protocol to encapsulate RDMA data frames, performs data parsing / encapsulation operations, and performs ECN congestion management.
[0030] Based on the above characteristics, the APP application model obtains the terminal ID number of this terminal node, and uses the terminal ID to find the message ID number sent by the terminal, the length and period of the message, the sending application, and the configuration information of the receiving terminal. It generates the sending time according to the Poisson distribution, and generates RDMA messages and Ethernet messages in combination with the message types specified in the configuration file, and defines the priority. The message ID number, sending time, and receiving terminal information are stored in the message.
[0031] Based on the above characteristics, the port bonding control model controls two standard Ethernet interfaces and supports multiple bonding modes:
[0032] 1) In balanced polling mode, data frames are transmitted sequentially.
[0033] 2) Master-backup mode: Only one Ethernet interface is active at any given time. If one fails, the other immediately becomes active from backup.
[0034] 3) Balanced mode, which means XOR Hash load balancing, combined with the switch's forced non-negotiation aggregation method;
[0035] 4) Broadcast mode: All data frames are sent from all Ethernet interfaces.
[0036] Based on the above characteristics, the lossless Ethernet simulation model also includes a switch simulation model, which includes a MAC controller module, an IPE module, a TM module, and an EPE module.
[0037] The MAC controller is used to receive packets from the port and forward them to the IPE module;
[0038] The IPE module is used to parse received packets, obtain port and VLAN related attributes, perform lookup operations and obtain relevant information based on the lookup results. If routing is required, it performs L3 protocol packet processing, then performs Layer 2 forwarding operations based on the MAC destination address, applies control policies to packets according to ACL configuration, and performs traffic control management.
[0039] The TM module is used for enqueuing, recursing, and scheduling packets. Queue scheduling includes HQoS multi-level scheduling and packet duplication for broadcast / multicast scenarios.
[0040] The EPE module is used to inspect the scheduling result messages, complete L3 and L2 layer editing, perform ACL-related processing in the Egress direction, and finally send the edited messages to the MAC controller or loopback port for transmission.
[0041] The beneficial effects of this invention are as follows:
[0042] 1. Systematic: It provides a complete simulation model from component design and collaboration mechanism to verification process, which solves the problem of model fragmentation in existing technologies and realizes high-fidelity simulation of the entire chain of lossless network "end-pipe-collaboration".
[0043] 2. High precision: Thanks to the design of the PFC / ECN collaborative mechanism, the simulation results can accurately reflect the complex dynamics in the lossless network, such as congestion diffusion and delay jitter, and the simulation data is in high agreement with the real test data.
[0044] 3. Cost Reduction: This simulation model can effectively reduce hardware simulation costs. It plays a crucial role in the design and verification of current network configurations and network products. Attached Figure Description
[0045] Figure 1 This is a diagram of the overall structure of the simulation analysis system.
[0046] Figure 2 This is a structural diagram of the terminal simulation model.
[0047] Figure 3 Example of generating a PAUSE frame.
[0048] Figure 4 Example of generating a PAUSE frame for PFC function.
[0049] Figure 5 is a functional structure diagram of the switch simulation model.
[0050] Figure 6 A flowchart of PFC processing for the data receiving direction in the terminal switching model.
[0051] Figure 7 PFC processing flowchart for data direction in the terminal switching model. Detailed Implementation
[0052] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.
[0053] The overall structure of the simulation analysis system is as follows: Figure 1 As shown in the figure, this embodiment presents a lossless Ethernet simulation model, which features innovative design in terms of both model architecture and core simulation mechanism.
[0054] In terms of model architecture, the lossless Ethernet simulation model shown in this embodiment constructs a hierarchical simulation model system, which includes two core components:
[0055] 1. Terminal Emulation Model: Simulates terminal behavior, supports multi-priority queues and the RoCEv2 protocol, parses and processes CNP and PFC frames, implements algorithms such as DCQCN, and responds to ECN and PFC events. The terminal emulation model includes a port binding control model, a terminal switching model, an RDMA model, an Ethernet protocol model, and an APP application model.
[0056] 2. Switch Simulation Model: This model simulates the core forwarding and control behaviors of a switch, implementing HQoS, fine-grained queue control, and a collaborative congestion detection and triggering mechanism integrating PFC and ECN. The switch simulation model includes a MAC controller, IPE module, TM module, and EPE module.
[0057] Regarding the core simulation mechanism, to achieve high-fidelity simulation, the lossless Ethernet simulation model adopts a collaborative control mechanism of PFC and ECN:
[0058] (1) Timing coordination: In the switch simulation model, an ECN marking threshold (lower) and a PFC trigger threshold (higher) are set for each priority queue. When congestion occurs, ECN marking is triggered first for end-to-end rate adjustment; if the congestion worsens, PFC is triggered for link-level backpressure. This simulates the real coordination strategy of "ECN priority, PFC as the last line of defense".
[0059] (2) Interaction Design: In the terminal simulation model, design the differential response logic of the transmitting end to CNP (ECN feedback) and PFC Pause frames. CNP triggers active slowdown, and PFC triggers forced pause. The two work together to affect the transmitting behavior.
[0060] The following is a detailed explanation of the lossless Ethernet simulation model.
[0061] See Figure 2 As shown, the terminal simulation model includes a port binding control model, a terminal switching model, an RDMA model, an Ethernet protocol model, and an APP application model.
[0062] 1) Port binding control model, which controls Ethernet interfaces.
[0063] 2) Terminal switching model, supporting Layer 2 switching and flow control, with data forwarding and copying operations based on whole packets. The priority queue management module prioritizes and schedules data packets; queue priorities are configurable, and each round of arbitration is composed of a combination of custom priorities and polling priorities. Flow control supports PAUSE flow control and PFC flow control, and also supports congestion management for data streams generated by multiple applications.
[0064] 3) RDMA model, which implements RDMA RoCEv2 protocol transmission and reception and ECN congestion notification functions, and supports unicast and multicast.
[0065] 4) Ethernet protocol model, implementing standard TCP / IP, UDP protocols and ECN congestion notification functions, supporting unicast, multicast and broadcast.
[0066] 5) The APP application model generates RDMA and Ethernet messages based on the configuration file content; and defines the priority of each message, such as three priorities for Ethernet messages: prio0, prio1, and prio3, and a priority of prio2 for RDMA messages. It supports parallel data generation by multiple applications.
[0067] During data transmission, the terminal simulation model shows:
[0068] 1. The APP application model generates RDMA messages and Ethernet messages based on the configuration file content;
[0069] 2. The RDMA model encapsulates RDMA messages into RDMA data frames and implements ECN functionality; the Ethernet protocol model encapsulates Ethernet messages into Ethernet data frames and implements ECN functionality.
[0070] 3. The terminal switching model performs PAUSE flow control and PFC flow control on RDMA data frames and Ethernet data frames, and sends them to the port binding control model for transmission.
[0071] The reception of data frames is the reverse process of transmission.
[0072] a) APP application model
[0073] The APP application model obtains the terminal ID number of this terminal node, and uses this terminal ID to look up the message ID number, message length and period, sending application, and receiving terminal configuration information. It generates the sending time according to a Poisson distribution, and combines this with the message type specified in the configuration file to generate RDMA messages and Ethernet messages, defining priorities. The message ID number, sending time, and receiving terminal information are stored in the message. The maximum message length supported by the APP application model is 2096 bytes.
[0074] b) RDMA model
[0075] The RDMA model includes an RDMA module and a BTH module. The RDMA module establishes a QP connection to control the data transmission process; the BTH module uses the IP protocol to encapsulate RDMA data frames, performs data parsing / encapsulation operations, and performs ECN congestion management.
[0076] c) Ethernet protocol model
[0077] The Ethernet protocol module includes a UDP module, a TCP module, an IP_encap module, an IP module, an ARP module, a MAC module, and an ECN module. The UDP module implements the User Datagram Protocol (UDP) for connectionless data transmission; the TCP module implements the Transmission Control Protocol (TCP) for connection-oriented data transmission; the IP_encap module is the interface layer between the transport layer and the IP module, performing IP packet encapsulation and decapsulation operations; the IP module implements routing and forwarding functions, as well as data packet fragmentation and reassembly operations; the ARP module maps IP addresses to physical MAC addresses, with the address translation table automatically generated by the ARP protocol or read from static configuration; the MAC module provides send / receive interfaces for links with different transmission rates, receiving upper-layer protocol packets, encapsulating them into Ethernet frames for transmission to the physical link, and receiving physical link data packets, decapsulating them, and forwarding them to the upper layer; the ECN module parses the parameter identifiers in the TCP header and limits the transmission rate of the corresponding data stream.
[0078] d) Terminal switching model
[0079] The terminal switching model in the terminal emulation model supports forwarding, flow control, and copying of application data frames. It supports destination MAC address-based forwarding, receiving data frames from upper-layer applications and forwarding them to the corresponding ports based on the destination MAC address.
[0080] The application model internally supports four priorities, prio0 to prio3, with prio0 having the highest priority and prio3 the lowest. High-priority data streams can interrupt low-priority data streams. That is, when the application sends data packets, it prioritizes sending high-priority data packets, and sends low-priority data packets only when high-priority data packets are empty.
[0081] The terminal switching model of the terminal simulation model implements LFC (Link Flow Control) and PFC (Priority-Based Flow Control).
[0082] LFC is a port-based flow control technology. An example of PAUSE frame generation is shown below. Figure 3 As shown in Figure 4. PFC is a priority-based flow control technology, and its PAUSE frames are generated for backlog situations of different priorities.
[0083] When the terminal simulation model acts as the receiver of PAUSE frames (i.e., the Egress port on the left side of the diagram), after receiving the uplink data frame, the terminal switching model filters out LFC PAUSE frames when parsing the Ethernet frame header parameters before placing them into the PORT_FIFO_RX receive queue. The filtering rule is based on the MAC frame destination address being "0x180c2000001", the type being "0x8808", and the opcode being "0x0001", determining that the data frame is an LFC PAUSE frame. Then, the pause duration field in the PAUSE frame is parsed, and port packet transmission is stopped according to the pause duration.
[0084] The terminal simulation model acts as the sender of the PAUSE frame (i.e., the Ingress port on the right side of the diagram). After the terminal switching model receives the data frame, it determines that the PORT_FIFO_RX receive queue count has reached the set threshold. Then, it generates a PAUSE frame, fills in the pause duration, and sends it to the port receiving the current Ethernet frame.
[0085] e) Port Binding Control Model
[0086] The port bonding control model controls two standard Ethernet interfaces and supports multiple bonding modes:
[0087] 1) Bond 0 (balance-rr) mode, a balanced round-robin strategy. Data packets are transmitted sequentially (i.e., the first packet goes through eth0, the next packet goes through eth1, and so on until all packets are transmitted). This mode provides load balancing and fault tolerance.
[0088] 2) Bond 1 (active-backup) mode, primary-backup strategy. Only one device is active at any given time. If one fails, the other immediately becomes the primary device from the backup. The MAC address is externally visible, and from the outside, the bond's MAC address is unique to avoid switch confusion. This mode only provides fault tolerance.
[0089] 3) Bond 2 (balance-xor) mode, load balancing strategy. This mode uses XOR hash load balancing and works in conjunction with the switch's forced non-negotiable aggregation method. Data packets are transmitted based on the specified transmission hash strategy. The default strategy is: (source MAC address XOR destination MAC address) % number of slaves. This mode provides load balancing and fault tolerance.
[0090] 4) Bond 3 (broadcast) mode: This mode sends packets from all network interfaces, resulting in unbalanced load and redundancy. It requires coordination with the switch's aggregation-forced non-negotiation mode. This mode provides fault tolerance.
[0091] Switch simulation model such as Figure 5 As shown, the modules related to the processing include the MAC controller, IPE, TM, EPE, etc.
[0092] 1) The MAC controller receives packets from the port and forwards them to the IPE module.
[0093] 2) The IPE (Ingress Process Engine) module parses the received packets, obtains port and VLAN related attributes, performs lookup operations (L2 / L3) and retrieves relevant information based on the lookup results. If routing is required, it performs L3 protocol packet processing, then performs Layer 2 forwarding operations based on the MAC destination address, applies control policies to the packets according to the ACL configuration, and performs traffic control management.
[0094] 3) The TM (Traffic Management) module performs operations such as enqueuing, reshaping, and scheduling of packets. Queue scheduling includes HQoS multi-level scheduling, and packet copying is performed for broadcast / multicast situations.
[0095] 4) The EPE (Egress Process Engine) module inspects the scheduling result messages, completes L3 and L2 layer editing, performs ACL-related processing on the Egress direction, and finally sends the edited messages to the MAC controller or loopback port for transmission.
[0096] Collaboration mechanism
[0097] In the terminal simulation model and the switch simulation model, priority-based flow control (PFC) and congestion notification (ECN) were designed.
[0098] a. PFC Function Implementation
[0099] PFC flow control mechanisms were designed in both the terminal simulation model and the switch simulation model. For terminal transmission and reception, parameter configuration via upper threshold XOFF and lower threshold XON was implemented to dynamically set the priority gating thresholds for each terminal's transmission and reception.
[0100] The PFC frame processing flow for terminal transmission and reception was designed separately, see [link to relevant documentation]. Figure 6 , Figure 7 ;
[0101] The backpressure enable vector priority_enable_vector and the backpressure timer time[priority] parameter were designed. By loading these two parameters into the data frame, the gating switch of the priority queue and the pause data frame transmission time parameter are implemented and transmitted between terminals.
[0102] The payload enqueueing process and PFC frame transmission procedure were designed. The payload enqueueing process enables PFC flow control when the number of data frames received by the terminal exceeds the maximum threshold. PFC flow control transmits multiple priority queues in a blocked state at a fixed frequency.
[0103] 1. The PFC flow control logic of the terminal simulation model during reception is as follows: Figure 6 As shown, the process is as follows:
[0104] (1) This process is the processing of receiving data frames as PAUSE frames of PFC. After the Ethernet frame is received by the port binding control model, it is forwarded to the terminal switching model, and the frame header information is parsed. If the destination address of the MAC frame is "0x180c2000001" and the type is "0x8808", then it is a PAUSE frame of PFC. Continue to parse the payload content, obtain the backpressure enable vector priority_enable_vector and the backpressure timer time[priority] corresponding to each priority queue.
[0105] If the corresponding bit of priority_enable_vector is 1, it indicates that flow control is required, and the time point for sending the next data frame is set according to the value of the time [priority] timer; if the bit of priority_enable_vector is 0, no processing is performed, indicating that the timer is invalid.
[0106] (2) If the frame header is not a PFC PAUSE frame, then it is another data frame and is processed according to the normal forwarding logic, proceeding to the next step.
[0107] (3) This process is payload enqueueing. This process is for when the number of data frames received by the terminal exceeds the flow control threshold, that is, the terminal has received a lot of data frames, causing data backlog, and flow control measures need to be activated. First, the priority of the data frame is parsed, the payload data packet is put into the receiving sub-queue mapped to the priority, the length of the sub-queue is judged, if it is greater than the set flow control threshold XOFF, the bit corresponding to the back pressure enable vector is set to 1, and the value of time[priority] is 0x7FFF, which means that the transmission is paused for 32767 transmission time units (one transmission time unit is the time required for 512 bits to be transmitted on the physical link). Then, the PFC frame sending function is called to put this flow control information into the next PFC PAUSE frame to be sent.
[0108] (4) The PFC frame transmission process describes that the physical transmission of PFC frames is not executed every time the sub-queue blocking state changes, but at a fixed frequency, the blocking state changes of multiple sub-queues within the current time interval are sent out together. First, the backpressure enable vector and backpressure timer of each sub-queue are updated according to the transmitted parameters. Then, it is determined whether the transmission interval has been reached. If the interval has been reached, the current state of the backpressure enable vector and backpressure timer of each sub-queue is encapsulated into a PFC PAUSE frame and handed over to the port binding control model for transmission.
[0109] (5) This process involves reducing the number of data frames sent to it from upstream, resulting in a decrease in the number of data frames received by the receiving terminal, which can disable the flow control measures. The payload is dequeued and forwarded to the upper layer. If the length of the receiving sub-queue is less than the set flow control recovery threshold XON, the bit corresponding to the backpressure enable vector is set to 0, the value of time[priority] is 0, and then the PFC frame sending function is called to put this flow control information into the next PFC PAUSE frame sent.
[0110] 2. The PFC control logic of the terminal simulation model during data transmission, such as... Figure 7 As shown, the processing flow is as follows:
[0111] (1) When the terminal switching model receives the upper layer data packet, it prepares to put it into the sending sub-queue according to the priority information.
[0112] (2) Ethernet frame enqueue processing: First, the priority is parsed and the Ethernet frame is placed into the sending sub-queue mapped to the priority. The length of the sub-queue is judged. If it is greater than the set flow control threshold XOFF, the terminal service rate is reduced.
[0113] (3) Ethernet frame dequeueing process: Select the sending subqueue, check if the corresponding timer allows sending. If yes, start sending Ethernet frames; otherwise, select the next sending subqueue. After completing the Ethernet frame sending, check if the length of all sending subqueues is less than the set flow control recovery threshold XON. If yes, restore the terminal service rate.
[0114] b. ECN Function Implementation
[0115] ECN congestion notification mechanisms were designed in both the terminal model and the switch model.
[0116] 1. ECN Design of Terminal Ethernet Protocol Model
[0117] Add ECN processing logic to the Ethernet protocol model of the terminal simulation model. When the switch model detects network congestion, it sets the ECN flag information in the data frame. After receiving the data frame, the terminal Ethernet protocol model parses the IP protocol header in the IP module and sets the corresponding ICI identifier according to the ECN bit. Upon detecting congestion, it updates the congestion mapping table, and then creates a CNP packet every 1ms based on the congestion mapping table. When the terminal model receives the CNP packet, it limits the transmission rate of the corresponding data stream.
[0118] 2. ECN Design for Terminal RDMA Model
[0119] Once the switch model detects traffic congestion, it marks the problem in the ECN field of the IP header of the data packet. When the terminal model's RDMA model receives the congestion notification, it parses the parameter identifier in the BTH (Base Transport Header, which exists in the IB data segment) and applies rate limiting to the problematic QP (Quantity Point).
[0120] It is understood that those skilled in the art can make equivalent substitutions or modifications to the technical solution and inventive concept of the present invention, and all such substitutions or modifications should fall within the protection scope of the appended claims.
Claims
1. A lossless Ethernet simulation model, comprising a terminal simulation model, characterized in that... The terminal simulation model includes a port binding control model, a terminal switching model, an RDMA model, an Ethernet protocol model, and an APP application model; The port binding control model is used to control Ethernet interfaces and send and receive frames. The terminal switching model is used to support Layer 2 switching of Ethernet and RDMA data frames and to support PFC flow control. The RDMA model is used to implement RDMA message sending and receiving via the RDMA RoCEv2 protocol and ECN congestion notification functionality. The Ethernet protocol model is used to implement TCP / IP, UDP protocols, and ECN congestion notification functions for Ethernet messages; The APP application model is used to generate RDMA messages and Ethernet messages based on the configuration file content, and to define the priority of each message.
2. The lossless Ethernet simulation model according to claim 1, characterized in that... The PFC flow control process during reception in the terminal switching model is as follows: (1) After the terminal switching model receives the Ethernet frame forwarded by the port binding control model, it parses the frame header information. If it is a PAUSE frame of PFC, it continues to parse the payload content and obtains the backpressure enable vector priority_enable_vector and the backpressure timer time[priority] corresponding to each priority queue. If the bit corresponding to priority_enable_vector is 1, it indicates that flow control is required, and the allowed transmission time of the next data frame is set according to the value of the time [priority] timer; if the bit corresponding to priority_enable_vector is 0, no action is taken, indicating that the timer is invalid. (2) If the frame header is not a PFC PAUSE frame, then it is another data frame and is processed according to the normal forwarding logic to proceed to the next step; (3) First, parse the priority of the data frame, put the payload data packet into the receiving sub-queue mapped to the priority, determine the length of the receiving sub-queue, if it is greater than the set flow control threshold XOFF, set the back pressure enable vector of the sub-queue to 1 and the value of time[priority]; then call the PFC frame sending function to put this flow control information into the next PFC PAUSE frame sent. (4) Forward the payload data packets in the receiving sub-queue to the upper layer. If the length of the receiving sub-queue is less than the set flow control recovery threshold XON, set the bit corresponding to the back pressure enable vector to 0, the value of time[priority] to 0, and then call the PFC frame sending function to put this flow control information into the next PFC PAUSE frame sent. (5) First, update the backpressure enable vector and backpressure timer of each sub-queue, and then determine whether the transmission interval has been reached. If the interval has been reached, encapsulate the current backpressure enable vector and backpressure timer status of each sub-queue into a PFC PAUSE frame and hand it over to the port binding control model for transmission.
3. The lossless Ethernet simulation model according to claim 1, characterized in that... The PFC flow control process during transmission in the terminal switching model is as follows: (1) The terminal switching model receives the upper-layer data packet and puts it into the sending sub-queue according to the priority information; (2) Determine the length of the sending sub-queue. If it is greater than the set flow control threshold XOFF, reduce the terminal service rate. (3) Select the sending subqueue and check whether the corresponding timer allows sending. If yes, start sending Ethernet frames; otherwise, select the next sending subqueue. (4) After completing the Ethernet frame transmission, check whether the length of all transmission sub-queues is less than the set flow control recovery threshold XON. If so, restore the terminal service rate.
4. The lossless Ethernet simulation model according to claim 1, characterized in that... The ECN congestion notification function of the Ethernet protocol model is as follows: When the Ethernet protocol model receives a data frame, it parses the IP protocol header. If the ECN bit indicates congestion, it updates the congestion mapping table. Then, it creates and sends CNP packets according to the congestion mapping table at regular intervals. When the Ethernet protocol model receives CNP packets, it limits the sending rate of the corresponding data stream.
5. A lossless Ethernet simulation model according to claim 1 or 4, characterized in that... The Ethernet protocol model includes modules such as UDP, TCP, IP_encap, IP, ARP, MAC, and ECN. The UDP module implements the User Datagram Protocol (UDP) for connectionless data transmission. The TCP module implements the Transmission Control Protocol (TCP) for connection-oriented data transmission. The IP_encap module is the interface layer between the transport layer and the IP module, performing IP packet encapsulation and decapsulation. The IP module implements routing and forwarding functions, as well as data packet fragmentation and reassembly. The ARP module maps IP addresses to physical MAC addresses; the address translation table is automatically generated by the ARP protocol or can be read from static configurations. The MAC module provides send / receive interfaces for links with different transmission rates, receiving upper-layer protocol packets, encapsulating them into Ethernet frames, and sending them to the physical link; it also receives physical link data packets, decapsulates them, and forwards them to the upper layer. The ECN module parses the parameter identifiers in the TCP header and limits the transmission rate of the corresponding data stream.
6. The lossless Ethernet simulation model according to claim 1, characterized in that... The ECN congestion notification function of the RDMA model is as follows: After receiving a congestion notification, the RDMA model parses the parameter identifier in BTH and applies rate limiting to the network data packets of the problem QP.
7. A lossless Ethernet simulation model according to claim 1 or 6, characterized in that... The RDMA model includes an RDMA module and a BTH module. The RDMA module establishes a QP connection to control the data transmission process; the BTH module uses the IP protocol to encapsulate RDMA data frames, performs data parsing / encapsulation operations, and performs ECN congestion management.
8. The lossless Ethernet simulation model according to claim 1, characterized in that... The APP application model obtains the terminal ID number of this terminal node, and uses this terminal ID to find the message ID number sent by the terminal, the length and period of the message, the sending application, and the configuration information of the receiving terminal. It generates the sending time according to the Poisson distribution, and generates RDMA messages and Ethernet messages in combination with the message types specified in the configuration file, and defines the priority. The message ID number, sending time, and receiving terminal information are stored in the message.
9. A lossless Ethernet simulation model according to claim 1, characterized in that... The port bonding control model controls two standard Ethernet interfaces and supports multiple bonding modes: 1) In balanced polling mode, data frames are transmitted sequentially. 2) Master-backup mode: Only one Ethernet interface is active at any given time. If one fails, the other immediately becomes active from backup. 3) Balanced mode, which means XOR Hash load balancing, combined with the switch's forced non-negotiation aggregation method; 4) Broadcast mode: All data frames are sent from all Ethernet interfaces.
10. A lossless Ethernet simulation model according to claim 1, characterized in that... It also includes a switch simulation model, which includes a MAC controller module, an IPE module, a TM module, and an EPE module. The MAC controller is used to receive packets from the port and forward them to the IPE module; The IPE module is used to parse received packets, obtain port and VLAN related attributes, perform lookup operations and obtain relevant information based on the lookup results. If routing is required, it performs L3 protocol packet processing, then performs Layer 2 forwarding operations based on the MAC destination address, applies control policies to packets according to ACL configuration, and performs traffic control management. The TM module is used for enqueuing, recursing, and scheduling packets. Queue scheduling includes HQoS multi-level scheduling and packet duplication for broadcast / multicast scenarios. The EPE module is used to inspect the scheduling result messages, complete L3 and L2 layer editing, perform ACL-related processing in the Egress direction, and finally send the edited messages to the MAC controller or loopback port for transmission.