Congestion information notification method and equipment for service message, and storage medium

Abstract

The invention discloses a notification method and device for congestion information of a service message and a storage medium, and relates to the field of data message transmission. The method comprises the following steps: updating corresponding session index information according to a session identifier in a session message, wherein the session index information comprises sending end information and receiving end information; obtaining service index information according to the session index information; updating corresponding service index information according to the queue length of the service message; and obtaining the type and queue length of the congested service message according to the service index information, and constructing a congestion information notification message comprising the sending duration of the congested service message according to the total length of the congested queue and the queue length of each type of service message. According to the invention, the congestion information notification message can be transmitted in time, the sending end can respond and decelerate in time, the speed can be decelerated in time without excessive speed reduction according to the congestion information notification message, and the response accuracy is high, so that the low time delay and high throughput of the network are ensured.

Description

Technical Field

[0001] The present invention relates to the field of data message transmission, and in particular to a method, device and storage medium for notifying congestion information of service messages. Background Art

[0002] With the rapid growth of Internet online services and cloud computing demand, some Internet service providers have deployed the RoCEv2 (RDMA over Converged Ethernet) communication protocol in commercial Ethernet data centers to meet the needs of high-performance computing. The RoCEv2 communication protocol is based on the UDP (User Datagram Protocol) transmission mechanism and can adapt to existing Ethernet data centers without the need for dedicated equipment.

[0003] In the RoCE network, a lossless Ethernet needs to be built to ensure that there is no packet loss during network transmission. The traditional approach is: after the relay node device finds congestion, it sends a message carrying a congestion marker (ECN) to the receiving server, and the receiving server then sends a CNP (Congestion Notification Packets) message to the sending server to notify the sending server to reduce the rate of sending messages, thereby alleviating congestion.

[0004] The defects of the above method are:

[0005] (1) Slow response: Congestion occurs in the forwarding equipment in the network, and it is the data packet receiver and sender that handle and feedback the congestion. When the network is large, the delay from congestion occurrence to congestion processing and feedback is long, and the sender cannot reduce the speed in time, resulting in worsening congestion.

[0006] (2) Inaccurate response: The network congestion status can only be obtained through the 11 mark in the ECN field of the data message. The congestion notification message generated by the receiving end cannot accurately tell the sending end how much the rate should be reduced to relieve congestion. If the speed reduction is not enough, the congestion cannot be effectively solved. If the speed reduction is excessive, the bandwidth utilization will be reduced. At the same time, during the congestion relief process, the forwarding device will continue to mark the congestion, which can easily cause the network throughput to be too low. Summary of the invention

[0007] In view of the defects existing in the prior art, the technical problem solved by the present invention is: how to notify congestion information on the basis of fast response speed and high response accuracy.

[0008] To achieve the above objectives, in a first aspect, an embodiment of the present application provides a method for notifying congestion information of a service message, the method comprising the following steps:

[0009] Update the corresponding session index information according to the session identifier in the session message, where the session index information includes the sending end information and the receiving end information;

[0010] Obtaining service index information according to session index information;

[0011] Update the corresponding service index information according to the queue length of the service message;

[0012] The congested service message type and queue length are obtained according to the service index information, and a congestion information notification message including the sending time length of the congested service message is constructed according to the total length of the congested queue and the queue length of each type of service message.

[0013] In combination with the first aspect, in one implementation, the session message includes a session request link establishment message and a session request link establishment reply message;

[0014] The session identifier of the session request link establishment message includes: sender IP, receiver IP, sender identifier and sender queue number;

[0015] The session identifier of the session request link establishment reply message includes: a dual-end session tag and a receiving end queue number;

[0016] The two-end session tag includes: sender IP, receiver IP, sender ID and receiver ID.

[0017] In combination with the first aspect, in one implementation, the session message further includes: a session start message, a disconnect request disconnect message, and a disconnect request disconnect reply message;

[0018] The session identifiers of the session opening message, the disconnection request disconnection message and the disconnection request disconnection reply message are all the dual-end session labels.

[0019] In combination with the first aspect, in one implementation, the service index information includes: a sender IP, a receiver IP, a session queue number, and a queue length count;

[0020] The process of updating the corresponding service index information according to the queue length of the service message includes: determining the service index information corresponding to the service message, and updating the queue length count in the service index information according to the service queue length.

[0021] In combination with the first aspect, in one implementation, the service message is a RoCEv2 message, the session index information is a RoCEv2 session flow table, and the RoCEv2 session flow table includes SIP, DIP, a sender identifier Local_id, a receiver identifier Remote_id, a sender queue number Local_QPN, a receiver queue number Remote_QPN, and a reception identifier Flag of a session message type;

[0022] The process of updating the corresponding session index information according to the session identifier in the session message includes:

[0023] Build two session search trees: one with key values ​​of SIP, DIP, and Local_id; the other with key values ​​of SIP, DIP, Local_id, and Remote_id;

[0024] For session request link establishment messages, session request link establishment reply messages, and session start messages: determine the session search tree corresponding to the key and the current message, and update the corresponding session search tree according to the information of the current message;

