Method and apparatus for data transmission, device, and storage medium

Abstract

According to embodiments of the present disclosure, provided are a method and apparatus for data transmission, a device, and a storage medium. The method comprises: at a first device, on the basis of a universal routing protocol, exchanging capability information related to resource trust capability with a second device, the resource trust capability indicating the capability to transmit data on the basis of reserved network resources; on the basis of the universal routing protocol, acquiring resource trust information of the second device, the resource trust information being related to a target network segment, wherein the resource trust information comprises reachability information of the target network segment and resource authorization information of the second device for the first device with respect to the target network segment; and on the basis of the resource trust information, processing data transmission to the second device. In the embodiments of the present disclosure, by means of the openness of the universal routing protocol, information exchange and resource negotiation can be controlled among a plurality of network devices provided by different device suppliers, thereby expanding the application range of a resource reservation mechanism, and on the whole, reducing the costs of network congestion control.

Description

Method, device, equipment and storage medium for data transmission

[0001] This application claims priority to the Chinese invention patent application entitled “Methods, devices, equipment and storage media for data transmission” and application number 202311799781.0, filed on December 25, 2023. The entire contents of that application are incorporated by reference into this application. Technical Field

[0002] Example embodiments of the present disclosure relate generally to the field of communications, and more particularly to methods, apparatuses, devices, and computer-readable storage media for data transmission. Background Art

[0003] With the rapid development of machine learning models, high-performance computing, and high-speed storage, data center networks are also gradually evolving toward high bandwidth, low latency, and large capacity. To achieve high throughput and efficiency in business operations, network protocol stacks are being gradually optimized. The emergence of technologies such as Remote Direct Memory Access (RDMA) and the Storage Performance Development Kit (SPDK) eliminates the need for multiple replication of the protocol stack kernel during data forwarding, further freeing up resources consumed by the Central Processing Unit (CPU) and kernel during data forwarding. This enables applications that maximize the speed of physical network cards. Driven by this trend, server physical network access has experienced significant speed evolution. While transmitting over high-bandwidth networks, it is expected to achieve lossless transmission with zero packet loss. Summary of the Invention

[0004] In a first aspect of the present disclosure, a method for data transmission is provided. The method comprises: exchanging capability information related to resource trust capability with a second device according to a general routing protocol, the resource trust capability indicating the capability to transmit data based on reserved network resources; obtaining resource trust information related to a target network segment from the second device according to the general routing protocol, the resource trust information including reachability information of the target network segment and resource authorization information of the second device to the first device regarding the target network segment; and processing data transmission to the second device based on the resource trust information.

[0005] In a second aspect of the present disclosure, a device for data transmission is provided. The device includes: a capability information exchange module configured to exchange capability information related to resource trust capability with a second device at a first device according to a universal routing protocol, where the resource trust capability indicates the ability to transmit data based on reserved network resources; a resource trust information acquisition module configured to acquire resource trust information related to a target network segment from the second device according to the universal routing protocol, where the resource trust information includes reachability information of the target network segment and resource authorization information of the second device to the first device regarding the target network segment; and a processing module configured to process data transmission to the second device based on the resource trust information.

[0006] In a third aspect of the present disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform the method of the first aspect.

[0007] In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein a computer program is stored on the computer-readable storage medium, and the computer program can be executed by a processor to implement the method of the first aspect.

[0008] It should be understood that the content described in this summary section is not intended to limit the key features or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0010] FIG1 shows a schematic diagram of an example environment in which embodiments of the present disclosure can be implemented;

[0011] FIG2 is a schematic diagram showing an example signaling flow for data transmission according to some embodiments of the present disclosure;

[0012] FIG3 shows a schematic diagram of an example signaling flow for exchanging resource trust information according to some embodiments of the present disclosure;

[0013] FIG4 shows a schematic diagram of another example signaling flow for exchanging resource trust information according to some embodiments of the present disclosure;

[0014] FIG5 shows a schematic block diagram of an example process of information processing according to some embodiments of the present disclosure;

[0015] FIG6 is a schematic block diagram illustrating an example process of data packet processing according to some embodiments of the present disclosure;

[0016] FIG7 shows a flowchart of a data transmission process according to some embodiments of the present disclosure;

[0017] FIG8 shows a block diagram of an apparatus for data transmission according to some embodiments of the present disclosure; and

[0018] FIG9 illustrates a block diagram of a device capable of implementing various embodiments of the present disclosure. DETAILED DESCRIPTION

[0019] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0020] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the operation requested will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operations of the disclosed technical solution based on the prompt message.

[0021] As an optional but non-limiting implementation, in response to receiving a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0022] It is understandable that the above notification and user authorization process are merely illustrative and do not limit the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0023] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) must comply with the requirements of relevant laws, regulations and relevant provisions.

[0024] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0025] It should be noted that the titles of any section / subsection provided herein are not limiting. Various embodiments are described throughout this document, and any type of embodiment may be included under any section / subsection. Furthermore, the embodiments described in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or in different sections / subsections.

