Super ethernet-based multi-connection transmission method, computer-readable storage medium, electronic device, and computer program product

Abstract

Embodiments of the present disclosure provide a super Ethernet-based multi-connection transmission method, a computer-readable storage medium, an electronic device, and a computer program product. The method comprises: splitting a service flow into a plurality of packet delivery context (PDC) connections; and transmitting the service flow by means of the plurality of PDC connections.

Description

Multi-connection transmission method based on Super Ethernet, computer-readable storage medium, electronic device and computer program product

[0001] Cross-reference to related applications

[0002] This disclosure is based on and claims priority to Chinese Patent Application No. 2025101214576, filed on January 23, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of communication technology, and more specifically, to a multi-connection transmission method based on Super Ethernet, a computer-readable storage medium, an electronic device, and a computer program product. Background Technology

[0004] In the current Ultra Ethernet Consortium (UEC) protocol specifications and technologies, service flows are primarily transmitted through a single connection. In this single-connection transmission model, network transmission efficiency and reliability can be limited by various factors, leading to problems such as uneven load distribution, low bandwidth utilization, and inaccurate congestion control. Summary of the Invention

[0005] This disclosure provides a multi-connection transmission method, computer-readable storage medium, electronic device, and computer program product based on Super Ethernet, to at least solve the problems of uneven load, low bandwidth utilization, and inaccurate congestion control encountered in single-connection transmission in related technologies.

[0006] According to one embodiment of this disclosure, a multi-connection transmission method based on Super Ethernet is provided, comprising:

[0007] Split the business flow into multiple Packet Delivery Context (PDC) connections;

[0008] The service flow is transmitted through multiple PDC connections.

[0009] According to yet another embodiment of this disclosure, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0010] According to yet another embodiment of this disclosure, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0011] According to yet another embodiment of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments. Attached Figure Description

[0012] Figure 1 is a schematic diagram of the application layer and transport layer in related technologies;

[0013] Figure 2 is a schematic diagram of the hierarchical relationship between business flow, PDC and CCC in related technologies;

[0014] Figure 3 is a flowchart of a multi-connection transmission method based on Super Ethernet according to an embodiment of the present disclosure;

[0015] Figure 4 is a flowchart of a multi-connection transmission mechanism based on the UET transport layer protocol according to an embodiment of the present disclosure;

[0016] Figure 5 is a schematic diagram of service flow splitting in the UET protocol according to an embodiment of the present disclosure;

[0017] Figure 6 is a schematic diagram of multi-connection transmission according to an embodiment of the present disclosure;

[0018] Figure 7 is a second schematic diagram of multi-connection transmission according to an embodiment of the present disclosure;

[0019] Figure 8 is a schematic diagram of multi-connection transmission according to an embodiment of the present disclosure;

[0020] Figure 9 is a schematic diagram of multi-connection transmission according to an embodiment of the present disclosure;

[0021] Figure 10 is a schematic diagram of multi-connection transmission according to an embodiment of the present disclosure;

[0022] Figure 11 is a schematic diagram of the PDS layer processing flow according to an embodiment of the present disclosure;

[0023] Figure 12 is a schematic diagram of a message extension format according to an embodiment of the present disclosure;

[0024] Figure 13 is a second schematic diagram of a message extension format according to an embodiment of the present disclosure;

[0025] Figure 14 is a schematic diagram of the allocation entropy label according to an embodiment of the present disclosure. Detailed Implementation

[0026] The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings and examples.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0028] The current Ultra Ethernet Consortium (UEC) protocol specification and technology lack a definition for a multi-connection mechanism. Because UEC is a connectionless design, the application layer is unaware of and does not maintain connection states. Figure 1 is a schematic diagram of the application layer and transport layer in related technologies. As shown in Figure 1, the UEC transport layer is called UET (UEC Transport), which is divided into two sublayers: SES (Semantic Sublayer) and PDS (Packet Delivery Sublayer). The PDS sublayer is responsible for establishing connections, called PDC (Packet Delivery Context) connections. The application layer only interacts directly with the SES layer and is unaware of connection states; the PDS sublayer also does not provide multi-connection transmission functionality.