[0025] For disconnect request disconnect message and disconnect request disconnect reply message: if the current message corresponds to the key value of any session retrieval tree, the information of the current message is updated in the corresponding session retrieval tree;

[0026] The service index information is a RoCEv2 service flow table, which includes SIP, DIP, session queue number and queue length count cnt;

[0027] The process of updating the corresponding service index information according to the queue length of the service message includes:

[0028] Two service search trees are established based on the RoCEv2 session flow table: one with key values ​​of SIP, DIP, and Remote_QPN, and the other with key values ​​of SIP, DIP, and Local_QPN;

[0029] After receiving the service message, if the current service message matches the key value of any service search tree, the cnt in the corresponding service search tree is updated according to the queue length of the current service message;

[0030] If there is no priority search tree corresponding to the forwarding destination port and message priority of the current service message, construct a corresponding priority search tree according to the forwarding destination port and message priority of the current service message, and associate it with the corresponding service search tree;

[0031] The process of obtaining the congested service message type and queue length according to the service index information includes: determining the corresponding retrieval object tree and service retrieval tree according to the forwarding destination port and message priority of the congested service message, determining the service message type according to the SIP, DIP and session queue number in the service retrieval tree, and determining the queue length according to the cnt in the service retrieval tree.

[0032] In combination with the first aspect, in one implementation, the process for determining the occurrence of congestion includes: setting a queue upper threshold k1 and a queue lower threshold k2, and when the queue length is above k1, determining that the sending time of the service message needs to be extended; when the queue length is below k2, determining that the sending time of the service message needs to be shortened;

[0033] The calculation process of the sending duration of the service message includes:

[0034] Calculate the total time required to extend or shorten the sending time:

[0035] Nall=β1x|Qcur-Qth|+β2x|Qcur-Qold|;

[0036] β1 and β2 are constants set according to the actual network conditions;

[0037] Qcur represents the total length of the currently congested queue;

[0038] Qold represents the total length of the queue during the last congestion;

[0039] Qth is k1 or k2. When Qth is k1, Nall means that the sending time needs to be extended. When Qth is k2, Nall means that the sending time needs to be shortened.

[0040] According to Nall, Qcur and the congestion queue length Ncong of each type of service message, the sending time Ncnp of each type of service message is calculated. The calculation formula is:

[0041] Ncnp=Ncong*Nall / Qcur.

[0042] In combination with the first aspect, in one implementation, the method further includes the following steps:

[0043] After detecting that the session is disconnected, the corresponding session index information and service index information are deleted;

[0044] When there are at least two device boards, the session index information and the service index information are synchronized to each device board.

[0045] In a second aspect, an embodiment of the present application provides a business message transmission device, which includes a processor, a memory, and a congestion information notification program for business messages stored on the memory and executable by the processor, wherein when the congestion information notification program for business messages is executed by the processor, the steps of the method provided in the first aspect are implemented.

[0046] In the third aspect, an embodiment of the present application provides a service message transmission system, which includes a sending node, a receiving node, and a plurality of relay nodes arranged between the sending node and the receiving node, and the service message transmission device provided in the second aspect is set on any relay node.

[0047] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a congestion information notification program for service messages is stored, wherein when the congestion information notification program for service messages is executed, the steps of the method provided in the first aspect are implemented.

[0048] Compared with the prior art, the advantages of the present invention are:

[0049] It can be seen from this that the present invention determines the service index information through the session index information, and then determines the sender and receiver of each type of service message. In this way, the relay node can directly transmit the congestion information notification message to the sender, without the need to carry out the process of first forwarding it to the receiver and then transmitting it to the sender in the prior art. Therefore, the congestion information notification message can be transmitted in a timely manner, allowing the sender to respond and reduce the speed in a timely manner.

[0050] At the same time, the service index information of the present invention includes the queue length of each type of message. According to the total length of the congested queue and the queue length of each type of message, the length of time that the service message of the congested type needs to be suspended from sending can be determined, so that the sending end can "precisely" slow down the message according to the congestion information notification. It can slow down in time without excessively slowing down, and the response accuracy is high, thereby ensuring low latency and high throughput of the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0052] Figure 1 A flow chart of a method for notifying congestion information of a service message in an embodiment of the present invention;

[0053] Figure 2Schematic diagram of the RoCEv2 format in an embodiment of the present invention;

[0054] Figure 3 This is a schematic diagram of feature extraction for session chaining in an embodiment of the present invention;

[0055] Figure 4 A schematic diagram of data transmission of a rack-mounted device in an embodiment of the present invention;

[0056] Figure 5 A schematic diagram of flow table synchronization between slots of a rack-mounted network device in an embodiment of the present invention;

[0057] Figure 6 Schematic diagram of the upper and lower thresholds of a queue in an embodiment of the present invention;

[0058] Figure 7 This is a schematic diagram of the hardware structure of a congestion information notification device for service messages involved in an embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0060] The flowcharts shown in the accompanying drawings are only examples and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may also be decomposed, combined or partially merged, so the actual execution order may change according to actual conditions.