[0026] Herein, unless explicitly stated otherwise, executing a step “in response to A” does not mean executing the step immediately after “A” but may include one or more intermediate steps.

[0027] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may be included below. The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may be included below.

[0028] As briefly mentioned above, the demand for zero-packet-lossless transmission is increasing over high-bandwidth networks. If network forwarding resources are insufficient and packet loss occurs, services often need to employ waiting and retransmission mechanisms to ensure data integrity. This data recovery mechanism prolongs individual data sessions, reducing data transmission efficiency to a certain extent.

[0029] In order to avoid or at least alleviate the above problems, there are two solutions. In one solution, the congestion detection mechanism of the associated device is used to identify the congestion point, and the congestion notification mechanism of the associated device is used to reversely suppress the data transmission rate of the data sender. That is, in this solution, the network congestion level is reduced by reducing the data transmission rate of the sender, so as to achieve lossless transmission with zero packet loss in the network. The other solution is based on the resource reservation mechanism. Before data transmission, forwarding resources on the data path from the data sender to the data receiver are reserved, and the transmission of valid business data is started only after the forwarding resources are guaranteed to be valid.

[0030] While this resource-trusted reservation forwarding mechanism is gaining increasing attention for its data forwarding performance and network scalability, it still has drawbacks in practical application. For example, the Wireless Bandwidth (IB) solution uses a resource trust mechanism to achieve lossless data transmission on a large scale within the IB protocol stack. However, compared to the Ethernet protocol, the IB protocol is proprietary, making it difficult to achieve multi-vendor compatibility with its congestion mechanism. This solution is ultimately limited to a single equipment vendor. Ethernet-based resource trust mechanisms are currently being applied in distributed distributed chassis (DDCs). In DDCs, a proprietary trust transmission mechanism is used to pre-negotiate resources between the sender and receiver. After successful negotiation, data packets are encapsulated and transmitted using a cell-based approach, achieving balanced data transmission across multiple links and zero packet loss during the data transmission process. However, this proprietary trust negotiation mechanism and cell-based forwarding mechanism still have closed-loop characteristics. For example, resource negotiation and data transmission issues can be hindered due to differences in equipment vendors.

[0031] To this end, an embodiment of the present disclosure proposes a solution for data transmission. According to various embodiments of the present disclosure, a first device as a data sender exchanges capability information related to resource trust capability with a second device as a data receiver according to a universal routing protocol. The resource trust capability indicates the ability to transmit data based on reserved network resources. The first device obtains resource trust information related to a target network segment from the second device according to the universal routing protocol. The resource trust information includes reachability information of the target network segment and resource authorization information of the second device to the first device regarding the target network segment. Then, the first device processes the data transmission to the second device based on the resource trust information.

[0032] In an embodiment of the present disclosure, a universal routing protocol is used to transmit resource trust information between the sending end and the receiving end. In this way, it is possible to ensure that resource reservation and communication are completed on the basis of the universal protocol. With the help of the openness of the universal routing protocol, information interaction and resource negotiation can be controlled between multiple network devices provided by different equipment vendors. According to the embodiment of the present disclosure, openness in terms of protocols, equipment, processing methods, etc. can be achieved, so that it can be applied to networks that include network devices provided by different equipment vendors. This expands the scope of application of the resource reservation mechanism and reduces the cost of network congestion control as a whole. In particular, in scenarios such as machine learning technology, high-performance computing, and high-performance storage, low-cost, vendor-open network congestion control based on resource trust can be achieved.

[0033] Hereinafter, exemplary embodiments of the present disclosure are described in detail with reference to the accompanying drawings.

[0034] FIG1 shows a schematic diagram of an example environment 100 in which embodiments of the present disclosure can be implemented. In the environment 100, a network 101 may include multiple network devices, such as a first device 110 and a second device 120, and so on. The first device 110 and the second device 120 can perform data transmission through an established connection. Note that the data transmission described herein refers to the transmission of user plane data. The first device 110 can send data to the second device 120, or the second device 120 can send data to the first device 110. In this document, the sender of data is also referred to as a sending end or a sending device, and the receiver of data is also referred to as a receiving end or a receiving device.

[0035] In the environment 100, the first device 110 and the second device 120 can be any type of network device, such as but not limited to a router, a switch, etc. Alternatively, in some embodiments, the first device 110 and / or the second device 120 can be any type of device with computing capabilities, including a terminal device or a server device. The terminal device can be any type of mobile terminal, fixed terminal or portable terminal, including a mobile phone, a desktop computer, a laptop computer, a notebook computer, a netbook computer, a tablet computer, a media computer, a multimedia tablet, a personal communication system (PCS) device, a personal navigation device, a personal digital assistant (PDA), an audio / video player, a digital camera / camcorder, a positioning device, a television receiver, a radio broadcast receiver, an e-book device, a gaming device or any combination of the foregoing, including accessories and peripherals of these devices or any combination thereof. The server device can, for example, include a computing system / server, such as a mainframe, an edge computing node, an electronic device in a cloud environment, and the like.

