CN117793027A - Method, apparatus, device and storage medium for data transmission - Google Patents

Abstract

According to embodiments of the present disclosure, methods, apparatuses, devices, and storage medium for data transmission are provided. The method comprises the following steps: exchanging, at the first device, capability information relating to resource trust capabilities, indicating the capability to transmit data based on reserving network resources, with the second device according to a generic routing protocol; acquiring resource trust information of the second equipment related to the target network segment according to a general routing protocol, wherein the resource trust information comprises reachability information of the target network segment and resource authorization information of the second equipment on the first equipment relative to the target network segment; and processing the data transmission to the second device based on the resource trust information. In the embodiment of the disclosure, by means of the openness of the universal routing protocol, information interaction and resource negotiation can be controlled among a plurality of network devices provided by different device suppliers, so that the application range of a resource reservation mechanism is enlarged, and the cost of network congestion control is reduced as a whole.

Description

Method, apparatus, device and storage medium for data transmission

Technical Field

Example embodiments of the present disclosure relate generally to the field of communications and, more particularly, relate to a method, apparatus, device, and computer-readable storage medium for data transmission.

Background

With rapid development of machine learning models, high-performance computing, high-speed storage and the like, data center networks are gradually developed to a large-bandwidth, low-delay and large-capacity direction. In order to achieve high throughput and high efficiency of the service running process, the network protocol stack is gradually optimized. The technology of remote direct memory access (Remote Direct Memory Access, called RDMA for short), high-performance storage development packet (Storage Performance Development Kit, called SPDK for short) and the like avoids multiple copies of the protocol stack kernel in the data forwarding process, and further releases the resource consumption of a central processing unit (Central Processing Unit, called CPU for short), the kernel and the like in the data forwarding process. This enables the application of physical network card rate maximization. Under this trend, physical network access of the server achieves a large-scale rate evolution. It is desirable to enable lossless delivery of network zero-loss packets while transmitting over large bandwidth networks.

Disclosure of Invention

In a first aspect of the present disclosure, a method for data transmission is provided. The method comprises the following steps: exchanging, at the first device, capability information relating to resource trust capabilities, indicating the capability to transmit data based on reserving network resources, with the second device according to a generic routing protocol; acquiring resource trust information of the second equipment related to the target network segment according to a general routing protocol, wherein the resource trust information comprises reachability information of the target network segment and resource authorization information of the second equipment on the first equipment relative to the target network segment; and processing the data transmission to the second device based on the resource trust information.

In a second aspect of the present disclosure, an apparatus for data transmission is provided. The device comprises: a capability information exchange module configured to exchange, at the first device, capability information relating to resource trust capabilities, indicating the capability to transmit data based on reserved network resources, with the second device according to a generic routing protocol; the resource trust information acquisition module is configured to acquire resource trust information of the second equipment related to the target network segment according to a general routing protocol, wherein the resource trust information comprises reachability information of the target network segment and resource authorization information of the second equipment on the first equipment about the target network segment; and a processing module configured to process data transmission to the second device based on the resource trust information.

In a third aspect of the present disclosure, an electronic device is provided. The apparatus comprises 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. The instructions, when executed by at least one processing unit, cause the apparatus to perform the method of the first aspect.

In a fourth aspect of the present disclosure, a computer-readable storage medium is provided. The computer readable storage medium has stored thereon a computer program executable by a processor to implement the method of the first aspect.

It should be understood that what is described in this section of the disclosure is not intended to limit key features or essential features of the embodiments of the disclosure, nor is it intended to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other features, advantages and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, wherein like or similar reference numerals denote like or similar elements, in which:

FIG. 1 illustrates a schematic diagram of an example environment in which embodiments of the present disclosure may be implemented;

fig. 2 illustrates a schematic diagram of an example signaling flow for data transmission, in accordance with some embodiments of the present disclosure;

fig. 3 illustrates a schematic diagram of an example signaling flow for exchanging resource trust information, according to some embodiments of the present disclosure;

fig. 4 illustrates a schematic diagram of another example signaling flow for exchanging resource trust information in accordance with some embodiments of the present disclosure;

FIG. 5 illustrates a schematic block diagram of an example process of information processing according to some embodiments of the present disclosure;