[0061] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0062] In a first aspect, the present application provides a method for notifying congestion information of a service message, see Figure 1 As shown, the steps of the method include:

[0063] S1: After receiving a session message, update the corresponding session index information according to the session identifier in the session message, where the session index information includes the sender information and the receiver information;

[0064] S2: Obtain service index information according to session index information, and after receiving a service message, update the corresponding service index information according to the queue length of the service message;

[0065] S3: When congestion is detected, the congested service message type and queue length are obtained according to the service index information; according to the total length of the congested queue and the queue length of each type of service message, a congestion information notification message including the sending time of the congested service message is constructed and transmitted to the sending end.

[0066] It can be seen from this that the present invention determines the service index information through the session index information, and then determines the sender and receiver of each type of service message. In this way, the relay node can directly transmit the congestion information notification message to the sender, without the need to carry out the process of first forwarding it to the receiver and then transmitting it to the sender in the prior art. Therefore, the congestion information notification message can be transmitted in a timely manner, allowing the sender to reduce the speed in time.

[0067] At the same time, the service index information of the present invention includes the queue length of each type of message. According to the total length of the congested queue and the queue length of each type of message, the length of time that the service message of the congested type needs to be suspended from sending can be determined, so that the sending end can "precisely" slow down the message according to the congestion information notification, which can not only slow down in time but also avoid excessive speed reduction, thereby ensuring low latency and high throughput of the network.

[0068] In one embodiment, the service message in the above method is a RoCEv2 message. For details, see Figure 2 As shown in the figure, RoCEv2 message is a UDP message, which uses the special UDP destination port number 4791. RoCEv2 message contains UDP encapsulation and Infiniband original message (hereinafter referred to as Infiniband message). The types of RoCEv2 message include:

[0069] CM message, also known as session message: a message related to establishing and disconnecting a RoCEv2 session.

[0070] CNP message: congestion notification message.

[0071] RoCEv2 service messages: CM messages and other RoCEv2 messages except CNP.

[0072] Infiniband message contains Infiniband header and Infiniband payload, etc. Infiniband header will contain Infiniband base Transport Header (hereinafter referred to as IB_BASE header). In addition, Infiniband header may also contain some extension headers such as MAD Header, CM ConnectRequest Header, CM ConnectReplay Header, CMReadyToUse Header, CM DisconnectRequest Header, CM DisconnectReplay Header, etc. The description of the above extension headers can be found in the Infiniband manufacturer standard "IB Specification Vol 1-Release-1.4".

[0073] The Opcode field in the IB_BASE header indicates the RoCEv2 message type, which occupies 1 byte. The Opcode field related to this embodiment is 0x80, which represents the CNP message type.

[0074] The IB_BASE header contains Dest QP, which indicates the destination Qpair id of the RoCEv2 message. In this embodiment, this field needs to be set when constructing the CNP message.

[0075] The attribute_id field in the above MAD Header can be used to identify the CM message type, as shown in Table 1. The five messages in the table are collectively referred to as CM messages, of which the first three are also called CM link establishment messages, and the last two are also called CM link disconnection messages; the UDP port numbers of the five messages are all 4791, and the header attribute IDs are 0x10, 0x13 to 0x16 respectively.

[0076] Table 1. CM message types

[0077] attribute_id value Message Type Message Type Abbreviation meaning 0x10 CM ConnectRequest CM_REQ Session request link establishment message 0x13 CM ConnectReplay CM_RPY Session request link establishment reply message 0x14 CM ReadyToUse CM_READY Session Opening Message 0x15 CM DisconnectRequest CM_DISREQ Disconnect request message 0x16 CM DisconnectReplay CM_DISRPY Disconnect Request Disconnect Response Message

[0078] At the same time, the RoCEv2 session process consists of three stages:

[0079] 1. Establish a session through CM link establishment message. The process of this stage includes:

[0080] (1) The sender sends a CM_REQ message through the relay node to the receiver; the CMConnectRequest Header in the CM_REQ message contains a Local_Communication_ID field (hereinafter referred to as REQ_LOCAL_ID).

[0081] (2) After receiving the CM_REQ message, the receiver replies with a CM_RPY message that passes through the relay node to the sender;

[0082] The CM ConnectReplay Header in the CM_RPY message contains the Local_Communication_ID field (hereinafter referred to as RPY_LOCAL_ID) and the Remote_Communication_ID field (hereinafter referred to as RPY_REMOTE_ID);

[0083] The CM ConnectReplay Header in the CM_RPY message includes a REMOTE_QPN field (hereinafter referred to as RPY_REMOTE_QPN).

[0084] The CM ConnectRequest Header in the CM_REQ message includes a Local_QPN field (hereinafter referred to as REQ_LOCAL_QPN).

[0085] (3) After receiving the CM_RPY message, the sender returns a CM_READY message which passes through the relay node to reach the receiver. The CM ReadyToUse Header in the CM_READY message contains a Local_Communication_ID field (hereinafter referred to as READY_LOCAL_ID) and a Remote_Communication_ID field (hereinafter referred to as READY_REMOTE_ID).