[0036] It should be understood that the structure and functionality of environment 100 are described for exemplary purposes only and do not imply any limitation on the scope of the present disclosure.

[0037] Figure 2 illustrates a schematic diagram of an example signaling flow 200 for data transmission according to some embodiments. For ease of description, Figure 2 will be described with reference to Figure 1. As an example, the following description will be from the perspective of first device 110 as the transmitting end and second device 120 as the receiving end. This is for illustrative purposes only and is not intended to be limiting.

[0038] As shown in FIG2 , for subsequent data transmission, the first device 110 establishes (205) a connection with the second device 120. For example, a Transmission Control Protocol (TCP) connection may be established between the first device 110 and the second device 120. After the connection is established, the first device 110 and the second device 120 may be considered as peers of each other.

[0039] The first device 110 exchanges (210) capability information with the second device 120 according to a general routing protocol. The capability information exchanged between the first device 110 and the second device 120 is related to resource trust capability and may also be referred to as resource trust capability information. Resource trust capability refers to the ability to transmit data based on reserved network resources. For example, a receiving end with resource trust capability can authorize a sending end to use at least a portion of its network resources, that is, to reserve such network resources to receive data from the sending end. The sending end with resource trust capability can send data based on the authorization of the receiving end.

[0040] In some embodiments, the first device 110 can exchange capability information with the second device 120 based on the Border Gateway Protocol (BGP). That is, the universal routing protocol can be BGP. For example, after the first device 110 and the second device 120 establish a connection, capability information related to resource trust capabilities can be carried in an open message (OPEN message) via BGP to exchange resource trust capabilities. The first device 110 and the second device 120 can each carry their own capability information in the open message sent to the other end.

[0041] The capability information may include any suitable type of information to indicate the resource trust capability of the information sender. In some embodiments, the capability information may include an indication that the sender of the capability information has resource trust capability. Alternatively or additionally, the capability information may include the output queue capacity of the sender, such as the capacity of a virtual output queue (VoQ). Taking BGP as an example, Table 1 shows example fields for capability information that may be included in an open message.

[0042] Table 1

[0043] In Table 1, the "Capability Code" field is 8 bits long and has a value of 128, indicating that the sender of the BGP message has the resource trust capability. The "Capability Length" field is 8 bits long and represents the length of the "Capability Value" field. The "Capability Value" field is 24 bits long and represents the capacity of the output queue of the message sender, such as VoQ capacity. If first device 110 and second device 120 complete the exchange of capability information, it means that first device 110 and second device 120 have the capability to exchange resource trust.

[0044] Continuing with the signaling flow 200, the first device 110 obtains (215) resource trust information related to the target network segment of the second device 120 according to the universal routing protocol. The resource trust information may include reachability information of the target network segment, such as the network resources of the second device 120 for the target network segment. The resource trust information may also include resource authorization information of the second device 120 to the first device 110 regarding the target network segment. For example, the resource trust information may indicate whether the network resources of the second device 120 for the target network segment are authorized for use by the first device 110 or whether they are available to the first device 110. In other words, the resource trust information may indicate whether the network resources of the second device 120 for the target network segment are in a resource-ready state for the first device 110. Note that the target network segment may include one or more network segments.

[0045] Continuing with signaling flow 200, the first device 110 processes (220) data transmission to the second device 120 based on the obtained resource trust information. For example, the first device 110 can determine a target interface and a target queue in the target interface of the second device 120 based on the reachability information in the resource trust information, where the target interface and the target queue are interfaces and queues for the target network segment. If the resource authorization information indicates that the target interface and the target queue are available to the first device 110, the first device 110 can send the target data to the second device 120. If the resource authorization information indicates that the target interface and the target queue are not available to the first device 110, the first device 110 does not send the target data to the second device 120.

[0046] More example embodiments of resource trust information are described below. In some embodiments, the first device 110 may send a resource trust request for a target network segment to the second device 120. The second device 120 may send a resource trust response, which may also be referred to as a resource trust authorization, to the first device 110 in response to the received request. The first device 110 may then determine the resource trust information by parsing the resource trust response according to a general routing protocol. In other embodiments, the second device 120 may send the resource trust information directly to the first device 110 without a request from the first device 110.

[0047] In some embodiments, if the universal routing protocol is BGP, the first device 110 may obtain the resource trust information through an UPDATE message transmitted between the first device 110 and the second device 120. For example, the resource trust request and the resource trust response may be included in the UPDATE message or implemented as an UPDATE message.