FIG. 6 illustrates a schematic block diagram of an example process of data packet processing, according to some embodiments of the present disclosure;

fig. 7 illustrates a flow chart of a process of data transmission according to some embodiments of the present disclosure;

fig. 8 illustrates a block diagram of an apparatus for data transmission, according to some embodiments of the present disclosure; and

fig. 9 illustrates a block diagram of an apparatus capable of implementing various embodiments of the present disclosure.

Detailed Description

It will be appreciated that prior to using the technical solutions disclosed in the embodiments of the present disclosure, the user should be informed and authorized of the type, usage range, usage scenario, etc. of the personal information related to the present disclosure in an appropriate manner according to the relevant legal regulations.

For example, in response to receiving an active request from a user, a prompt is sent to the user to explicitly prompt the user that the operation it is requesting to perform will require personal information to be obtained and used with the user. Thus, the user can autonomously select whether to provide personal information to software or hardware such as an electronic device, an application program, a server or a storage medium for executing the operation of the technical scheme of the present disclosure according to the prompt information.

As an alternative but non-limiting implementation, in response to receiving an active request from a user, the manner in which the prompt information is sent to the user may be, for example, a popup, in which the prompt information may be presented in a text manner. In addition, a selection control for the user to select to provide personal information to the electronic device in a 'consent' or 'disagreement' manner can be carried in the popup window.

It will be appreciated that the above-described notification and user authorization process is merely illustrative and not limiting of the implementations of the present disclosure, and that other ways of satisfying relevant legal regulations may be applied to the implementations of the present disclosure.

It will be appreciated that the data (including but not limited to the data itself, the acquisition or use of the data) involved in the present technical solution should comply with the corresponding legal regulations and the requirements of the relevant regulations.

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been illustrated in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather, these embodiments are provided so that this disclosure will be more thorough and complete. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

It should be noted that any section/subsection headings 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 embodiment described in the same section/subsection and/or in a different section/subsection.

In this context, unless explicitly stated otherwise, performing a step "in response to a" does not mean that the step is performed immediately after "a", but may include one or more intermediate steps.

In describing embodiments of the present disclosure, the term "comprising" and its like should be taken to be open-ended, i.e., 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 are also possible below. The terms "first," "second," and the like, may refer to different or the same object. Other explicit and implicit definitions are also possible below.

As mentioned briefly above, there is an increasing demand for lossless delivery of network zero-loss packets when large bandwidth network transmissions are performed. If the network equipment has insufficient forwarding resources and packet loss occurs, the service end often needs to adopt actions such as waiting, retransmission and the like to ensure the integrity of the data. Such a data recovery mechanism may lead to an extension of the time of a single data session, thereby reducing the data transmission efficiency to some extent.

To avoid or at least alleviate the above problems, two solutions exist. In one solution, the congestion point is identified by a congestion detection mechanism of the channel associated device, and the data transmission rate of the data transmission end is reversely suppressed in cooperation with a congestion notification mechanism of the channel associated. That is, in this scheme, the congestion degree of the network is reduced by reducing the data transmission rate of the transmitting end, so as to achieve lossless delivery of zero packet loss of the network. Another solution is based on a resource reservation mechanism. And reserving forwarding resources on a data path from a data sending end to a data receiving end before data transmission, and starting effective service data transmission after ensuring that the forwarding resources are effective.

While such reserved forwarding mechanisms based on resource trust mechanisms are attracting more and more attention in terms of data forwarding performance and networking scale, such schemes still have drawbacks in terms of practical application. For example, wireless bandwidth (IB) schemes enable lossless delivery of data on a large scale over the IB protocol stack using a resource trust mechanism. However, IB protocols are proprietary with respect to ethernet protocols and thus cannot be made compatible with each other by multiple providers of congestion mechanisms. This solution is ultimately limited to a single equipment provider. The resource trust mechanism based on the ethernet protocol is currently applied in the distributed chassis (Distributed Disaggregated Chassis, abbreviated DDC). In DDC, a private trust transfer mechanism is employed to complete resource pre-negotiation between a sender and a receiver. After the negotiation is successful, the encapsulation and the transmission of the data packet are completed in a cell-based mode, so that the balance of data transmission on a plurality of links and zero packet loss in the data transmission process are realized. However, such private trust negotiation mechanisms and cell-based forwarding mechanisms still have a seal. For example, the resource negotiation and the data transfer are impossible due to the difference of the device suppliers.