[0029] In RoCEv2, each QP connection corresponds to a 5-tuple, described by {source IP address, destination IP address, protocol field, source UDP port, destination UDP port}. Different QP connections are load-balanced using flow-level hashing. However, in the UET protocol design, each PDC connection does not correspond to a unique IP 5-tuple. This is because multiple PDC connections are bound to a CCC (Congestion Control Context), and each CCC internally allocates source UDP ports. Therefore, multiple PDC connections belonging to the same CCC may have the same 5-tuple. Figure 2 is a schematic diagram of the hierarchical relationship between service flow, PDC, and CCC in related technologies. As shown in Figure 2, the current UEC has made many improvements to its overall architecture design compared to RoCEv2; however, it does not provide a multi-connection transmission design. Furthermore, since the UEC application layer adopts a connectionless design, multi-connection transmission methods similar to RoCEv2 cannot be directly ported to the UEC. This disclosure addresses the above problems by proposing an improved multi-connection transmission mechanism based on existing UEC technology.

[0030] This embodiment provides a multi-connection transmission method based on Super Ethernet that operates on the above-described architecture. Figure 3 is a flowchart of the multi-connection transmission method based on Super Ethernet according to an embodiment of this disclosure. As shown in Figure 3, the process includes the following steps:

[0031] Step S302: Split the service flow into multiple message delivery context PDC connections;

[0032] Step S304: Transmit service streams through multiple PDC connections.

[0033] The embodiments disclosed herein can significantly improve the efficiency and reliability of data transmission, especially in scenarios with high bandwidth requirements, such as internal communication in data centers, cloud computing resource scheduling, and large-scale video streaming. They can fully utilize the multi-path and high-bandwidth characteristics of Super Ethernet to achieve efficient data transmission.

[0034] In one embodiment of this disclosure, step S302 may specifically include: extending the application layer's programming interface, wherein the programming interface is used to instruct the use of multi-connection transmission; splitting the service flow into multiple sub-service flows through the application layer and allocating them to multiple PDC connections in the transport layer; or splitting the service flow into multiple sub-service flows based on the application layer's instructions through the transport layer and allocating them to multiple PDC connections. In an optional embodiment, step S302 may further include: splitting the service flow into multiple sub-service flows through the application layer and allocating them to multiple PDC connections in the transport layer; then splitting the service flow into multiple sub-service flows based on the application layer's instructions through the transport layer and allocating them to multiple PDC connections. This implementation allows the application layer to directly control the connection allocation in the transport layer, improving the flexibility of the transmission strategy and making it suitable for scenarios that require dynamic adjustment of the transmission path or the number of connections, such as path switching and load balancing during network congestion.

[0035] In one embodiment, the extended application layer programming interface may specifically include adding a flow-id field to the programming interface. The flow-id field indicates that the transport layer uses multi-connection transmission, wherein sub-service flows with the same flow-id field belong to the same service flow. The flow-id field ensures that sub-flows belonging to the same service flow are correctly identified and processed at the transport layer. This is crucial for services that require data reassembly and sequence control across connections, such as real-time video conferencing and online games.

[0036] In one embodiment of this disclosure, splitting a service flow into multiple sub-service flows at the application layer and allocating them to multiple PDC connections at the transport layer includes: splitting the service flow into multiple sub-service flows at the application layer, and sending PDC connection allocation requests corresponding to multiple sub-service flows to the SES sublayer of the transport layer, wherein one sub-service flow corresponds to one PDC connection allocation request, and each PDC connection allocation request for multiple sub-service flows carries the flow-id of the service flow; when the SES sublayer of the transport layer receives the PDC connection allocation request, it assigns a message identifier msg-id to the PDC connection allocation request; when the PDS sublayer of the transport layer receives the PDC connection allocation request from the SES sublayer, it allocates the multiple sub-service flows to multiple PDC connections according to the msg-id and flow-id carried in the PDC connection allocation request, wherein the flow-id is used to identify the service flow, and the msg-id is used to identify the sub-service flow. This sub-flow allocation mechanism can effectively support multi-connection transmission while ensuring data integrity and order, making it suitable for scenarios requiring high reliability and ordered transmission, such as financial transactions and telemedicine.