[0048] In this embodiment, in order for the first device 110 and the second device 120 to complete the exchange of resource trust information, identifiers for exchanging resource trust information under corresponding address families can be defined under different address family identifiers (AFIs). As an example, a subsequent address family identifier (SAFI) can be used as such an identifier. For example, a SAFI of 241 can be defined under an Internet Protocol (IP) version 4 (IPv4) AFI, an Internet Protocol version 6 (IPv6) AFI, a virtual private network (VPN) version 4 (VPNv4) AFI, a VPN version 6 (VPNv6) AFI, and a layer 2 VPN (L2VPN) AFI, respectively, to indicate that resource trust information is exchanged under the corresponding address family. Table 2 shows example fields in a message (e.g., a BGP update message) used to carry resource trust information.

[0049] Table 2

[0050] In Table 2, if the value of the "Subsequent Address Family Identifier" field is a predetermined value (eg, 241), it means that this message is used for exchanging resource trust information. In one example, the "NLRI" field can be used to carry a resource trust request or a resource trust response.

[0051] To this end, in some embodiments, the example fields in Table 3 may be used for the "NLRI" field or unit.

[0052] Table 3

[0053] In Table 3 above, the "Message Type" field indicates the resource trust information interaction type. These types may include, but are not limited to, partial resource trust request, full resource trust request, partial resource trust response, and full resource trust response. The "Length" field indicates the length of the "Message Type Specific" field, which carries the content of the resource trust request or resource trust response. The "Message Type Specific" field may be defined differently based on the AFI-SAFI context information, as described below.

[0054] In some embodiments, the reachability information may indicate one or more interfaces of the second device 120 for the target network segment, for example, one or more outgoing interfaces. Alternatively or additionally, the reachability information may indicate a corresponding quality of service (QoS) level of the one or more interfaces, such as a differentiated services code point (DSCP). Alternatively or additionally, the reachability information may indicate a corresponding queue in one or more interfaces, such as which queue in the outgoing interface is used for the target network segment. Accordingly, the resource authorization information may include an indication of whether the interface and the included queue are available for the first device 110. For example, such reachability information may be included in a resource trust response. Accordingly, the resource trust request may include an identification of the target network segment, such as a prefix or subnet mask of the target network segment.

[0055] The following describes an example of a resource trust interaction type. In the case of a partial resource trust request, the sending end (e.g., the first device 110) can obtain resource authorization information based on the reachability routing information of the target network segment. The resource authorization information can be used to transmit routing information and data packet QoS classification information. The routing information in the resource authorization information can be used to obtain the output interface related to the routing information on the receiving end (e.g., the second device 120). The QoS information in the resource authorization information is used to obtain the corresponding queue information and related resource authorization information on the receiving end.

[0056] Taking AFI=1 representing IPv4 unicast as an example, Table 4 shows an example of fields used for a partial resource trust request.

[0057] Table 4 may be viewed as an example implementation of the “NLRI” field or element shown in Table 3.

[0058] Table 4

[0059] In Table 4 above, the value of the "Information Type" field is 1, indicating a partial resource trust request. The "Length" field indicates the length of the IPv4 prefix and the length of the IPv4 Prefix Information field. The "IP Address Prefix Length" field and the "IPv4 Address Prefix" field indicate the specific target network segment requested by first device 110, and the information length of these fields is variable. As can be seen from Table 4, resource trust information for multiple network segments can be requested.

[0060] In the case of a complete resource trust request, the sender (e.g., first device 110) obtains all routing information, QoS classification, interface, queue, and resource authorization information on the receiver (e.g., second device 120). If the value of the "Information Type" field in Table 3 is 2, it indicates a complete resource trust request. This request does not carry IP network segment information, indicating that the first device 110 expects to obtain reachability information for all target network segments of the second device 120 and the corresponding resource authorization information.

[0061] The partial resource trust response corresponds to the partial resource trust request. In the case of the partial resource trust response, the receiving end (eg, the second device 120) returns the corresponding interface, queue, and resource authorization information according to the routing information and QoS classification information requested by the sending end.

[0062] Table 5 shows an example of fields for a partial resource trust response. Table 5 can be considered as an example implementation of the "NLRI" field or element shown in Table 3.

[0063] Table 5

[0064] In the above Table 5, the value of the "Information Type" field is 3, indicating a partial resource trust response. After receiving the partial resource trust request message of the first device 110, the second device 120 completes the partial resource trust response based on the interface status of the target network segment on the second device 120. The partial resource trust response indicates the following information: a reachable IP network segment, such as the "IPv4 address prefix" field; an outgoing interface, such as the "interface index" field; a queue in the outgoing interface, such as the "interface queue index" field; and an outgoing interface and queue trust value (that is, whether the interface indicated by the interface index and the queue indicated by the interface queue index can be used for the first device 110), such as the "interface resource trust authorization" field. As can be seen from Table 5, the second device 120 can have multiple interfaces for the target network segment, and the first device 110 can request resource trust information for multiple target network segments.

[0065] The complete resource trust response corresponds to the complete resource trust request. The receiving end (eg, the second device 120) may return all local routing reachability information, outbound interface information, traffic classification, queue mapping, and resource trust authorization information.