To this end, embodiments of the present disclosure propose a scheme for data transmission. According to various embodiments of the present disclosure, a first device, which is a data sender, exchanges capability information related to resource trust capabilities, which indicate the capability to transmit data based on reserving network resources, with a second device, which is a data receiver, according to a generic routing protocol. And the first equipment acquires the resource trust information of the second equipment related to the target network segment 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 with respect to the target network segment for the first device. The first device then processes the data transmission to the second device based on the resource trust information.

In embodiments of the present disclosure, a generic routing protocol is employed to communicate resource trust information between a sender and a receiver. Thus, the resource reservation and communication can be ensured to be completed on the basis of the general protocol. By virtue of the openness of the generic routing protocol, information interaction and resource negotiation can be controlled between multiple network devices provided by different device providers. According to the embodiments of the present disclosure, openness in terms of protocols, devices, processing methods, and the like can be achieved, so that it can be applied to networks including network devices provided by different device providers. This expands the application range of the resource reservation mechanism and reduces the cost of network congestion control as a whole. Particularly, the network congestion control based on resource trust, which is low in cost and open by a provider, can be realized in the scenes of machine learning technology, high-performance calculation, high-performance storage and the like.

Example embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

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

In environment 100, first device 110 and second device 120 may be any type of network device, such as, but not limited to, a router, a switch, and the like. Alternatively, in some embodiments, the first device 110 and/or the second device 120 may be any type of device having computing capabilities, including a terminal device or a server device. The terminal device may be any type of mobile terminal, fixed terminal, or portable terminal, including a mobile handset, desktop computer, laptop computer, notebook computer, netbook computer, tablet computer, media computer, multimedia tablet, personal Communication System (PCS) device, personal navigation device, personal Digital Assistant (PDA), audio/video player, digital camera/camcorder, positioning device, television receiver, radio broadcast receiver, electronic book device, game device, or any combination of the preceding, including accessories and peripherals for these devices, or any combination thereof. The server devices may include, for example, computing systems/servers, such as mainframes, edge computing nodes, electronic devices in a cloud environment, and so forth.

It should be understood that the structure and function of environment 100 are described for illustrative purposes only and are not meant to suggest any limitation as to the scope of the disclosure.

Fig. 2 illustrates a schematic diagram of an example signaling flow 200 for data transmission, in accordance with some embodiments. Fig. 2 will be described with reference to fig. 1 for convenience of description. As an example, the following will describe an angle with the first device 110 as a transmitting end and the second device 120 as a receiving end. This is exemplary only and not intended to be limiting.

As shown in fig. 2, the first device 110 establishes (205) a connection with the second device 120 for subsequent data transmission. For example, a Transmission Control Protocol (TCP) connection may be established between the first device 110 and the second device 120. After establishing the connection, the first device 110 and the second device 120 may be considered as peers (peers) to each other.

The first device 110 exchanges (210) capability information with the second device 120 according to a generic routing protocol. The capability information exchanged by the first device 110 with the second device 120 relates 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 according to 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, i.e., reserve such network resources to receive data from the sending end. A sender with resource trust capability can send data according to the authority of the receiver.

In some embodiments, the first device 110 may exchange capability information with the second device 120 according to a border gateway protocol (Boeder Gateway Protocol, BGP for short). That is, the generic routing protocol may be BGP. For example, after the first device 110 establishes a connection with the second device 120, the capability information related to the resource trust capability may be carried in an OPEN message (OPEN message) by BGP to exchange the resource trust capability. The first device 110 and the second device 120 may carry their capability information in an open message sent to the peer, respectively.

The capability information may include any suitable type of information to indicate resource trust capabilities 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 output queue capacity of the sender, such as capacity of a virtual output queue (VoQ). Taking BGP as an example, table 1 shows example fields for capability information, which may be included in the open message.

TABLE 1

Fields	Length (Unit: bits)
		Capability code	8
Capability length	8
		Capability value	24