[0037] In one embodiment of this disclosure, allocating multiple sub-service flows to multiple PDC connections based on the msg-id and flow-id carried in the PDC connection allocation request includes: if the flow-id already exists, allocating different PDC connections for different msg-ids belonging to the flow-id. This mechanism ensures that even within the same service flow, different data sub-flows can be transmitted through different connections, thereby avoiding single points of failure and improving transmission stability and efficiency.

[0038] In one embodiment of this disclosure, the method further includes: maintaining a mapping relationship between flow-id, msg-id, and PDC-id in the PDS sublayer, wherein the PDC-id is used to identify the PDC connection; and associating sub-PDCs with the PDC connection, wherein the sub-PDCs are used to identify whether the PDC connection is a sub-connection. By maintaining these mapping relationships, fine-grained management of multi-connection transmission can be achieved, facilitating troubleshooting and performance optimization in complex network environments.

[0039] In another embodiment, the extended application layer programming interface may include adding a parameter PDC-num, where PDC-num indicates the number of PDC sub-connections established for the service flow. This addition of a parameter allows the application layer to directly control the number of connections in the transport layer, enhancing the flexibility and controllability of the transmission strategy. It is suitable for scenarios requiring dynamic adjustment of the number of connections based on network conditions, such as live streaming and online education.

[0040] In one embodiment of this disclosure, a service flow is split into multiple sub-service flows based on instructions from the application layer via the transport layer and allocated to multiple PDC connections. This includes: adding a PDC-num to the interface between the SES sublayer and the PDS sublayer; assigning a msg-id to the transmission request when the SES sublayer receives a service flow transmission request; requesting the establishment of an MC-PDC connection through the interface between the SES sublayer and the PDS sublayer; and splitting the service flow into multiple sub-service flows and creating a PDC multi-connection based on the PDC-num when the PDS sublayer receives a multi-PDC connection creation request. Each PDC multi-connection includes multiple PDC sub-connections, with each sub-service flow corresponding to one PDC sub-connection. This multi-connection creation mechanism based on PDC-num enables intelligent splitting and reassembly of service flows, improving data transmission efficiency and reliability. It is suitable for scenarios requiring high throughput and low latency, such as high-definition video-on-demand and large data transmission.

[0041] In one embodiment of this disclosure, creating a PDC multi-connection based on PDC-num includes: maintaining the mapping relationship between msg-id and virtual connection; creating multiple PDC connections based on PDC-num, and maintaining the mapping relationship between the multiple PDC connections and virtual connections. By maintaining these mapping relationships, dynamic adjustment and optimization of multi-connection transmission can be achieved, improving the utilization rate of network resources. This is suitable for scenarios that require real-time adjustment of transmission strategies, such as real-time data processing and dynamic network optimization.

[0042] In one embodiment, the method further includes: carrying an MC-PDC in the extended message, wherein the MC-PDC is used to instruct the target end to establish an MC-PDC connection in reverse. This extended message mechanism enables the target end to automatically establish multiple connections according to the instructions of the source end, simplifying the configuration and management of multiple connection transmission, improving the degree of automation of transmission, and is suitable for large-scale network deployment and automated operation and maintenance scenarios, such as cloud computing and the Internet of Things.

[0043] In another embodiment, if the service type of the transmission request is Original Ordered (ROD) mode, the transport layer provides order preservation for multiple PDC connections; or the packets corresponding to multiple PDC connections carry the parent PSN number of the service flow, where the parent PSN number is used by the transport layer at the destination to reassemble the packets received from multiple connections and transmit them to the application layer. This order preservation mechanism ensures that even in the case of multi-connection transmission, data arrives at the application layer in the correct order, which is crucial for services requiring strict order control, such as online transactions and real-time communication.

[0044] In one embodiment of this disclosure, transmitting service flows through multiple PDC connections includes: assigning different entropy labels to the multiple PDC connections via an extended congestion control context (CCC) interface; and transmitting service flows based on the different entropy labels. This entropy label-based transmission mechanism can effectively avoid network congestion, improve transmission stability and efficiency, and is suitable for scenarios requiring efficient data transmission in complex network environments, such as cross-regional data synchronization and large-scale data distribution.