[0086] 2. After the session is established, the communicating parties can send RoCEv2 service messages to each other; the IB_BASE header in the RoCEv2 service flow message contains the Destination Queue Pair field (hereinafter referred to as DST_QPAIR, session queue ID).

[0087] 3. After the session is completed, the session is terminated through the CM teardown message or flow table aging. The process of this stage includes:

[0088] (1) The sender sends a CM_DISREQ message through the relay node to the receiver; the CMConnectRequest Header in the CM_DISREQ message contains a Local_Communication_ID field (hereinafter referred to as DREQ_LOCAL_ID) and a Remote_Communication_ID field (hereinafter referred to as DREQ_REMOTE_ID).

[0089] (2) After receiving the CM_DISREQ message, the receiving end replies with a CM_DISRPY message which passes through the relay node to reach the sending end; the CM ConnectReplay Header in the CM_DISRPY message contains a Local_Communication_ID field (hereinafter referred to as RPY_LOCAL_ID) and a Remote_Communication_ID field (hereinafter referred to as RPY_REMOTE_ID).

[0090] It can be seen that if it is necessary to enable the congestion notification message to be transmitted directly to the sender, it is necessary to extract the identifiers and queue numbers (QPN) of both ends (sender and receiver) in the session message; for this purpose, the session message in the above method only includes the session request link establishment message and the session request link establishment reply message.

[0091] The session identifier of the session request link establishment message includes: sender IP (SIP), receiver IP (DIP), sender identifier (Local_id) and sender queue number (Local_QPN);

[0092] The session identifier of the session request link establishment reply message includes: a dual-end session tag and a receiving end queue number (Remote_QPN);

[0093] The two-end session tag includes: the sender IP (SIP), the receiver IP (DIP), the sender identifier (Local_id) and the receiver identifier (Remote_id).

[0094] In one embodiment, considering the situation that the message may be lost due to packet loss or other abnormal reasons, all the messages in Table 1 need to be used as session messages, that is:

[0095] The session message includes:

[0096] Session link establishment messages: specifically, session link establishment request messages, session link establishment request reply messages, and session start messages;

[0097] Session disconnect message: specifically, disconnect request disconnect message and disconnect request disconnect reply message.

[0098] For the session identifier: except for the session request link establishment message, the session identifiers of the other session messages are all the above-mentioned two-end session tags.

[0099] The session index information (i.e., RoCEv2 session flow table) formed in the above manner is shown in Table 2. The Flag in Table 2 is the receiving identifier of the session message type. The Flag is used to determine the session progress and subsequent flow table deletion operations (releasing resources or aging flow tables).

[0100] Table 2: RoCEv2 session flow table

[0101]

[0102] On this basis, in one embodiment, the process of updating the corresponding session index information according to the session identifier in the session message in the above method includes:

[0103] When the CM message reaches the processor, the RoCEv2 session flow table needs to be retrieved. The flow table entries are stored in the memory as described in Table 2. At the same time, two AVL trees (session retrieval trees) are constructed for retrieval:

[0104] 1. The corresponding AVL tree key value is the triple {SIP, DIP, Local_id} in the above flow table field. This tree is hereinafter referred to as AVL_CM_REQ.

[0105] Second, the corresponding AVL tree key value is the {SIP, DIP, Local_id, Remote_id} hereinafter referred to as the quadruple in the above flow table field. This tree is hereinafter referred to as AVL_CM_RPY.

[0106] When establishing the AVL tree, the key is compared from high to low bytes and inserted into the AVL tree. The value in the AVL tree is the memory address of the above-mentioned flow table entry stored, hereinafter referred to as a pointer. For the convenience of searching, the ipv4 entry and the ipv6 entry can be stored separately. Since the only difference between ipv4 and ipv6 in this patent is the length of the ip address, the implementation is universal, so the difference between ipv4 and ipv6 will not be described separately below.

[0107] Specific:

[0108] For session chaining, see Figure 3 As shown:

[0109] The process of receiving a CM_REQ message includes:

[0110] 1. Use the SIP, DIP in the message IPv4 header and the REQ_LOCAL_ID of the message to form the triple key {SIP, DIP, REQ_LOCAL_ID} of the RoCEv2 flow table to search for AVL_CM_REQ. If a hit is found, extract the message information according to the flow table field description and update the flow table entry. If a hit is not found, extract the message information according to the flow table field description to create a new flow table entry and insert the flow table entry pointer into the AVL_CM_REQ tree.

[0111] 2. According to the flow table field description, the Flag field Bit0 of the flow table entry needs to be set.

[0112] The process of receiving a CM_RPY message includes:

[0113] 1. Use the SIP, DIP in the message IPv4 header and the RPY_LOCAL_ID and RPY_REMOTE_ID of the message to form the search key of the RoCEv2 flow table.

[0114] 2. Compose the triple key {DIP, SIP, RPY_REMOTE_ID} to search the AVL_CM_REQ tree. If it is a hit, extract the message information according to the flow table field description and update the flow table entry. If it is not a hit, extract the message information according to the flow table field description to create a new flow table entry and insert the entry pointer to the AVL_CM_REQ tree.