In table 1, the "capability code" field is 8 bits in length, and has a value of 128, which represents that the sender of the BGP message has resource trust capability. The "capability length" field is 8 bits in length and represents the length of the "capability value" field. The "capability value" field is 24 bits in length and represents the capacity of the output queue at the message sender, e.g., voQ capacity. If the first device 110 completes the exchange of capability information with the second device 120, this means that the first device 110 has the capability to exchange resource trust with the second device 120.

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

Continuing with the signaling flow 200, the first device 110 processes (220) the data transmission to the second device 120 based on the acquired resource trust information. For example, the first device 110 may determine a target interface and a target queue in the target interface of the second device 120, which are interfaces and queues for the target network segment, based on the reachability information in the resource trust information. If the resource grant information indicates that the target interface and target queue are available to the first device 110, the first device 110 may send the target data to the second device 120. If the resource grant information indicates that the target interface and 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.

Further example embodiments regarding resource trust information are described below. In some embodiments, the first device 110 may send a resource trust request for the target network segment to the second device 120. The second device 120 may send a resource trust response, also referred to as a resource trust authority, to the first device 110 for the received request. The first device 110 may in turn determine the resource trust information by parsing the resource trust response according to the generic 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.

In some embodiments, if the generic routing protocol is BGP, the first device 110 may obtain the resource trust information via UPDATE messages passed 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 or implemented as an update message.

In such an embodiment, in order for the first device 110 to complete the exchange of resource trust information with the second device 120, the identification of the interaction resource trust information under the corresponding address family may be defined under a different Address Family Identifier (AFI). As an example, a Subsequent Address Family Identifier (SAFI) may be used as such an identification. For example, SAFI may be defined as 241 under Internet Protocol (IP) version 4 (IPv 4) AFI, internet protocol version 6 (IPv 6) AFI, virtual Private Network (VPN) version 4 (VPNv 4) AFI, VPN version 6 (VPNv 6) AFI, and layer 2VPN (L2 VPN) AFI, respectively, to represent interaction of resource trust information under the corresponding address families. Table 2 shows example fields in a message (e.g., BGP update message) for carrying resource trust information.

TABLE 2

Fields	Length (Unit: bit)
		Address family identifier	16
Subsequent address family identifier	8
		Length of next hop network address	8
Network address of next hop	Variable
		Reservation of	8
Network Layer Reachability Information (NLRI)	Variable

In Table 2, the value of the "subsequent address family identifier" field is a predetermined value (e.g., 241), meaning that this message is used for interaction of resource trust information. In one example, the "NLRI" field may be used to carry a resource trust request or resource trust response.

To this end, in some embodiments, an example field as in table 3 may be employed for the "NLRI" field or unit.

TABLE 3 Table 3

In table 3 above, the "message type" field may represent the type of interaction of the resource trust information. The interaction type of the resource trust information may include, but is not limited to: partial resource trust request, complete resource trust request, partial resource trust response, complete resource trust response. The "length" field indicates the length of the "message type specific" field, which is used to carry the contents of the resource trust request or the contents of the resource trust response. The "message type specific" field may be defined differently according to AFI-SAFI context information, as will be described below.

In some embodiments, the reachability information may indicate one or more interfaces, e.g., one or more egress interfaces, of the second device 120 for the target network segment. Alternatively or additionally, the reachability information may indicate respective quality of service (QoS) levels of one or more interfaces, such as Differentiated Services Code Points (DSCPs). Alternatively or additionally, the reachability information may indicate a respective queue in one or more interfaces, e.g. which queue in the outgoing interface is used for the target network segment. Accordingly, the resource grant information may include an indication of whether the interface and the included queue are available to the first device 110. For example, such reachability information may be included in the 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.

Examples regarding the type of resource trust interactions are described below. In the case of a partial resource trust request, the sender (e.g., first device 110) may obtain resource authorization information from the reachability routing information of the target network segment. The resource grant information may be used to communicate routing information and packet QoS classification information. The routing information in the resource grant information may be used to obtain an outbound interface on the receiving end (e.g., the second device 120) associated with the routing information. The QoS information in the resource grant information is used for acquiring corresponding queue information and related resource grant information on the receiving end.

Taking afi=1 for IPv4 unicast as an example, table 4 shows an example of fields for a partial resource trust request. Table 4 may be viewed as an example implementation of the "NLRI" field or element shown in table 3.