[0045] The multi-connection transmission method disclosed herein not only fully utilizes the bandwidth resources of Super Ethernet to improve data transmission efficiency and reliability, but also enables flexible allocation and management of service flows by extending the interfaces of the application layer and transport layer, enhancing the system's scalability and adaptability. Furthermore, by carrying additional identification information in the packets, it ensures correct packet reassembly and service ordering, providing strong support for demanding service transmissions. This transmission method is particularly suitable for scenarios requiring high bandwidth, low latency, high reliability, and ordered transmission, such as data center intranet communication, cloud computing resource scheduling, large-scale video streaming, online transactions, and real-time communication, significantly improving data transmission performance and user experience.

[0046] This disclosure proposes a multi-connection transmission mechanism adapted to the architecture design of the UET transport layer protocol. First, by improving the processing flow of the SES and PDS sublayers, a service flow is split into multiple PDC connections. Second, by redefining the interfaces of PDC and CCC, different source User Datagram Protocol (UDP) ports are allocated to different PDC connections, ultimately achieving a multi-connection transmission capability provided to the UEC application layer.

[0047] Figure 4 is a flowchart of a multi-connection transmission mechanism based on the UET transport layer protocol according to an embodiment of the present disclosure. As shown in Figure 4, the first part splits the service flow into multiple sub-connections for transmission, and the second part assigns a separate entropy label to each sub-connection by improving the CCC interface and process.

[0048] First, a service flow needs to be split into multiple PDC connections, meaning that different parts of the service flow use different PDC connections during network transmission. A PDC connection is identified by {Initiator PDC-id, Target PDC-id}. Specifically, as shown in Figure 3, this disclosure proposes two methods for splitting a service flow into multiple PDC connections.

[0049] This disclosure does not limit the use of these two stream splitting methods in combination. For example, the application layer can split the stream first and then instruct the transport layer to continue splitting the stream. Similar extensions are all within the design concept of this disclosure.

[0050] Method 1: Split and reorganize business flows at the application layer;

[0051] Figure 5 is a schematic diagram of service flow splitting in the UET protocol according to an embodiment of this disclosure. As shown in Figure 5, when the application layer splits a service flow into sub-flows and initiates data transmission separately, each sub-flow is assigned a msg-id by the SES and delivered to the PDS sublayer. The PDS sublayer allocates PDC connections to these sub-flows. The PDS protocol stipulates that a PDC connection can be reused by multiple service flows when resources are sufficient. Since these sub-flows have the same source address, destination address, and traffic priority (TC), the PDS is likely to allocate the same PDC connection to these sub-flows. Therefore, the existing solution cannot guarantee splitting to multiple PDC connections.

[0052] To address this issue, this disclosure proposes implementing PDC connection allocation for application-layer sub-flows by improving the application layer interface and PDS process. Firstly, a `flow-id` field is added to the interface; sub-flows carrying the same `flow-id` field belong to the same parent business flow. Typically, the `flow-id` is assigned by the application; the simplest approach is to use the current timestamp as the business flow-id, ensuring uniqueness. There are no restrictions on the allocation method of the `flow-id`.

[0053] Figure 6 is a schematic diagram of multi-connection transmission according to an embodiment of this disclosure. As shown in Figure 6, a flow-id is added to the SES sublayer and PDS interface. When the PDS sublayer receives a PDC connection allocation request from the SES sublayer, it checks the request parameters msg-id and flow-id, where flow-id is used to identify the parent service flow and msg-id is used to identify the child service flow. If flow-id exists, different PDC connections are allocated to different msg-ids belonging to the same flow-id. The mapping relationship maintained by PDS becomes: {flow-id, msg-id} -> PDC-id. A 1-bit identifier sub-PDC needs to be associated on the PDC to identify whether the PDC connection is a child connection.

[0054] Method 2: Split and reassemble service flows at the transport layer.

[0055] In existing UEC schemes, the PDS sublayer can only establish a single PDC connection. This disclosure proposes an alternative approach: natively supporting multiple PDC connections in the PDS sublayer, called MC-PDC (Multi Connection PDC). In this case, the application layer programming interface needs to be extended to allow the application layer to instruct the underlying layer to use multiple connections (the application layer remains unaware of the underlying connection state). Typically, the programming interface only needs to add 1 bit of information; for example, MC-PDC = true indicates that the application layer wants the underlying layer to use multiple connection transmission. Optionally, a parameter PDC-num can be added to indicate how many sub-connections to establish for this service flow.