[0115] 3. Compose the four-tuple key {DIP, SIP RPY_REMOTE_ID, RPY_LOCAL_ID} to search the AVL_CM_RPY tree. If it is a hit, extract the message information according to the flow table field description and update the flow table entry. If it is not a hit, extract the message information according to the flow table field description to create a new flow table entry and insert the entry pointer to the AVL_CM_RPY tree.

[0116] 4. According to the flow table field description, Bit 1 of the Flag field of the flow table entry needs to be set.

[0117] The process of receiving the CM_READY message includes:

[0118] 1. Use the SIP, DIP in the message IPv4 header and the READY_LOCAL_ID and READY_REMOTE_ID of the message to form the search key of the RoCEv2 flow table.

[0119] 2. Compose the triple key {SIP, DIP, READY_LOCAL_ID} to search the AVL_CM_REQ tree. If it is a hit, extract the message information according to the flow table field description and update the flow table entry. If it is not a hit, extract the message information according to the flow table field description to create a new flow table entry and insert the entry pointer to the AVL_CM_REQ tree.

[0120] 3. Compose the four-tuple key {SIP, DIP, READY_LOCAL_ID, READY_REMOTE_ID} to search the AVL_CM_RPY tree. If it is a hit, extract the message information according to the flow table field description and update the flow table entry. If it is not a hit, extract the message information according to the flow table field description to create a new flow table entry and insert the entry pointer to the AVL_CM_RPY tree.

[0121] 4. According to the flow table field description, Bit 2 of the Flag field of the flow table entry needs to be set.

[0122] In the above process, if Bit0, Bit1, and Bit2 of the Flag field of the flow table entry are all set, it means that the RoCEv2 session flow table is successfully established.

[0123] For session disconnection:

[0124] The process of receiving a CM_DISREQ message includes:

[0125] 1. Use the SIP and DIP in the message IPv4 header and the DREQ_LOCAL_ID and DREQ_REMOTE_ID of the message to form the search key of the RoCEv2 session flow table.

[0126] 2. Compose the four-tuple key {SIP, DIP, DREQ_LOCAL_ID, DREQ_REMOTE_ID} to search the AVL_CM_RPY tree. If a match is found, set the Flag field Bit3 according to the flow table field description. If a match is not found, do not process it.

[0127] 3. If both Bit3 and Bit4 of the Flag field of the flow table entry are set, it means that the session is disconnected. At this time, the AVL tree entry resources and flow table entry resources need to be released.

[0128] The process of receiving a CM_DISRPY message includes:

[0129] 1. Use the SIP and DIP in the message IPv4 header and the DRPY_LOCAL_ID and DRPY_REMOTE_ID of the message to form the search key of the RoCEv2 session flow table.

[0130] 2. Compose the four-tuple key {DIP, SIP, DRPY_LOCAL_ID, DRPY_REMOTE_ID} to search the AVL_CM_RPY tree. If a match is found, set the Flag field Bit4 according to the flow table field description. If a match is not found, do not process it.

[0131] 3. If both Bit3 and Bit4 of the Flag field of the flow table entry are set, it means that the session is disconnected, and the AVL tree entry resources and flow table entry resources are released.

[0132] Furthermore, the service index information obtained according to the session index information in the above method includes: the sender IP, the receiver IP, the session queue number QPN and the queue length count; the process of updating the corresponding service index information according to the queue length of the service message in the above method includes: determining the service index information corresponding to the service message, and updating the queue length count in the service index information according to the service queue length.

[0133] In this way, when subsequent service messages are congested, the sending queue number corresponding to the destination queue number of the service message can be determined through the service index information, and the subsequent message sending time can be calculated through the queue length.

[0134] Specifically, the service message of the RoCEv2 session and the corresponding RoCEv2 service flow table are shown in Table 3.

[0135] Table 3. RoCEv2 service flow table

[0136]

[0137] As shown in Table 2 and Table 3, since only the session queue ID is included in the service message, the queue numbers of the receiving end and the sending end cannot be known. However, the service flow table obtained according to the session flow table can determine the queue numbers of both ends according to the session queue ID.

[0138] At the same time, since the RoCEv2 service will prioritize services and monitor congestion according to priority, for example, if a service with priority 3 is congested, only the service with priority 3 will be managed. Therefore, the process of constructing the RoCEv2 service flow table in this embodiment includes:

[0139] Two AVL trees (service retrieval trees) are established based on the RoCEv2 session flow table:

[0140] First, the corresponding AVL tree key value is the {SIP, DIP, Remote_QPN} in the above RoCEv2 session flow table field. This tree is called AVL_TF_REQ below. The AVL tree value is a pointer to the above service flow table entry.

[0141] Second, the corresponding AVL tree key value is the {SIP, DIP, Local_QPN} in the above RoCEv2 session flow table field. This tree is referred to as AVL_TF_RPY. The AVL tree value is a pointer to the above service flow table entry.