TABLE 4 Table 4

In table 4, the value of the "information type" field is 1, which is used to indicate a partial resource trust request. The "length" field is used to indicate 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 are used to indicate a specific target network segment to be requested by the first device 110, and the information length of the partial fields is variable. As can be seen from table 4, resource trust information for multiple segments can be requested.

In the case of a full resource trust request, the sender (e.g., first device 110) obtains all of the routing information, qoS classification, interfaces, queues, and resource grant information on the receiver (e.g., second device 120). If the value of the "information type" field in Table 3 is 2, then a complete resource trust request is indicated. The request does not carry IP network segment information, indicating that the first device 110 desires to obtain reachability information for all target network segments of the second device 120 and corresponding resource authorization information.

The partial resource trust response corresponds to the partial resource trust request. In the case of a partial resource trust response, the receiving end (e.g., the second device 120) returns corresponding interface, queue, and resource grant information according to the routing information and QoS classification information requested by the sending end.

Table 5 shows an example of fields for a partial resource trust response. Table 5 may be viewed as an example implementation of the "NLRI" field or element shown in table 3.

TABLE 5

In table 5 above, the "information type" field has a value of 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 according to the interface condition of the target network segment on the second device 120. The partial resource trust response indicates the following information: reachable IP network segments, such as an "IPv4 address prefix" field; an outbound interface, such as an "interface index" field; queues in the egress interface, such as an "interface queue index" field; the outbound interface and queue trust values (i.e., 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 an "interface resource trust authority" field. As can be seen from table 5, the second device 120 may have multiple interfaces for the target network segment and the first device 110 may request resource trust information for multiple target network segments.

The complete resource trust response corresponds to the complete resource trust request. The receiving end (e.g., second device 120) may return locally all routed reachability information, egress interface information, traffic classification, queue mapping, and resource trust authority information.

Table 6 shows an example of fields for a complete resource trust response. Table 6 may be viewed as an example implementation of the "NLRI" field or element shown in table 3.

TABLE 6

In table 6 above, the "information type" field has a value of 4, indicating a complete resource trust response. After receiving the complete resource trust request message of the first device 110, the second device 120 completes the complete resource trust response according to the interface condition of the target network segment on the second device 120. The complete resource trust response indicates the following information: reachable IP network segments, such as an "IPv4 address prefix" field; an outbound interface, such as an "interface index" field; queues in the egress interface, such as an "interface queue index" field; the outbound interface and queue trust values (i.e., 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 an "interface resource trust authority" field. As can be seen from table 6, the second device 120 may have multiple interfaces for the target network segment and the first device 110 may request resource trust information for multiple target network segments.

Example fields in the resource trust request and the resource trust response are described above. It should be appreciated that the above-described fields are merely exemplary, and that in some embodiments, the resource trust request and the resource trust response may include more or fewer fields.

In some embodiments, the first device 110 and the second device 120 may exchange resource trust information through a complete resource trust request and a complete resource trust response. For example, in the case where the first device 110 establishes an initial connection with the second device 120 or in a device initialization phase, a full amount of resource trust information may be obtained. In other words, in such an embodiment, the target network segment may include all reachable network segments of the second device 120.

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

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

In some embodiments, the first device 110 and the second device 120 may exchange resource trust information through a partial resource trust request and a partial resource trust response. In some embodiments, the target network segment comprises an updated network segment in which reachability occurs. The resource trust request sent by the first device 110 to the second device 120 comprises 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.

Fig. 4 illustrates a schematic diagram of an example signaling flow 400 for exchanging resource trust information in accordance with further embodiments. As shown in fig. 4, if the second device 120 increases the reachable IP network segments 1.1.1.0/24, the second device 120 sends (405) updated routing information to the first device 110, wherein the reachable information of the IP network segments 1.1.1.0/24 is increased. In response, the first device 110 sends (410) a partial resource trust request to the second device 120 requesting resource trust information for IP network segment 1.1.1.0/24. Accordingly, the second device 120 may send (415) a partial resource trust response for IP network segment 1.1.1.0/24 to the first device 110. For example, the first device 110 receives an interface, interface resource trust approval information, etc. from the second device 120 for the corresponding 1.1.1.0/24 network segment.

Fig. 5 illustrates a schematic block diagram of an example process 500 of information processing according to some embodiments of the disclosure. According to the exchange of resource trust information described above, information processing at a sender of data (e.g., first device 110) may be implemented as shown in example process 500. As shown in fig. 5, at block 510, the first device 110 processes routing information. For example, the first device 110 may interact with the second device 120 in accordance with a generic routing protocol to obtain network layer reachability information, such as prefixes of one or more network segments, of the second device 120 as neighbors.

At block 520, the first device 110 sends a resource trust request for the target network segment. For example, the first device 110 may issue partial resource information requests (as shown in fig. 4) or full resource trust requests (as shown in fig. 5) to the second device 120 according to different phases. At 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 in turn correspond reachability information (e.g., outbound interfaces, queues, 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 according to the device identifications (e.g., router IDs) of the peers. Thus, the first device 110 may determine summarized resource trust information. Table 7 shows an example of summarized resource trust information.

TABLE 7

In the example of Table 7, for a segment with an address prefix of "10.1.1.0/24", an interface with an index of 1, a queue with an index of 1 in a peer with an ID of 1.1.1.1 is available, i.e., in a resource ready state; an interface with index 2, a queue with index 1, in a peer with ID 1.1.1.2 is not available, i.e. in a resource-constrained state.

Process 500 continues. At block 540, the first device 110 generates a data packet to be transmitted, such as VoQ data. At block 550, the first device 110 performs a determination of the packet transmission logic. That is, the first device 110 determines to send data to the peer with available resources, but not to the peer with unavailable resources. For example, the first device 110 may determine whether to send data based on the resource status of the peer. In the example of table 7, under 10.1.1.0/24 reachable routing, 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.

As briefly mentioned above, in some conventional schemes, cell-based approaches are employed to encapsulate and communicate data packets. Such cell-based forwarding mechanisms exist in a closed form. To this end, in some embodiments, the transmitted data may be encapsulated according to a generic network layer protocol. Thus, the data surface intercommunication of data transmission among a plurality of network devices can be realized in the environment of multiple device suppliers.

Fig. 6 illustrates a schematic block diagram of an example process 600 of data packet processing, according to some embodiments of the disclosure. Process 600 may be performed after process 500. At block 610, the first device 110 may slice the data packet to form a plurality of slices. For example, after the first device 110 determines the next hop address of the packet, the packet may be sliced in order to ensure that the packet is balanced in traffic across multiple equivalent links. The size of each slice may be the same. At block 620, the first device 110 may encapsulate the slice with a header conforming to the native protocol. The original protocol may be, for example, a proprietary protocol of the device vendor or a generic protocol.

At block 630, the first device 110 may encapsulate the slice with a header conforming to a generic network layer protocol (e.g., IP). For example, the first device 110 may add encapsulation of the IP header for the slice. At block 640, the first device 110 may send the encapsulated slice to the selected peer.

Example procedure

Fig. 7 illustrates 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. Process 700 is described below with reference to fig. 1.

At block 710, the first device 110 exchanges capability information with the second device regarding resource trust capabilities indicating capabilities for transmitting data based on reserving network resources according to a generic routing protocol.

At block 720, the first device 110 obtains resource trust information for the second device regarding the target network segment according to the generic routing protocol, the resource trust information including reachability information for the target network segment and resource authorization information for the first device for the second device regarding the target network segment.

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

In some embodiments, obtaining resource trust information of the second device regarding the target network segment includes: according to the universal routing protocol, sending a resource trust request aiming at the target network segment to second equipment; 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 generic routing protocol.

In some embodiments, the target network segment comprises an all reachable network segment of the second device, the resource trust request comprises a complete resource trust request for the all reachable network segment, and the resource trust request comprises a complete resource trust response for the all reachable network segment.

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

In some embodiments, the target network segment comprises an update network segment for which reachability changes, the resource trust request comprises a partial resource trust request for the update network segment, and the resource trust response comprises a partial resource trust response for the update network segment.

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

In some embodiments, the reachability information indicates at least one of: the method includes the steps of receiving, by the second device, a resource grant information from the first device, the resource grant information including an indication of whether the corresponding queue is available to the first device, one or more interfaces of the second device for the target network segment, a corresponding quality of service (QoS) level of the one or more interfaces, and a corresponding queue in the one or more interfaces.

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

In some embodiments, processing the data transmission to the second device comprises: determining a target interface of the second device and a target queue in the target interface based on the reachability information; and transmitting the target data to the second device in response to the resource grant information indicating that the target interface and the target queue are available to the first device.

In some embodiments, transmitting the target data to the second device includes: encapsulating a slice of the data packet to be transmitted with a header conforming to a generic network layer protocol; and transmitting the encapsulated slice to a second device.

In some embodiments, the generic network layer protocol comprises an internet protocol.

In some embodiments, the generic routing protocol comprises a border gateway protocol, the capability information is exchanged via open messages communicated between the first device and the second device, and the resource trust information is obtained via update messages communicated between the first device and the second device.

Example apparatus and apparatus

Fig. 8 illustrates a schematic block diagram of an apparatus 800 for data transmission according to some embodiments of the present disclosure. The apparatus 800 may be implemented as or included in the first device 110. The various modules/components in apparatus 800 may be implemented in hardware, software, firmware, or any combination thereof.

As shown, the apparatus 800 includes a capability information exchange module 810 configured to exchange, at a first device, capability information related to resource trust capabilities, indicating capabilities to transmit data based on reserving network resources, with a second device according to a generic routing protocol.

The apparatus 800 further comprises a resource trust information obtaining module 820 configured to obtain resource trust information of the second device related to the target network segment according to the generic routing protocol, the resource trust information comprising 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.

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

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

In some embodiments, the target network segment comprises an all reachable network segment of the second device, the resource trust request comprises a complete resource trust request for the all reachable network segment, and the resource trust request comprises a complete resource trust response for the all reachable network segment.

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

In some embodiments, the target network segment comprises an update network segment for which reachability changes, the resource trust request comprises a partial resource trust request for the update network segment, and the resource trust response comprises a partial resource trust response for the update network segment.

In some embodiments, the request-sending module is further configured to: receiving route update information indicating to update the network segment from the second device; and sending a partial resource trust request to the second device in response to the route update information.

In some embodiments, the reachability information indicates at least one of: the method includes the steps of receiving, by the second device, one or more interfaces for the target network segment, respective QoS levels for the one or more interfaces, respective queues in the one or more interfaces, and resource grant information including an indication of whether the respective queues are available to the first device.

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

In some embodiments, processing module 830 includes: a resource determination module configured to determine a target interface of the second device and a target queue in the target interface based on the reachability information; and a data transmission module configured to transmit the target data to the second device in response to the resource grant information indicating that the target interface and the target queue are available to the first device.

In some embodiments, the data transmission module is further configured to: encapsulating a slice of the data packet to be transmitted with a header conforming to a generic network layer protocol; and transmitting the encapsulated slice to a second device.

In some embodiments, the generic network layer protocol comprises an internet protocol.

In some embodiments, the generic routing protocol comprises a border gateway protocol, the capability information is exchanged via open messages communicated between the first device and the second device, and the resource trust information is obtained via update messages communicated between the first device and the second device.

Fig. 9 illustrates a block diagram that shows an electronic device 900 in which one or more embodiments of the disclosure may be implemented. It should be understood that the electronic device 900 illustrated in fig. 9 is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. The electronic device 900 illustrated in fig. 9 may be used to implement the first device 110 of fig. 1.

As shown in fig. 9, the electronic device 900 is in the form of 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 930, one or more communication units 940, one or more input devices 950, and one or more output devices 960. The processing unit 910 may be an actual or virtual processor and is capable of performing various processes according to programs stored in the memory 920. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to increase the parallel processing capabilities of electronic device 900.

Electronic device 900 typically includes multiple computer storage media. Such a medium may be any available media that is accessible by electronic device 900, including, but not limited to, volatile and non-volatile media, removable and non-removable media. The memory 920 may be volatile memory (e.g., registers, cache, random Access Memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 930 may be a removable or non-removable media and may include machine-readable media such as flash drives, magnetic disks, or any other media that may be capable of storing information and/or data and that may be accessed within electronic device 900.

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

The communication unit 940 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 900 may be implemented in a single computing cluster or in multiple computing machines capable of communicating over a communications connection. Thus, the electronic device 900 may operate in a networked environment using logical connections to one or more other servers, a network Personal Computer (PC), or another network node.

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

According to an exemplary implementation of the present disclosure, a computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions are executed by a processor to implement the method described above is provided. According to an exemplary implementation of the present disclosure, there is also provided a computer program product tangibly stored on a non-transitory computer-readable medium and comprising computer-executable instructions that are executed by a processor to implement the method described above.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus, devices, and computer program products implemented according to the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer readable program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various implementations of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The foregoing description of implementations of the present disclosure has been provided for illustrative purposes, is not exhaustive, and is not limited to the implementations disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various implementations described. The terminology used herein was chosen in order to best explain the principles of each implementation, the practical application, or the improvement of technology in the marketplace, or to enable others of ordinary skill in the art to understand each implementation disclosed herein.

Claims (15)

1. A data transmission method, comprising:

exchanging, at the first device, capability information relating to resource trust capabilities, indicating the capability to transmit data based on reserving network resources, with the second device according to a generic routing protocol;

acquiring resource trust information of the second equipment related to a target network segment according to the universal routing protocol, wherein the resource trust information comprises reachability information of the target network segment and resource authorization information of the second equipment on the first equipment about the target network segment; and

and processing data transmission to the second device based on the resource trust information.

2. The method of claim 1, wherein obtaining resource trust information for the second device related to a target network segment comprises:

according to the universal routing protocol, sending a resource trust request aiming at the target network segment to the second equipment;

receiving a resource trust response from the first device for the resource trust request; and

the resource trust information is determined by parsing the resource trust response according to the generic routing protocol.

3. The method of claim 2, wherein the target network segment comprises all reachable network segments of the second device,

the resource trust request comprises a complete resource trust request for the all reachable segments and the resource trust request comprises a complete resource trust response for the all reachable segments.

4. The method of claim 3, wherein sending a resource trust request for the target network segment to the second device comprises:

and in response to establishing an initial connection between the second device and the first device, sending the complete resource trust request to the second device.

5. The method of claim 2, wherein the target network segment comprises an updated network segment with a change in reachability,

The resource trust request comprises a partial resource trust request for the update network segment and the resource trust response comprises a partial resource trust response for the update network segment.

6. The method of claim 5, wherein sending a resource trust request for the target network segment to the second device comprises:

receiving route update information from the second device indicating the updated network segment; and

and sending the partial resource trust request to the second device in response to the route update information.

7. The method of claim 1, wherein the reachability information indicates at least one of:

one or more interfaces of the second device for the target network segment,

respective quality of service (QoS) levels of the one or more interfaces,

corresponding queues in the one or more interfaces, and

the resource grant information includes an indication of whether the respective queue is available to the first device.

8. The method of claim 1, wherein the capability information comprises at least one of:

an indication that the sending device of the capability information has the resource trust capability, or

Output queue capacity of the capability information transmitting device.

9. The method of claim 1, wherein processing the data transmission to the second device comprises:

determining a target interface of the second device and a target queue in the target interface based on the reachability information; and

and transmitting target data to the second device in response to the resource grant information indicating that the target interface and the target queue are available to the first device.

10. The method of claim 9, wherein transmitting target data to the second device comprises:

encapsulating a slice of the data packet to be transmitted with a header conforming to a generic network layer protocol; and

the encapsulated slice is sent to the second device.

11. The method of claim 10, wherein the generic network layer protocol comprises an internet protocol.

12. The method of claim 1, wherein the generic routing protocol comprises a border gateway protocol,

the capability information is exchanged via open messages communicated between the first device and the second device, and the resource trust information is obtained via update messages communicated between the first device and the second device.

13. An apparatus for data transmission, comprising:

a capability information exchange module configured to exchange, at the first device, capability information relating to resource trust capabilities, indicating a capability to transmit data based on reserving network resources, with the second device according to a generic routing protocol;

a resource trust information acquisition module configured to acquire resource trust information of the second device related to a target network segment according to the universal routing protocol, wherein the resource trust information comprises reachability information of the target network segment and resource authorization information of the second device on the first device about the target network segment; and

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 coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, which when executed by the at least one processing unit, cause the electronic device to perform the method of any one of claims 1 to 12.

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