[0056] Figure 7 is a second schematic diagram of multi-connection transmission according to an embodiment of the present disclosure. As shown in Figure 7, in the interface from the SES sublayer to the PDS sublayer, the MC-PDC parameter and PDC-num are also added to transmit application layer requests. When the PDS sublayer receives a request carrying an MC-PDC indication, it creates a PDC multi-connection. The specific method of establishing PDC multi-connections is not limited in this disclosure. Typically, the PDS sublayer first maintains a virtual connection PDC-id, and then creates multiple PDC sub-connections under this virtual connection as needed. Each PDC connection is identified by a {Initiator PDC-id, Target PDC-id}, and the PDS returns the virtual connection identifier to the SES sublayer.

[0057] At this point, the PDS sublayer needs to maintain two mapping relationships. The first mapping relationship is the existing msg-id->virtual connection PDC-id, and the second mapping relationship is the virtual connection PDC-id->{subPDC-id} set. When the PDS sublayer receives message data from the SES layer, it actively distributes the message packet among multiple subPDCs. The distribution method may be based on a certain block size and distributed in turn, or it may be other methods, which are not limited in this disclosure.

[0058] Similarly, a 1-bit identifier sub-PDC needs to be associated with the PDC to identify whether the PDC connection is a sub-connection.

[0059] Figure 8 is a schematic diagram of multi-connection transmission according to an embodiment of this disclosure. As shown in Figure 8, each PDC connection has its own independent contiguous PSN space. Since different sub-PDC connections may take different paths, out-of-order delivery may occur. If out-of-order reordering is not required, for example, if the application uses RUD (Reliable Unordered Delivery) mode, the message format does not need to be extended. If the application layer requires the original service to be ordered (for example, using ROD (Reliable Ordered Delivery) mode), the message needs to carry the PSN number of the original service flow in addition to the PSN number of the PDC connection itself. The existing PSN number of the PDC connection is used to ensure transmission reliability, while the parent PSN number is used to reassemble the messages received from multiple connections at the receiving transport layer before delivering them to the application layer.

[0060] This disclosure does not limit the specific extension method of the Parent Packet Sequence Number (PSN) in the UEC service message.

[0061] Specifically, in UET, for RDMA (Remote Direct Memory Access) Read operations, a separate reverse connection is established (instead of the bidirectional connection like QP). The Read operation transmits the actual data in the reverse PDC connection. In this case, it is necessary to instruct the reverse transport layer to use multiple connections. At this time, the application layer still only needs to pass 1 bit of information to determine whether to establish an MC-PDC connection in the forward or reverse direction based on the operation type (e.g., Write / Read). For Read operations, the message needs to be extended to carry MC-PDC indication information and optional PDC-num information, so that the other end can follow the MC-PDC process in the reverse direction according to the indication information. Figure 9 is a schematic diagram of multiple connection transmission according to an embodiment of this disclosure. As shown in Figure 9, the actual establishment and interaction process of other connections, such as MP-PDC, is similar to that of the forward connection and will not be described in detail.

[0062] Through these two methods, the transport layer provides multi-connection transmission capabilities to the application layer. The application layer only needs to pass the corresponding request parameters in the programming interface to instruct the transport layer to adopt the appropriate processing flow. That is, if the application layer actively splits the sub-stream, the business flow-id identifier is passed in the request parameters; if the application layer wants the underlying transport layer to split the transmission into multiple connections, the mp-PDC identifier is passed in the request parameters, and optionally the PDC-num parameter is passed.

[0063] A PDC binds to a CCC via an interface request. In existing schemes, multiple PDC connections may bind to the same CCC, and the CCC is responsible for assigning entropy tags, which are carried in the source UDP port field. Therefore, multiple PDC sub-connections may end up with the same IP 5-tuple, thus failing to achieve beneficial effects such as load balancing.