[0142] In this embodiment, the process of updating the RoCEv2 service flow table according to service information includes:

[0143] The chip needs to identify the RoCEv2 service flow and update the RoCEv2 service flow table count. Specifically:

[0144] Step 1: Extract SIP, DIP, DST_QPAIR from the IP header of the service flow to form the key {SIP, DIP, DST_QPAIR} and search the AVL_TF_REQ tree; if there is no match, go to step 2; if there is a match, go to step 3.

[0145] Step 2: Extract SIP, DIP, and DST_QPAIR from the IP header of the service flow to form the key {SIP, DIP, DST_QPAI} and search the AVL_TF_RPY tree; if there is a match, proceed to step 3; if there is no match, it means that the current service is not tracked and will not be processed.

[0146] Step 3. Extract the corresponding message features according to the flow table field description and update the flow table (encap_len is initially 0). According to the session queue ID of the service message, it is necessary to extract the forwarding destination port dst_port and message priority tc of the service flow. Use {dst_port, tc} as the key to build a new retrieval object tree called AVL_LINK_QUEUE. The entries of the tree are linked list header nodes, and the entries in the linked list nodes are pointers to the above-mentioned RoCEv2 service flow table entries. Go to step 4 for processing.

[0147] 4. When the service message enters the queue to which the flow table entry field {dst_port, tc} belongs, the count of the flow table entry is cnt++. When the message is forwarded from the queue to which {dst_port, tc} belongs, cnt--. Note that when cnt decreases to 0, it will not continue to decrease (generally it will not occur).

[0148] See also Figure 1 As shown, according to the above, the above method also includes the following steps:

[0149] S4: After monitoring that the session is disconnected, delete the corresponding session index information (ie, release the RoCEv2 session flow table resources) and service index information (ie, release the RoCEv2 service flow table resources).

[0150] In addition, in some cases, it is necessary to remove the session through natural aging, for example:

[0151] In some special scenarios, for example, if only CM_REQ information is obtained and CM_RPY information is lost due to special reasons, it is necessary to actively remove the corresponding flow table entry. The specific process is: start the task to monitor the RoCEv2 session flow table entries, perform Age_cnt++ on the entries that have not been fully built in each cycle, and delete the flow table entry if Age_cnt increases to the specified threshold.

[0152] In other cases, after the flow table is completely created, the subsequent chain removal only receives one of the messages CM_DISREQ or CM_DISRPY. In this case, the flow table entry is considered incomplete from the moment the message is received, and the aging monitoring task needs to be started.

[0153] When a RoCEv2 session flow table entry is aged and deleted, the associated RoCEv2 service flow table entry still needs to be deleted and the related AVL tree entry resources released.

[0154] In the meantime, see Figure 1 As shown, in one embodiment, the method further includes the following steps: S5: when there are at least two device boards, the session index information and the service index information are synchronized to each device board.

[0155] See also Figure 4 As shown, the application scenario of this embodiment is a rack-mounted device, which is generally composed of multiple device boards. The device boards are inserted into the slots of the rack, and the rack device is presented to the outside as a whole. In the rack device, the flow table RoCEv2 session flow table information is required to be synchronized between the device cards. Specifically, when the slot receives a CM message, if the port where the CM message enters and the destination forwarding port of the CM message are not in the same slot, synchronization is required.

[0156] For example, a server at one end is connected to slot 1 of rack A, and traffic from the server at the other end comes from slot 2 of rack A. At this time, the flow table information between slot 1 and slot 2 is required to be synchronized.

[0157] Examples of interactions between device boards are as follows:

[0158] Assume that slotA receives the CM_REQ message, slotA establishes the session flow table as described above, and assumes that the service destination port of the CM_RPY message is in slotB. SlotA needs to package the above flow table information into a common Ethernet message and send it to slotB.

[0159] See also Figure 5 As shown, if slotA and the target slot are not in the same slot, the message is generally forwarded through the Fabric switch disk, which provides a channel for forwarding traffic between different slots in the rack-mounted device.

[0160] In one embodiment, the process of determining the occurrence of congestion in the above method includes: setting a queue upper threshold k1 and a queue lower threshold k2. When the queue length is above k1, it is determined that congestion has occurred and the sending time of the service message needs to be extended; when the queue length (the queue length can be the number of service messages or the specific byte length) is below k2, it is determined that the congestion has been resolved, and the sending time of the service message needs to be shortened.

[0161] For details, see Figure 6 As shown in the figure, the queue upper threshold is k1, the queue lower threshold is k2, the processor is notified when the queue length increases to above k2, i.e. point A, and the processor is notified when the queue length decreases to below k1, i.e. point B. The information sent to the processor includes the port number port to which the congested queue belongs, the priority tc of the congested queue, and the total length qlen of the congested queue.

[0162] On this basis, the process of obtaining the congested service message type and queue length according to the service index information in the above method includes: retrieving AVL_LINK_QUEUE according to {port, tc}, obtaining the linked list header associated with the target queue, which contains the RoCEv2 service flow table entry information associated with the queue.