[0066] Table 6 shows an example of fields for a complete resource trust response. Table 6 can be considered as an example implementation of the "NLRI" field or element shown in Table 3.

[0067] Table 6

[0068] In Table 6 above, the value of the "Information Type" field is 4, indicating a complete resource trust response. After receiving the complete resource trust request message from the first device 110, the second device 120 completes the complete resource trust response based on the interface status of the target network segment on the second device 120. The complete resource trust response indicates the following information: reachable IP network segment, such as the "IPv4 address prefix" field; outgoing interface, such as the "interface index" field; queue in the outgoing interface, such as the "interface queue index" field; outgoing interface and queue trust values ​​(that is, whether the interface indicated by the interface index and the queue indicated by the interface queue index are available to the first device 110), such as the "interface resource trust authorization" field. As can be seen from Table 6, the second device 120 can have multiple interfaces for the target network segment, and the first device 110 can request resource trust information for multiple target network segments.

[0069] The above describes example fields in the resource trust request and resource trust response. It should be understood that the above fields are only exemplary, and in some embodiments, the resource trust request and resource trust response may include more or fewer fields.

[0070] In some embodiments, the first device 110 and the second device 120 can exchange resource trust information via a full resource trust request and a full resource trust response. For example, when the first device 110 and the second device 120 establish an initial connection or during device initialization, the full amount of resource trust information can be obtained. In other words, in this embodiment, the target network segment can include all reachable network segments of the second device 120.

[0071] Figure 3 shows a schematic diagram of an example signaling flow 300 for exchanging resource trust information according to some embodiments. As shown in Figure 3, the first device 110 establishes (205) an initial connection with the second device 120 and completes the exchange (210) of capability information by opening information. The first device 110 exchanges (305) routing information with the second device 120 to obtain the reachable network segments of both parties. For example, in the case of BGP, the first device 110 and the second device 120 can exchange routing information through update messages. The first device 110 sends (310) a complete resource trust request to the second device 120 to request resource trust information of all reachable network segments of the second device 120. The second device 120 sends (315) a complete resource trust response to the first device 110 in response to the request sent from the first device 110.

[0072] In some embodiments, the second device 120 may also obtain the complete resource trust information of the first device 110. As shown in FIG3 , the second device 120 may send (320) a complete resource trust request to the first device 110 to request resource trust information for all reachable network segments of the first device 110. The second device 120 may send (325) a complete resource trust response to the first device 110.

[0073] In some embodiments, the first device 110 and the second device 120 may exchange resource trust information via a partial resource trust request and a partial resource trust response. In some embodiments, the target network segment includes an updated network segment where reachability occurs. The resource trust request sent by the first device 110 to the second device 120 includes a partial resource trust request for the updated network segment. The resource trust response received by the first device 110 from the second device 120 includes a partial resource trust response for the updated network segment.

[0074] Figure 4 shows a schematic diagram of an example signaling flow 400 for exchanging resource trust information according to some further embodiments. As shown in Figure 4, if the second device 120 adds a reachable IP network segment 1.1.1.0 / 24, the second device 120 sends (405) updated routing information to the first device 110, in which the reachability information of the IP network segment 1.1.1.0 / 24 is added. In response to this, the first device 110 sends (410) a partial resource trust request to the second device 120 to request resource trust information for the IP network segment 1.1.1.0 / 24. Accordingly, the second device 120 can send (415) a partial resource trust response for the IP network segment 1.1.1.0 / 24 to the first device 110. For example, the first device 110 receives the interface, interface resource trust approval information, etc. for the corresponding 1.1.1.0 / 24 network segment from the second device 120.

[0075] FIG5 is a schematic block diagram of an example process 500 for information processing according to some embodiments of the present disclosure. Based on the exchange of resource trust information described above, information processing at the data sending end (e.g., the first device 110) can be implemented as shown in the example process 500. As shown in FIG5, in block 510, the first device 110 processes routing information. For example, the first device 110 can exchange routing information with the second device 120 according to a general routing protocol to obtain network layer reachability information of the second device 120 as a neighbor, such as prefixes of one or more network segments.

[0076] In block 520, the first device 110 sends a resource trust request for the target network segment. For example, the first device 110 may send a partial resource information request (as shown in FIG. 4 ) or a complete resource trust request (as shown in FIG. 5 ) to the second device 120 at different stages. In block 530, the first device 110 may process the received resource trust response. For example, the first device 110 may receive a resource trust response that matches the issued resource trust request. The first device 110 may then map the reachability information (e.g., outbound interface, queue, etc.) and resource authorization information (e.g., whether the first device 110 is authorized) carried in the resource trust response to the IP-reachable network segment. In some embodiments, if the first device 110 receives resource trust information from multiple peers (i.e., multiple second devices), the first device 110 may deduplicate the received resource trust information based on the device identifiers (e.g., router IDs) of these peers. Thus, the first device 110 may determine aggregated resource trust information. Table 7 shows an example of aggregated resource trust information.