[0064] Figure 10 is a schematic diagram of multi-connection transmission according to an embodiment of the present disclosure. As shown in Figure 10, a 1-bit identifier sub-PDC is added to the interface between the PDC and CCC of the PDS. When the PDC connection is a sub-connection, sub-PDC is set to true in the interface. When the CCC detects that the request parameters carry the sub-PDC identifier, it creates a new CCC and binds it to the PDC-id. In this way, different sub-PDC-ids will be independently assigned a CCC, thereby assigning different entropy tags.

[0065] The PDC and CCC interfaces can also optionally be extended to indicate flow-id (application layer sub-flow) or parent PDC-id (transport layer sub-flow) information to help better allocate CCC-id.

[0066] It should be noted that when assigning entropy labels, CCC randomly selects them from a set, meaning that multiple sub-PDCs may still be assigned the same entropy label. The processing flow for entropy label assignment can be further specified. For example, when assigning entropy labels to PDCs with sub-PDC identifiers, an incremental approach can be used: assigning entropy label 1 to the first sub-PDC, entropy label 2 to the second sub-PDC, and so on. This disclosure does not limit the specific method by which CCC assigns entropy labels.

[0067] This embodiment distributes service flows to multiple PDC connections through application-layer sub-streaming. Assume a service application has the capability to split and reassemble service flows. This application needs to transmit a set of data and wants to send the data through three PDC connections. Existing UEC transport layer protocols cannot meet this requirement.

[0068] Based on the improved mechanism described in this disclosure, only the transport layer programming interface extension needs to support the input of flow-id, and the application layer needs to assign a flow-id=10000 to this service. An example of the programming interface extension is shown below:

[0069] ssize_tfi_write(structfid_ep*ep,constvoid*buf,size_tlen,

[0070] void*desc,fi_addr_tdest_addr,void*context,longflowId=10000);

[0071] The application layer divides the data to be transmitted into three parts, and initiates a transmission request for each part separately through the interface, with each part carrying a flow-id of 10000. When the SES receives the transmission request from the application layer, it assigns a msg-id to each request (1, 2, 3 in a simple example), extracts the parameter flow-id=10000 from the programming interface, and initiates a request to the PDS sublayer. Figure 11 is a schematic diagram of the PDS layer processing flow according to an embodiment of this disclosure. As shown in Figure 11, it includes:

[0072] For the first request, msg-id=1, flow-id=10000, then check if there is a mapping associated with flow-id=10000. If not, assign a PDC-id=1 to msg-id=1, mark sub-PDC=true, and establish the relationship {msg-id=1,flow-id=10000}->PDC-id=1. Return PDC-id=1 for the first SES request.

[0073] For the second request, msg-id=2, flow-id=10000, then check if there is a mapping associated with flow-id=10000. If it is found that PDC-id=1 is already associated with flow-id=10000, then assign a PDC-id=2 to msg-id=2, mark sub-PDC=true, and establish the relationship {msg-id=2,flow-id=10000}->PDC-id=2. Return PDC-id=2 for the second SES request.

[0074] For the third request, msg-id=3, flow-id=10000, then check if there is a mapping associated with flow-id=10000. It is found that PDC-id=1 and 2 are already associated with flow-id=10000. Then, assign a PDC-id=3 to msg-id=3, mark sub-PDC=true, and establish the relationship {msg-id=1,flow-id=10000}->PDC-id=3. Return PDC-id=3 for the second SES request.

[0075] This embodiment provides multi-connection services to the application layer by natively supporting the MC-PDC mode at the transport layer. Extensions are provided in the transport layer programming interface to support the application layer instructing the transport layer to adopt multi-connection mode; the optional number of supported multi-connections is shown below.

[0076] ssize_tfi_write(structfid_ep*ep,constvoid*buf,size_tlen,

[0077] void*desc,fi_addr_tdest_addr,void*context,MC-PDC=true,PDC-num=3);

[0078] When the SES sublayer receives a transmission request, it is assumed that msg-id=1 is assigned to the request.

[0079] SES determines that an MC-PDC connection is being established at the sending end based on the operation type fi_write. Therefore, it requests the establishment of an MC-PDC connection through the interface with PDS, and the number of PDC connections is 3. The standard description of the interface between SES and PDS is informal, and no specific interface example is given in this embodiment. When PDS receives a multi-PDC connection creation request, it creates PDC connections according to the following process:

[0080] PDS maintains a virtual PDC connection according to the existing process, with PDC-id=1;

[0081] PDS maintains the mapping from msg-id=1 to virtual connection PDC-id=1 and returns the virtual connection PDC-id=1 to SES;

[0082] Based on PDC-num=3, PDS continues to create three new PDCs, namely PDC-id=2, PDC-id=3 and PDC-id=4, mark sub-PDC=true, and bind these three new PDCs to virtual PDCs. Specifically, a mapping is maintained: PDC-id=1->{PDC-id=2,PDC-id=3,PDC-id=4}.

[0083] If the SES detects that the operation type is fi_read, the initiating end still requests to establish a normal PDC connection. It instructs the target end to establish an MC-PDC connection in the reverse direction by carrying MC-PDC in the extended message. Figure 12 is a schematic diagram of the message extension format according to an embodiment of this disclosure. As shown in Figure 12, PDC-num information can optionally be carried. In the SES semantic header, one reserved bit carries MC-PDC=true, and 3 reserved bits carry PDC-num information. After receiving the MC-PDC=1 information in the semantic header, the target end knows that it needs to request the PDS to establish an MC-PDC connection in the reverse direction. The connection establishment process will not be described in detail.

[0084] If the application layer initiates a request requiring the service type to be ROD mode, the transport layer also needs to provide order preservation for multiple connections. As described in the invention, in addition to carrying the PSN of the original PDC connection, it needs to carry the parent PSN number, which is not continuous in each child PDC message. Figure 13 is a schematic diagram of the message extension format according to an embodiment of this disclosure, as shown in Figure 13, which is carried in the PDS message header.

[0085] This embodiment extends the interface between PDC and CCC, enabling CCC to perceive the PDC connection type and thus assign different CCCs to sub-PDC connections. Assume a service has been split into three PDC connections using the method described in Embodiment 1, with PDC-ids of 1, 2, and 3, and flow-id = 10000. In the PDS, a variable is maintained indicating the three connection types: sub-PDC = true.

[0086] When a PDC requests the CCC module to assign it a CCC-id, the interface needs to be extended to support the sub-PDC field. Optional support is for the flow-id field, as shown below:

[0087] AllocateCCC(bool:sprayed=false, sub-PDC=true, flow-id=10000);

[0088] For requests carrying sub-PDC=true, the CCC module creates a new CCC and returns the corresponding CCC-id. For example:

[0089] The CCC module receives a binding request for PDC-id=1, carries sub-PDC=true, creates CCC-id=1 and binds it;

[0090] The CCC module receives a binding request for PDC-id=2, carries sub-PDC=true, creates CCC-id=2 and binds it;

[0091] The CCC module receives a binding request for PDC-id=3, carries sub-PDC=true, creates CCC-id=3 and binds it;

[0092] Figure 14 is a schematic diagram of entropy label allocation according to an embodiment of the present disclosure. As shown in Figure 14, the CCC module can assign a random entropy label to each CCC-id, which will not be described in detail here. To strictly guarantee uniqueness, the CCC may also optionally maintain a variable entropy_label_for_subPDC, which is initially set to 0 and incremented in the entropy label space. For each new request labeled as sub-PDC, the assigned entropy label is the current entropy_label_for_subPDC value.

[0093] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this disclosure.

[0094] This embodiment also provides a multi-connection transmission device based on Super Ethernet, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated. The device includes:

[0095] The splitting module is used to split the business flow into multiple message delivery context (PDC) connections;

[0096] A transmission module is used to transmit the service flow through multiple PDC connections.

[0097] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0098] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0099] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0100] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0101] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0102] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0103] It is obvious to those skilled in the art that the modules or steps of this disclosure described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this disclosure is not limited to any particular combination of hardware and software.

[0104] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A multi-connection transmission method based on Super Ethernet, comprising: Split the business flow into multiple message delivery context PDC connections; The service flow is transmitted through multiple PDC connections.