[0163] At the same time, the calculation process of the sending time of the service message in the above method includes:

[0164] 1. Calculate the total time Nall needs to be extended or shortened, specifically:

[0165] Nall=β1x|Qcur-Qth|+β2x|Qcur-Qold|;

[0166] Among them, β1x|Qcur-Qth| is a proportional term, which calculates the absolute deviation of the queue length relative to the threshold; β2x|Qcur-Qold| is an integral term, which calculates the change value of the queue; β1 and β2 are empirical coefficients (i.e., constants) that are adjusted according to the actual network conditions;

[0167] Qcur represents the total length of the currently congested queue;

[0168] Qold represents the total length of the queue during the last congestion;

[0169] Qth is k1 or k2. When Qth is k1, Nall indicates that the sending time needs to be extended. When Qth is k2, Nall indicates that the sending time needs to be shortened.

[0170] Step 1 describes the total time required to extend or shorten the transmission of all service messages associated with the congestion queue, and also needs to be specific to a certain type of service message. Therefore, step 2 is required to calculate the time required to extend or shorten the transmission of each service message based on the weight.

[0171] 2. According to Nall, the current Qcur and the current congestion queue length Ncong of each type of service message, calculate the sending time Ncnp of each type of service message. The calculation formula is:

[0172] Ncnp=Ncong*Nall / Qcur.

[0173] It should be noted that S1 to S3 in the above method are steps performed in real time, especially S3. After calculating the sending duration in the above step 2, S3 will monitor in real time and calculate again to accurately control the sending duration, for example:

[0174] The calculation result at 19:42:01 is that type A service packets need to be suspended for 10 seconds, and the calculation result at 19:42:03 is that type A service packets need to be suspended for 5 seconds. At this time, type A service packets have been suspended for 2 seconds and need to be suspended for another 3 seconds. This information will be transmitted to the sender through the constructed congestion information notification message.

[0175] At the same time, corresponding to the above-mentioned RoCEv2 service message, the RoCEv2 service uses the CNP message as the congestion information notification message, which is stipulated as follows: each time a CNP message is received, it is paused for 1 second. Correspondingly, the above-calculated sending duration is the number of CNP messages sent or canceled.

[0176] In particular, when the number of congested packets in the queue of a certain flow is 0, the processing of this flow should be skipped.

[0177] Further, when a CNP message is used as a congestion information notification message, the process of constructing a congestion information notification message including a sending duration of a congested service message in the above method includes:

[0178] The CNP message consists of a UDP encapsulation and an IB_BASE header. Specifically:

[0179] 1. The RoCEv2 service flow table entries have been obtained when calculating the number of CNP packets sent above;

[0180] 2. The encap field of this entry contains the UDP encapsulation and IB_BASE header;

[0181] 3. It is necessary to recalculate the IP checksum of the IP header in the UDP encapsulation;

[0182] 4. The opcode of the IB_BASE header needs to be modified to be equal to 0x81 (referring to the CNP message type).

[0183] In a second aspect, an embodiment of the present application further provides a business message transmission device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0184] Reference Figure 7 , Figure 7 Schematic diagram of the hardware structure of the service message transmission device involved in the embodiment of the present application. In the embodiment of the present application, the service message transmission device may include a processor, a memory, a communication interface and a communication bus.

[0185] The communication bus may be of any type and is used to interconnect the processor, the memory, and the communication interface.

[0186] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces, which are used to interconnect devices within the service message transmission device, and interfaces used to interconnect the service message transmission device with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, optical fiber interfaces, ATM interfaces, etc.; user devices can be display screens (Display), keyboards (Keyboard), etc.

[0187] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0188] The processor may be a general-purpose processor, and the general-purpose processor may call the congestion information notification program for service messages stored in the memory, and execute the congestion information notification method for service messages provided in the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the congestion information notification program for service messages is called may refer to the various embodiments of the congestion information notification method for service messages of the present application, which will not be repeated here.

[0189] Those skilled in the art will understand that Figure 7 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0190] In a third aspect, the present invention provides a business message transmission system, which includes a sending node, a receiving node, and a plurality of relay nodes arranged between the sending node and the receiving node, and any relay node is provided with the business message transmission device mentioned in the second aspect.

[0191] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.

[0192] The computer-readable storage medium of the present application stores a congestion information notification program for service messages, wherein when the congestion information notification program for service messages is executed by a processor, the steps of the congestion information notification method for service messages as described above are implemented.

[0193] Among them, the method implemented when the congestion information notification program for business messages is executed can refer to the various embodiments of the congestion information notification method for business messages in the present application, and will not be repeated here.

[0194] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0195] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0196] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0197] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0198] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0199] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0200] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0201] The above are only specific implementations of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the embodiments of the present invention, and these modifications or replacements should be included in the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention shall be based on the protection scope of the claims.

Claims

1. A method for notifying congestion information of a service message, characterized in that: The method comprises the following steps: Update the corresponding session index information according to the session identifier in the session message, where the session index information includes the sending end information and the receiving end information; Obtaining service index information according to session index information; Update the corresponding service index information according to the queue length of the service message; The congested service message type and queue length are obtained according to the service index information, and a congestion information notification message including the sending time length of the congested service message is constructed according to the total length of the congested queue and the queue length of each type of service message.