[0077] Table 7

[0078] In the example in Table 7, for the network segment with the address prefix "10.1.1.0 / 24", interface index 1 and queue index 1 of peer ID 1.1.1.1 are available, meaning that resources are ready. Interface index 2 and queue index 1 of peer ID 1.1.1.2 are unavailable, meaning that resources are suppressed.

[0079] Continue with process 500. In box 540, the first device 110 generates a data packet to be sent, such as VoQ data. In box 550, the first device 110 performs a judgment of the data packet sending logic. That is, the first device 110 determines to send data to the peer with available resources, and not to send data to the peer with unavailable resources. For example, the first device 110 can determine whether to send data based on the resource status of the peer. In the example of Table 7, under the reachable route 10.1.1.0 / 24, the first device 110 can send data to the peer with ID 1.1.1.1, but not to the peer with ID 1.1.1.2.

[0080] As briefly mentioned above, some conventional solutions employ a cell-based approach to encapsulate and transmit data packets. This cell-based forwarding mechanism is inherently closed. Therefore, in some embodiments, transmitted data can be encapsulated using a universal network layer protocol. This enables data plane interoperability between multiple network devices in a multi-vendor environment.

[0081] Figure 6 shows a schematic block diagram of an example process 600 for data packet processing according to some embodiments of the present disclosure. Process 600 can be performed after process 500. In box 610, the first device 110 can slice the data packet to form a plurality of slices. For example, after the first device 110 determines the next hop address of the data packet, the data packet can be sliced ​​to ensure the balance of traffic of the data packet on multiple equal-cost links. The size of each slice can be the same. In box 620, the first device 110 can encapsulate the slice with a header that complies with the original protocol. The original protocol can be, for example, a proprietary protocol of the device vendor or a universal protocol.

[0082] At block 630, the first device 110 may encapsulate the slice with a header consistent with a common network layer protocol (e.g., IP). For example, the first device 110 may encapsulate the slice with an IP header. At block 640, the first device 110 may send the encapsulated slice to the selected peer.

[0083] Example Process

[0084] 7 shows a flow chart of a process 700 for data transmission according to some embodiments of the present disclosure. The process 700 may be implemented at the first device 110. The process 700 is described below with reference to FIG1.

[0085] In block 710 , the first device 110 exchanges capability information related to resource trust capability with the second device according to a general routing protocol, where the resource trust capability indicates a capability of transmitting data based on reserved network resources.

[0086] In block 720 , the first device 110 obtains resource trust information related to the target network segment from the second device according to the universal routing protocol. The resource trust information includes reachability information of the target network segment and resource authorization information of the second device to the first device regarding the target network segment.

[0087] At block 730 , the first device 110 processes the data transmission to the second device based on the resource trust information.

[0088] In some embodiments, obtaining resource trust information related to the target network segment of the second device includes: sending a resource trust request for the target network segment to the second device according to a general routing protocol; receiving a resource trust response to the resource trust request from the first device; and determining the resource trust information by parsing the resource trust response according to the general routing protocol.

[0089] In some embodiments, the target network segment includes all reachable network segments of the second device, the resource trust request includes a complete resource trust request for all reachable network segments, and the resource trust request includes a complete resource trust response for all reachable network segments.

[0090] In some embodiments, sending the resource trust request for the target network segment to the second device includes: in response to establishing an initial connection between the second device and the first device, sending a complete resource trust request to the second device.

[0091] In some embodiments, the target network segment includes an updated network segment whose reachability has changed, the resource trust request includes a partial resource trust request for the updated network segment, and the resource trust response includes a partial resource trust response for the updated network segment.

[0092] In some embodiments, sending the resource trust request for the target network segment to the second device includes: receiving routing update information indicating an updated network segment from the second device; and sending a partial resource trust request to the second device in response to the routing update information.

[0093] In some embodiments, the reachability information indicates at least one of: one or more interfaces of the second device for the target network segment, corresponding quality of service (QoS) levels of the one or more interfaces, corresponding queues in the one or more interfaces, and the resource authorization information includes an indication of whether the corresponding queue is available for the first device.

[0094] In some embodiments, the capability information includes at least one of: an indication that the sending device of the capability information has resource trust capability, or an output queue capacity of the sending device of the capability information.

[0095] In some embodiments, processing data transmission to the second device includes: determining a target interface and a target queue in the target interface of the second device based on reachability information; and sending target data to the second device in response to resource authorization information indicating that the target interface and the target queue are available for the first device.

[0096] In some embodiments, sending the target data to the second device includes: encapsulating a slice of the data packet to be sent with a header that conforms to a general network layer protocol; and sending the encapsulated slice to the second device.

[0097] In some embodiments, the general-purpose network layer protocol includes the Internet Protocol.

[0098] In some embodiments, the general routing protocol includes a border gateway protocol, the capability information is exchanged via an open message transmitted between the first device and the second device, and the resource trust information is obtained via an update message transmitted between the first device and the second device.