2. The method according to claim 1, wherein, Splitting business flows across multiple PDC connections includes: An extended application layer programming interface, wherein the programming interface is used to indicate the use of multi-connection transport; The service flow is split into multiple sub-service flows by the application layer and allocated to multiple PDC connections of the transport layer; or the service flow is split into multiple sub-service flows by the transport layer based on the instructions of the application layer and allocated to the multiple PDC connections.

3. The method according to claim 2, wherein, The extended application layer programming interface includes: A flow identifier field, flow-id, is added to the programming interface. The flow-id field indicates that the transport layer uses multi-connection transmission. Sub-service flows with the same flow-id field belong to the same service flow.

4. The method according to claim 2, wherein, The multiple PDC connections that split the service flow into multiple sub-service flows through the application layer and allocate them to the transport layer include: In the application layer, the service flow is split into multiple sub-service flows, and PDC connection allocation requests corresponding to the multiple sub-service flows are sent to the SES sublayer of the transport layer respectively. Each sub-service flow corresponds to one PDC connection allocation request, and the PDC connection allocation requests corresponding to the multiple sub-service flows all carry the flow-id of the service flow. When the SES sublayer of the transport layer receives the PDC connection allocation request, it assigns a message identifier msg-id to the PDC connection allocation request; When the PDS sublayer of the transport layer receives the PDC connection allocation request from the SES sublayer, it allocates the multiple sub-service flows to the multiple PDC connections according to the msg-id and flow-id carried in the PDC connection allocation request, wherein the flow-id is used to identify the service flow and the msg-id is used to identify the sub-service flow.

5. The method according to claim 4, wherein, Assigning the multiple sub-service flows to the multiple PDC connections based on the msg-id and flow-id carried in the PDC connection allocation request includes: If the flow-id already exists, assign different PDC connections to different msg-ids belonging to the flow-id.

6. The method according to claim 5, wherein, The method further includes: The PDS sublayer maintains a mapping relationship between flow-id, msg-id, and PDC-id, wherein the PDC-id is used to identify the PDC connection; A sub-PDC is associated on the PDC connection, wherein the sub-PDC is used to identify whether the PDC connection is a sub-connection.

7. The method according to claim 2, wherein, The extended application layer programming interface includes: Add a parameter PDC-num to the programming interface, whereby PDC-num is used to indicate the number of PDC sub-connections established for the service flow.

8. The method according to claim 7, wherein, The process of splitting the service flow into multiple sub-service flows based on the instructions of the application layer through the transport layer and allocating them to the multiple PDC connections includes: Add the PDC-num to the interface from the SES sublayer to the PDS sublayer, and assign a msg-id to the transmission request when the SES sublayer of the transport layer receives the transmission request of the service flow; An MC-PDC connection is established by requesting the interface between the SES sublayer and the PDS sublayer. When the PDS sublayer receives a request to create multiple PDC connections, it splits the service flow into multiple sub-service flows and creates a PDC multi-connection based on the PDC-num. The PDC multi-connection includes multiple PDC sub-connections, and each sub-service flow corresponds to one PDC sub-connection.

9. The method according to claim 8, wherein, Creating a PDC multi-connection based on the PDC-num includes: Maintain the mapping relationship between the msg-id and the virtual connection; Multiple PDC connections are created based on the PDC-num, and the mapping relationship between the multiple PDC connections and the virtual connections is maintained.

10. The method according to claim 8, wherein, The method further includes: The extended message carries an MC-PDC, which is used to instruct the target end to establish an MC-PDC connection in reverse.

11. The method according to claim 8, wherein, The method further includes: if the service type of the transmission request is Original Service Ordered (ROD) mode, providing order preservation for the multiple PDC connections through the transport layer; or The packets corresponding to the multiple PDC connections carry the parent PSN number of the service flow, wherein the parent PSN number is used to reassemble the packets received from the multiple connections at the transport layer at the target end and transmit them to the application layer.

12. The method according to claim 1, wherein, Transmitting the service flow through multiple PDC connections includes: Different entropy labels are assigned to the multiple PDC connections by extending the Congestion Control Context (CCC) interface. The service flow is transmitted based on the different entropy labels.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the steps of the method according to any one of claims 1 to 11.

14. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1 to 11.

Images