2. The method for notifying congestion information of a service message according to claim 1, characterized in that: The session message includes a session request link establishment message and a session request link establishment reply message; The session identifier of the session request link establishment message includes: sender IP, receiver IP, sender identifier and sender queue number; The session identifier of the session request link establishment reply message includes: a dual-end session tag and a receiving end queue number; The two-end session tag includes: sender IP, receiver IP, sender ID and receiver ID.

3. The method for notifying congestion information of a service message according to claim 2, characterized in that: The session message also includes: a session start message, a disconnect request disconnect message and a disconnect request disconnect reply message; The session identifiers of the session opening message, the disconnection request disconnection message and the disconnection request disconnection reply message are all the dual-end session labels.

4. The method for notifying congestion information of a service message according to claim 3, characterized in that: The service index information includes: sender IP, receiver IP, session queue number and queue length count; The process of updating the corresponding service index information according to the queue length of the service message includes: determining the service index information corresponding to the service message, and updating the queue length count in the service index information according to the service queue length.

5. The method for notifying congestion information of a service message according to claim 4, characterized in that: The service message is a RoCEv2 message, and the session index information is a RoCEv2 session flow table, which includes SIP, DIP, a sender identifier Local_id, a receiver identifier Remote_id, a sender queue number Local_QPN, a receiver queue number Remote_QPN, and a reception identifier Flag of the session message type; The process of updating the corresponding session index information according to the session identifier in the session message includes: Build two session search trees: one with key values ​​of SIP, DIP, and Local_id; the other with key values ​​of SIP, DIP, Local_id, and Remote_id; For session request link establishment messages, session request link establishment reply messages, and session start messages: determine the session search tree corresponding to the key and the current message, and update the corresponding session search tree according to the information of the current message; For disconnect request disconnect message and disconnect request disconnect reply message: if the current message corresponds to the key value of any session retrieval tree, the information of the current message is updated in the corresponding session retrieval tree; The service index information is a RoCEv2 service flow table, which includes SIP, DIP, session queue number and queue length count cnt; The process of updating the corresponding service index information according to the queue length of the service message includes: Two service search trees are established based on the RoCEv2 session flow table: one with key values ​​of SIP, DIP, and Remote_QPN, and the other with key values ​​of SIP, DIP, and Local_QPN; After receiving the service message, if the current service message matches the key value of any service search tree, the cnt in the corresponding service search tree is updated according to the queue length of the current service message; If there is no priority search tree corresponding to the forwarding destination port and message priority of the current service message, construct a corresponding priority search tree according to the forwarding destination port and message priority of the current service message, and associate it with the corresponding service search tree; The process of obtaining the congested service message type and queue length according to the service index information includes: determining the corresponding retrieval object tree and service retrieval tree according to the forwarding destination port and message priority of the congested service message, determining the service message type according to the SIP, DIP and session queue number in the service retrieval tree, and determining the queue length according to the cnt in the service retrieval tree.

6. The method for notifying congestion information of a service message according to any one of claims 1 to 5, characterized in that: The congestion determination process includes: setting a queue upper threshold k1 and a queue lower threshold k2, and when the queue length is above k1, determining that the service message sending time needs to be extended; when the queue length is below k2, determining that the service message sending time needs to be shortened; The calculation process of the sending duration of the service message includes: Calculate the total time required to extend or shorten the sending time: Nall=β1x|Qcur-Qth|+β2x|Qcur-Qold|; β1 and β2 are constants set according to the actual network conditions; Qcur represents the total length of the current congested queue; Qold represents the total queue length of the last congestion; Qth is k1 or k2. When Qth is k1, Nall means that the sending time needs to be extended. When Qth is k2, Nall means that the sending time needs to be shortened. According to Nall, Qcur and the congestion queue length Ncong of each type of service message, the sending time Ncnp of each type of service message is calculated. The calculation formula is: Ncnp=Ncong*Nall / Qcur.

7. The method for notifying congestion information of a service message according to any one of claims 1 to 5, characterized in that: The above method further comprises the following steps: After detecting that the session is disconnected, the corresponding session index information and service index information are deleted; When there are at least two device boards, the session index information and the service index information are synchronized to each device board.

8. A service message transmission device, characterized in that: The service message transmission device includes a processor, a memory, and a congestion information notification program for service messages stored in the memory and executable by the processor, wherein when the congestion information notification program for service messages is executed by the processor, the steps of the congestion information notification method for service messages as described in any one of claims 1 to 7 are implemented.

9. A service message transmission system, comprising a sending node, a receiving node, and a plurality of relay nodes arranged between the sending node and the receiving node, characterized in that: The service message transmission device according to claim 8 is provided on any relay node.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a congestion information notification program for service messages, wherein when the congestion information notification program for service messages is executed, the steps of the congestion information notification method for service messages as described in any one of claims 1 to 7 are implemented.

Images