[0099] Example devices and equipment

[0100] 8 shows a schematic structural block diagram of an apparatus 800 for data transmission according to certain embodiments of the present disclosure. Apparatus 800 may be implemented as or included in the first device 110. Each module / component in apparatus 800 may be implemented by hardware, software, firmware, or any combination thereof.

[0101] As shown in the figure, the apparatus 800 includes a capability information exchange module 810, which is configured to exchange capability information related to resource trust capability with a second device at a first device according to a general routing protocol, where the resource trust capability indicates the capability of transmitting data based on reserved network resources.

[0102] The device 800 also includes a resource trust information acquisition module 820, which is configured to obtain resource trust information related to the target network segment of the second device according to a general routing protocol. The resource trust information includes reachability information of the target network segment and resource authorization information of the second device to the first device regarding the target network segment.

[0103] The apparatus 800 further includes a processing module 830 configured to process data transmission to the second device based on the resource trust information.

[0104] In some embodiments, the resource trust information acquisition module 820 includes: a request sending module, configured to send a resource trust request for a target network segment to a second device according to a general routing protocol; a response receiving module, configured to receive a resource trust response to the resource trust request from a first device; and a response parsing module, configured to determine resource trust information by parsing the resource trust response according to a general routing protocol.

[0105] In some embodiments, the target network segment includes all reachable network segments of the second device, the resource trust request includes a complete resource trust request for all reachable network segments, and the resource trust request includes a complete resource trust response for all reachable network segments.

[0106] In some embodiments, the request sending module is further configured to: in response to establishing an initial connection between the second device and the first device, send a complete resource trust request to the second device.

[0107] In some embodiments, the target network segment includes an updated network segment whose reachability has changed, the resource trust request includes a partial resource trust request for the updated network segment, and the resource trust response includes a partial resource trust response for the updated network segment.

[0108] In some embodiments, the request sending module is further configured to: receive routing update information indicating an updated network segment from the second device; and send a partial resource trust request to the second device in response to the routing update information.

[0109] In some embodiments, the reachability information indicates at least one of: one or more interfaces of the second device for the target network segment, corresponding QoS levels of the one or more interfaces, corresponding queues in the one or more interfaces, and the resource authorization information includes an indication of whether the corresponding queue is available for the first device.

[0110] In some embodiments, the capability information includes at least one of: an indication that the sending device of the capability information has resource trust capability, or an output queue capacity of the sending device of the capability information.

[0111] In some embodiments, the processing module 830 includes: a resource determination module, configured to determine the target interface and the target queue in the target interface of the second device based on reachability information; and a data sending module, configured to send target data to the second device in response to resource authorization information indicating that the target interface and the target queue are available for the first device.

[0112] In some embodiments, the data sending module is further configured to: encapsulate a slice of the data packet to be sent using a header that complies with a general network layer protocol; and send the encapsulated slice to the second device.

[0113] In some embodiments, the general-purpose network layer protocol includes the Internet Protocol.

[0114] In some embodiments, the general routing protocol includes a border gateway protocol, the capability information is exchanged via an open message transmitted between the first device and the second device, and the resource trust information is obtained via an update message transmitted between the first device and the second device.

[0115] FIG9 shows a block diagram of an electronic device 900 in which one or more embodiments of the present disclosure may be implemented. It should be understood that the electronic device 900 shown in FIG9 is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. The electronic device 900 shown in FIG9 can be used to implement the first device 110 of FIG1 .

[0116] As shown in FIG9 , electronic device 900 is a general-purpose electronic device. Components of electronic device 900 may include, but are not limited to, one or more processors or processing units 910, memory 920, storage device 930, one or more communication units 940, one or more input devices 950, and one or more output devices 960. Processing unit 910 may be a real or virtual processor and is capable of performing various processes according to programs stored in memory 920. In a multi-processor system, multiple processing units execute computer-executable instructions in parallel to enhance the parallel processing capabilities of electronic device 900.

[0117] The electronic device 900 typically includes a plurality of computer storage media. Such media can be any accessible media that the electronic device 900 can access, including but not limited to volatile and non-volatile media, removable and non-removable media. The memory 920 can be a volatile memory (e.g., registers, cache, random access memory (RAM)), a non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. The storage device 930 can be a removable or non-removable medium and can include a machine-readable medium, such as a flash drive, a disk, or any other medium that can be used to store information and / or data and can be accessed within the electronic device 900.

[0118] The electronic device 900 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 9 , a disk drive for reading or writing from a removable, non-volatile disk (e.g., a “floppy disk”) and an optical drive for reading or writing from a removable, non-volatile optical disk may be provided. In these cases, each drive may be connected to a bus (not shown) by one or more data media interfaces. The memory 920 may include a computer program product 925 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.

[0119] The communication unit 940 enables communication with other electronic devices via a communication medium. Additionally, the functions of the components of the electronic device 900 can be implemented as a single computing cluster or multiple computing machines that can communicate via a communication connection. Thus, the electronic device 900 can operate in a networked environment using a logical connection with one or more other servers, a network personal computer (PC), or another network node.

[0120] The input device 950 may be one or more input devices, such as a mouse, keyboard, or trackball. The output device 960 may be one or more output devices, such as a display, a speaker, or a printer. The electronic device 900 may also communicate with one or more external devices (not shown) through the communication unit 940 as needed, such as a storage device, a display device, or the like, with one or more devices that allow a user to interact with the electronic device 900, or with any device that allows the electronic device 900 to communicate with one or more other electronic devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface (not shown).

[0121] According to an exemplary implementation of the present disclosure, a computer-readable storage medium is provided, on which computer-executable instructions are stored, wherein the computer-executable instructions are executed by a processor to implement the method described above. According to an exemplary implementation of the present disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the method described above.

[0122] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0123] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, such that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0124] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0125] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple implementations of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part for a module, program segment or instruction, and a part for a module, program segment or instruction comprises one or more executable instructions for realizing the logical function of the specification. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be realized by a special hardware-based system that performs the function or action of the specification, or can be realized by a combination of special hardware and computer instructions.

[0126] While various implementations of the present disclosure have been described above, the foregoing description is intended to be illustrative, not exhaustive, and not limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is selected to best explain the principles of the implementations, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A data transmission method, comprising: exchanging, at a first device, with a second device, capability information related to a resource trust capability according to a general routing protocol, where the resource trust capability indicates the ability to transmit data based on reserved network resources; acquiring, according to the general routing protocol, resource trust information of the second device related to a target network segment, where the resource trust information includes reachability information of the target network segment and resource authorization information of the second device for the first device regarding the target network segment; and processing data transmission to the second device based on the resource trust information.

2. The method according to claim 1, wherein acquiring the resource trust information of the second device related to the target network segment includes: sending, according to the general routing protocol, a resource trust request for the target network segment to the second device; receiving, at the first device, a resource trust response to the resource trust request; and determining the resource trust information by parsing the resource trust response according to the general routing protocol.

3. The method according to claim 2, wherein the target network segment includes all reachable network segments of the second device, the resource trust request includes a complete resource trust request for all the reachable network segments, and the resource trust request includes a complete resource trust response for all the reachable network segments.

4. The method according to claim 3, wherein sending the resource trust request for the target network segment to the second device includes: sending the complete resource trust request to the second device in response to an initial connection being established between the second device and the first device.

5. The method according to claim 2, wherein the target network segment includes an updated network segment with a changed reachability, the resource trust request includes a partial resource trust request for the updated network segment, and the resource trust response includes a partial resource trust response for the updated network segment.

6. The method according to claim 5, wherein sending the resource trust request for the target network segment to the second device includes: receiving, from the second device, routing update information indicating the updated network segment; and sending the partial resource trust request to the second device in response to the routing update information.

7. The method according to claim 1, wherein the reachability information indicates at least one of the following: one or more interfaces of the second device for the target network segment, corresponding quality of service (QoS) levels of the one or more interfaces, corresponding queues in the one or more interfaces, and the resource authorization information includes an indication of whether the corresponding queue is available for the first device.

8. The method according to claim 1, wherein the capability information includes at least one of the following: an indication that the sending device of the capability information has the resource trust capability, or the output queue capacity of the sending device of the capability information.

9. The method according to claim 1, wherein processing data transmission to the second device includes: Based on the reachability information, determine the target interface of the second device and the target queue in the target interface; And In response to the resource authorization information indicating that the target interface and the target queue are available for the first device, send target data to the second device.

10. The method according to claim 9, wherein sending target data to the second device includes: Encapsulate slices of the data packet to be sent with a header conforming to a general-purpose network layer protocol; And Send the encapsulated slices to the second device.

11. The method according to claim 10, wherein the general-purpose network layer protocol includes the Internet Protocol.

12. The method according to claim 1, wherein the general-purpose routing protocol includes the Border Gateway Protocol, The capability information is exchanged through an open message transmitted between the first device and the second device, and the resource trust information is obtained through an update message transmitted between the first device and the second device.

13. A device for data transmission, comprising: A capability information exchange module, configured to exchange, at a first device, capability information related to a resource trust capability with a second device according to a general-purpose routing protocol, the resource trust capability indicating the ability to transmit data based on reserved network resources; A resource trust information acquisition module, configured to obtain, according to the general-purpose routing protocol, resource trust information of the second device related to a target network segment, the resource trust information including reachability information of the target network segment and resource authorization information of the second device for the first device regarding the target network segment; And A processing module, configured to process data transmission to the second device based on the resource trust information.

14. An electronic device, comprising: At least one processing unit; And At least one memory, the at least one memory being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the electronic device to execute the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, having stored thereon a computer program, the computer program being executable by a processor to implement the method according to any one of claims 1 to 12.

Images