Cross-domain data processing method and apparatus, and device, storage medium and program product

Abstract

The present application relates to a cross-domain data processing method and apparatus, and a device, a storage medium and a program product, and relates to the field of network technology and security. The method comprises: on the basis of a data packet received from a first domain, acquiring a segment identifier of a head node of the first domain and a binding segment identifier of a second domain in the data packet; on the basis of the segment identifier and the binding segment identifier, using a check code generation algorithm to generate a first check code; and when the data packet includes a second check code identical to the first check code, forwarding the data packet on the basis of the binding segment identifier, wherein the second check code is generated by the head node on the basis of the segment identifier and the binding segment identifier by using a pre-configured check code generation algorithm, and the pre-configured check code generation algorithm is from the second domain.

Description

Cross-domain data processing methods, devices, equipment, storage media, and program products

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on April 23, 2024, with application number 2024104913652, entitled "Cross-domain data processing method, apparatus, device, storage medium and program product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of network technology and security, and in particular to a cross-domain data processing method, apparatus, device, storage medium, and program product. Background Technology

[0004] SRv6 (Segment Routing IPv6) is a protocol designed based on source routing principles for forwarding IPv6 packets over a network. SRv6 achieves hop-by-hop forwarding by inserting a SRH (Segment Routing Header) into IPv6 packets. This SRH contains an explicit IPv6 address stack, and intermediate nodes continuously update the destination and offset address stacks.

[0005] An IPv6 (Internet Protocol version 6) packet consists of an IPv6 standard header, 0 to n extension headers, and a payload. To implement segment routing based on the IPv6 forwarding plane, a new type of extension header (RH) called the Segment Routing Header (SRH) is added to the IPv6 routing header. This header specifies an explicit path in IPv6 and stores IPv6 segment list information, functioning similarly to the segment list in SR-MPLS (Segment Routing MPLS, segment routing based on the MPLS (Multi-Protocol Label Switching) forwarding plane).

[0006] The head node adds a Segment Routing Extension Header (SRH) to the IPv6 (Internet Protocol version 6) message, and intermediate nodes can forward the message according to the path information contained in the SRH.

[0007] The Binding Segment ID (BSID) is also a fundamental instruction in Segment Routing. It is used to identify the entire candidate path and provides functions such as tunnel connection and traffic redirection. If a packet carries the Binding Segment ID (BSID) corresponding to the candidate path, it will be redirected to the corresponding candidate path.

[0008] In current technology, in cross-domain scenarios using SRv6 (segment routing based on the IPv6 forwarding plane), the first domain inserts the binding segment identifier (BSID) of the second domain. Nodes in the second domain identify the binding segment identifier BSID and replace it with the segment identifier (SID) list of the second domain, thus enabling tunnel connections and traffic routing within the second domain. However, this technology allows the insertion of binding segment identifier BSIDs into any device that supports SRv6 (segment routing based on the IPv6 forwarding plane), which can easily lead to the abuse of network resources in the second domain.

[0009] Summary of the Invention

[0010] Therefore, it is necessary to provide a cross-domain data processing method, apparatus, device, storage medium, and program product to address the aforementioned technical problems.

[0011] Firstly, this application provides a cross-domain data processing method. The method includes:

[0012] Based on the received data packet from the first domain, obtain the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet;

[0013] Based on the segment identifier and the bound segment identifier, a first checksum is generated using a checksum generation algorithm; and

[0014] When the data packet contains a second check code that is the same as the first check code, the data packet is forwarded according to the binding segment identifier;

[0015] The second checksum is generated by the head node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm comes from the second field.

[0016] In one embodiment, before forwarding the data packet according to the binding segment identifier when the data packet contains a second check code that is the same as the first check code, the method further includes: obtaining the field value of a preset bit in the target field of the data packet; and determining that the data packet contains a second check code that is the same as the first check code when the first check code is equal to the field value.

[0017] In one embodiment, the target field includes either a first reserved field encapsulated in a hop-by-hop option header or a second reserved field encapsulated in a destination option header.

[0018] In one embodiment, after generating a first checksum using a checksum generation algorithm based on the segment identifier and the binding segment identifier, the method further includes: when the data packet does not contain a second checksum that is the same as the first checksum, then determining that the binding segment identifier is an untrusted binding segment identifier.

[0019] In one embodiment, before obtaining the segment identifier of the header node of the first domain and the binding segment identifier of the second domain from the received data packet from the first domain, the method further includes: a second controller of the second domain publishing the checksum generation algorithm to a first controller of the first domain, and the first controller sending the checksum generation algorithm to each trusted node of the first domain; the checksum generation algorithm is used by each trusted node of the first domain to generate the second checksum; and

[0020] Receive the data packet.

[0021] In one embodiment, the first domain includes a metropolitan area network, and the second domain includes a backbone network.

[0022] Secondly, this application provides a cross-domain data processing method. The method includes:

[0023] Based on the obtained segment identifier of the head node of the first field and the bound segment identifier of the second field, a second checksum is generated using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm originates from the second field; and

[0024] Send a data packet to the edge node of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum;

[0025] The edge node is configured to generate a first checksum using the checksum generation algorithm based on the segment identifier and the binding segment identifier, and forward the data packet based on the binding segment identifier if the first checksum and the second checksum are the same.

[0026] In one embodiment, after generating a second checksum using a pre-configured checksum generation algorithm based on the segment identifier of the header node of the first field and the binding segment identifier of the second field, the method further includes: obtaining the data packet to be processed; and inserting the second checksum as the field value of a preset bit in the target field of the data packet to be processed.

[0027] In one embodiment, before generating the second checksum using a pre-configured checksum generation algorithm based on the segment identifier of the header node of the first domain and the binding segment identifier of the second domain, the method further includes: receiving the checksum generation algorithm sent by the first controller of the first domain to obtain the pre-configured checksum generation algorithm; the checksum generation algorithm of the first controller of the first domain is published from the second controller of the second domain.

[0028] In one embodiment, before generating the second checksum using a pre-configured checksum generation algorithm based on the segment identifier of the header node of the first domain and the binding segment identifier of the second domain, the method further includes: receiving the checksum generation algorithm published from a second controller of the second domain to obtain the pre-configured checksum generation algorithm; and sending the checksum generation algorithm to each trusted node of the first domain; the checksum generation algorithm is used by each trusted node of the first domain to generate the second checksum.

[0029] Thirdly, this application also provides a cross-domain data processing apparatus. The apparatus includes:

[0030] The first acquisition module is used to acquire, based on the received data packet from the first domain, the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet;

[0031] The first generation module is configured to generate a first checksum based on the segment identifier and the bound segment identifier using a checksum generation algorithm; and

[0032] The forwarding processing module is used to forward the data packet according to the binding segment identifier when the data packet contains a second check code that is the same as the first check code;

[0033] The second checksum is generated by the head node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm comes from the second field.

[0034] Fourthly, this application also provides a cross-domain data processing apparatus. The apparatus includes:

[0035] The second generation module is used to generate a second checksum based on the segment identifier of the head node of the first field and the bound segment identifier of the second field, using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm originates from the second field; and

[0036] A data packet sending module is used to send data packets to the edge nodes of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum.

[0037] The edge node is configured to generate a first checksum using the checksum generation algorithm based on the segment identifier and the binding segment identifier, and forward the data packet based on the binding segment identifier if the first checksum and the second checksum are the same.

[0038] Fifthly, this application also provides a network device. The network device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0039] Based on the received data packet from the first domain, the segment identifier of the header node of the first domain and the binding segment identifier of the second domain are obtained from the data packet; a first checksum is generated using a checksum generation algorithm based on the segment identifier and the binding segment identifier; and, when the data packet contains a second checksum that is the same as the first checksum, the data packet is forwarded based on the binding segment identifier; wherein, the second checksum is generated by the header node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm originates from the second domain.

[0040] Sixthly, this application also provides a network device. The network device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0041] Based on the obtained segment identifier of the header node of the first domain and the binding segment identifier of the second domain, a second checksum is generated using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm comes from the second domain; and a data packet is sent to the edge node of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum; wherein, the edge node is used to generate a first checksum based on the segment identifier and the binding segment identifier using the checksum generation algorithm, and if the first checksum and the second checksum are the same, forward the data packet based on the binding segment identifier.

[0042] Seventhly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0043] Based on the received data packet from the first domain, the segment identifier of the header node of the first domain and the binding segment identifier of the second domain are obtained from the data packet; a first checksum is generated using a checksum generation algorithm based on the segment identifier and the binding segment identifier; and, when the data packet contains a second checksum that is the same as the first checksum, the data packet is forwarded based on the binding segment identifier; wherein, the second checksum is generated by the header node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm originates from the second domain.

[0044] Eighthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0045] Based on the obtained segment identifier of the header node of the first domain and the binding segment identifier of the second domain, a second checksum is generated using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm originates from the second domain; and a data packet is sent to the edge node of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum; wherein, the edge node is used to generate a first checksum based on the segment identifier and the binding segment identifier using the checksum generation algorithm, and if the first checksum and the second checksum are the same, forward the data packet based on the binding segment identifier.

[0046] Ninthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0047] Based on the received data packet from the first domain, the segment identifier of the header node of the first domain and the binding segment identifier of the second domain are obtained from the data packet; a first checksum is generated using a checksum generation algorithm based on the segment identifier and the binding segment identifier; and, when the data packet contains a second checksum that is the same as the first checksum, the data packet is forwarded based on the binding segment identifier; wherein, the second checksum is generated by the header node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm originates from the second domain.

[0048] Tenthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0049] Based on the obtained segment identifier of the header node of the first domain and the binding segment identifier of the second domain, a second checksum is generated using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm originates from the second domain; and a data packet is sent to the edge node of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum; wherein, the edge node is used to generate a first checksum based on the segment identifier and the binding segment identifier using the checksum generation algorithm, and if the first checksum and the second checksum are the same, forward the data packet based on the binding segment identifier.

[0050] Details of one or more embodiments of this application are set forth in the following drawings and description. Other features, objects, and advantages of this application will become apparent from the specification, drawings, and claims. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the disclosed drawings without creative effort.

[0052] Figure 1 is an application environment diagram of a cross-domain data processing method in one embodiment of this application.

[0053] Figure 2 is a schematic diagram of cross-domain data processing methods in traditional technologies.

[0054] Figure 3 is a flowchart illustrating a cross-domain data processing method in one embodiment of this application.

[0055] Figure 4 is a flowchart illustrating the check code comparison process in one embodiment of this application.

[0056] Figure 5(a) is a schematic diagram of a cross-domain data processing method in one embodiment of this application.

[0057] Figure 5(b) is a schematic diagram of the check code processing steps in one embodiment of this application.

[0058] Figure 6 is a schematic diagram of a cross-domain data processing method in another embodiment of this application.

[0059] Figure 7 is a structural block diagram of a cross-domain data processing device in one embodiment of this application.

[0060] Figure 8 is a structural block diagram of a cross-domain data processing device in another embodiment of this application.

[0061] Figure 9 is an internal structure diagram of a network device in one embodiment. Detailed Implementation

[0062] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0063] Explanation of some terms used in this application:

[0064] A BSID (Binding SID) is a special type of segment ID that provides some scalability to SRv6 (Segment Routing IPv6, segment routing based on the IPv6 (Internet Protocol version 6) forwarding plane). Using BSIDs to concatenate paths can reduce the stack depth and header overhead of SRv6 to some extent. Especially in cross-domain scenarios, for security and privacy reasons, end-to-end forwarding paths can be constructed by inserting BSIDs.

[0065] The IPv6 (Internet Protocol version 6) protocol defines a variety of extension headers, among which the Hop-by-Hop Options Header (HBH) and Destination Options Header (DOH) reserve extension fields that can be defined and read / written.

[0066] The cross-domain data processing method provided in this application embodiment can be applied to the application environment shown in Figure 1. In this application embodiment, the first domain may include a metropolitan area network (MAN), and the second domain may include a backbone network. The cross-domain data processing method provided in this application embodiment can be executed by the edge node of the backbone network shown in Figure 1. The other cross-domain data processing method provided in this application embodiment can be executed by the head node of the MAN shown in Figure 1.

[0067] Based on the application environment shown in Figure 1, in the cross-domain scenario of SRv6, the problem of cross-domain service scheduling can be solved by using the bound segment identifier (BSID). The backbone network (second domain) pre-establishes differentiated paths, uses the bound segment identifier (BSID) as the path identifier, and transmits the path carrying the bound segment identifier (BSID) to the metropolitan area network (first domain) devices through a route reflector (RR) or controller. The head node (head-end device) of the metropolitan area network can insert the bound segment identifier (BSID) into the segment identifier (SID) list without needing to insert the detailed segment identifier (SID) list of the backbone network. After receiving the data packet, the backbone network replaces the bound segment identifier (BSID) with the segment identifier (SID) list from the backbone network, encapsulates it in the data packet header, and pops it before leaving the backbone network. This method reduces the length of the metropolitan area network's segment identifier (SID) list and allows for path adjustments in the backbone network without requiring the metropolitan area network to readjust the segment identifier (SID), thus shielding the two networks from network changes.

[0068] Based on current technology, in the scenario described above, the following problem exists: the backbone network fully trusts the binding segment identifier (BSID) from the metropolitan area network (MAN) and performs outer encapsulation based on the BSID. However, as shown in Figure 2, all MAN (first domain) devices supporting SRv6 can insert the BSID. Once an untrusted device obtains and inserts the binding segment identifier (BSID) (for example, by copying a normal data packet and reading the binding segment identifier from it), the backbone network will redirect traffic to a differentiated path based on the binding segment identifier, thus causing the abuse of the backbone network's high-quality resources.

[0069] Therefore, this application provides a cross-domain data processing method that prevents the arbitrary misuse of network resources such as backbone networks. The cross-domain data processing method of this application will be further described below with reference to various embodiments and corresponding accompanying drawings.

[0070] In one embodiment, as shown in Figure 3, a cross-domain data processing method is provided. This method can be applied to the edge nodes of the backbone network shown in Figure 1, and the method may include the following steps:

[0071] Step S301: Based on the received data packet from the first domain, obtain the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet.

[0072] The edge node of the second domain (the edge node of the backbone network) can receive data packets from the first domain (metropolitan area network). The data packets from the first domain can be sent by the head node (head-end device) of the metropolitan area network and passed to the edge node of the second domain through the relevant nodes of the first domain. Then the edge node of the second domain can obtain the segment identifier (metropolitan area SID[0]) of the head node of the first domain and the binding segment identifier (BSID) of the second domain in the data packet.

[0073] Step S302: Generate the first check code using the check code generation algorithm based on the segment identifier and the bound segment identifier.

[0074] In this step, the edge nodes of the second domain can generate a first checksum based on the segment identifier and the bound segment identifier (but not limited to the segment identifier and the bound segment identifier) ​​using a pre-determined checksum generation algorithm. This checksum generation algorithm can be an algorithm such as Fletcher-8, and it can be pre-determined by the controller of the second domain (to distinguish it from the controller of the first domain, the controller of the second domain is referred to as the second controller of the second domain, and the controller of the first domain is referred to as the first controller of the first domain). This checksum generation algorithm needs to be pre-configured on the trusted nodes of the first domain and the edge nodes of the second domain.

[0075] Step S303: When the data packet contains a second check code that is the same as the first check code, the data packet is forwarded according to the binding segment identifier.

[0076] In this step, after generating the first checksum, the edge node of the second domain needs to determine whether the data packet from the first domain contains a second checksum that is identical to the first checksum. If the data packet contains a second checksum that is identical to the first checksum, the edge node of the second domain can forward the data packet based on the binding segment identifier (BSID). Specifically, the edge node of the second domain can trust the binding segment identifier (BSID) inserted into the data packet. The edge node of the second domain can map the binding segment identifier (BSID) to the segment identifier list (SID List) of the second domain (backbone network), insert it into the header, and forward the data packet according to the policy.

[0077] In some embodiments, after generating a first checksum using a checksum generation algorithm based on the segment identifier and the binding segment identifier, the method may further include: if the data packet does not contain a second checksum that is the same as the first checksum, then determining that the binding segment identifier is an untrusted binding segment identifier.

[0078] In this embodiment, when the edge node of the second domain determines that the data packet does not contain a second check code that is the same as the first check code, it means that the binding segment identifier BSID inserted in the data packet cannot be trusted. The edge node of the second domain can choose not to forward the data packet, thereby preventing the network resources of the second domain (backbone network) from being abused.

[0079] In step S303 above, the second checksum contained in the data packet is generated by the head node of the first domain (metropolitan area network) using a pre-configured checksum generation algorithm (pre-determined by the second controller of the second domain) based on the segment identifier and the binding segment identifier. This pre-configured checksum generation algorithm of the head node of the first domain originates from the second domain. That is, if a node in the first domain is a trusted node, that node will be pre-configured with a checksum generation algorithm. Therefore, when that node sends a data packet, it can generate a second checksum based on the segment identifier and binding segment identifier of the node (head node) using the pre-configured checksum generation algorithm and write it into the data packet before sending it to the edge node of the second domain. Thus, the edge node can complete the trustworthiness verification and forwarding process of the binding segment identifier in the data packet through steps S302 to S304 above. However, if a node in the first domain is not a trusted node, it cannot use the checksum generation algorithm to generate a second checksum that can be verified by the edge node of the second domain. In this way, the edge node of the second domain can prevent the network resources of the second domain (backbone network) from being arbitrarily abused based on the trustworthiness judgment of the binding segment identifier.

[0080] Compared to other trustworthiness verification methods, such as the HMAC (Message Authentication Code) field in SRv6 TLV (Type Length Value), this method can only ensure that the data packet is not tampered with by intermediate nodes, but cannot determine the trustworthiness of the BSID (Binding Segment Identifier) ​​illegally inserted by the header node. However, the method in this application can verify the trustworthiness of the BSID inserted by the header node. Another example is the whitelist method: the backbone network controls whether to trust the BSID of the received data packet through a whitelist. The first controller of the metropolitan area network sends the whitelist to the second controller of the backbone network. The whitelist method requires the metropolitan area network to expose its device (node) information to the backbone network and requires long-term maintenance of the whitelist. In contrast, the method in this application only requires the backbone network and the metropolitan area network to transmit the verification code generation algorithm, maintaining relative independence between the two networks.

[0081] The cross-domain data processing method described in the above embodiments allows a node in the second domain to obtain the segment identifier of the header node of the first domain and the binding segment identifier of the second domain when it receives a data packet from the first domain. Then, based on the segment identifier and the binding segment identifier, a first checksum is generated using a checksum generation algorithm. If the data packet contains a second checksum identical to the first checksum, the data packet is forwarded based on the binding segment identifier. The second checksum is generated by the header node using a pre-configured checksum generation algorithm from the second domain based on the segment identifier and the binding segment identifier. Therefore, the node in the second domain can identify and determine the trustworthiness of the binding segment identifier (BSID) inserted into the data packet from the first domain. If the data packet contains a second checksum identical to the first checksum, the inserted binding segment identifier (BSID) is confirmed to be trustworthy. The data packet is then forwarded according to a policy, thus preventing the arbitrary abuse of network resources such as the backbone network.

[0082] In one embodiment, as shown in FIG4, before forwarding the data packet according to the binding segment identifier in step S303 when the data packet contains a second check code that is the same as the first check code, the following steps may also be included:

[0083] Step S401: Obtain the field value of the target field in the data packet at the preset position.

[0084] Step S402: When the first check code is equal to the field value, it is determined that the data packet contains a second check code that is the same as the first check code.

[0085] In this embodiment, in step S401, the edge node of the second domain can obtain the field value of the target field in the data packet after receiving the data packet from the first domain. The target field refers to the field used by the head node to write / insert the second checksum. The preset position of the target field can be used to write / insert the second checksum, and the second checksum is written / inserted as a field value into the preset position of the target field.

[0086] In one embodiment, as shown in FIG5(a), the target field may include a first reserved field encapsulated in the Hop-by-Hop Options Header (HBH) or a second reserved field encapsulated in the Destination Options Header (DOH). Specifically, the header node of the first field may insert the second checksum as a field value into a preset position (e.g., the first 8 bits) of the first reserved field encapsulated in the Hop-by-Hop Options Header (HBH) or the second reserved field encapsulated in the Destination Options Header (DOH). Thus, the edge node of the second field can obtain the field value of the first reserved field encapsulated in the HBH or the second reserved field encapsulated in the Destination Options Header (DOH) in the data packet after receiving the data packet from the first field.

[0087] In step S402, after generating the first checksum and extracting the aforementioned field value, the edge node of the second domain can compare the first checksum with the field value. When the first checksum and the field value are equal, the edge node of the second domain can determine that the data packet from the first domain contains a second checksum that is identical to the first checksum. In some embodiments, when the first checksum and the field value are not equal, the edge node of the second domain can determine that the data packet from the first domain does not contain a second checksum that is identical to the first checksum.

[0088] The solution in this embodiment can implement checksum verification based on existing encapsulation formats without adding extra overhead.

[0089] In some embodiments, before obtaining the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet received from the first domain in step S301, the following steps may be included: the second controller of the second domain publishes the checksum generation algorithm to the first controller of the first domain, and the first controller sends the checksum generation algorithm to each trusted node of the first domain; the checksum generation algorithm is used by each trusted node of the first domain to generate a second checksum; and the data packet is received.

[0090] In this embodiment, the second controller of the second domain (backbone network) can pre-publish the checksum generation algorithm to the first controller of the first domain (metropolitan area network). The second controller of the second domain (backbone network) and the first controller of the first domain (metropolitan area network) can respectively distribute the algorithm to each trusted node (device) in the second domain and the first domain. Thus, when the trusted node in the first domain, acting as the head node, pushes the binding segment identifier (BSID) onto the header node, it uses the pre-configured checksum generation algorithm to calculate the second checksum by combining the header node's segment identifier (SID) with the second domain's binding segment identifier (BSID). This second checksum can then be written as a field value into a preset bit (e.g., the first 8 bits) of the first reserved field encapsulated in the hop-by-hop option header (HBH) or the second reserved field encapsulated in the destination option header (DOH). Therefore, the checksum generation algorithm is pre-configured to each trusted node, and the algorithm itself does not need to be transmitted over the network. The second controller of the backbone network and the first controller of the metropolitan area network can exchange information through an API interface (Application Programming Interface), for example, by using netconf / yang to distribute the configuration. The edge nodes of the second domain (edge ​​nodes of the backbone network) can receive data packets from the first domain (metropolitan area network). These data packets can be sent from the head nodes (head-end devices) of the metropolitan area network and transmitted to the edge nodes of the second domain via the relevant nodes of the first domain.

[0091] As an embodiment of the method of this application, as shown in Figure 5(b), the second controller of the second domain (backbone network) can use a hash algorithm (such as the Fletcher-8 algorithm) as the checksum generation algorithm. The second controller of the second domain (backbone network) can be published to the first controller of the first domain (metropolitan area network). The second controller of the second domain (backbone network) and the first controller of the first domain (metropolitan area network) can be distributed to each trusted node respectively. The head node of the first domain (metropolitan area network) can use the checksum generation algorithm to generate an 8-bit hash value from the head node's segment identifier SID + binding segment identifier BSID as the second checksum, which is then inserted into the first hop-by-hop option header HBH encapsulated in the first checksum. In the reserved fields or the second reserved field encapsulated in the Destination Options Header (DOH), the edge nodes of the second domain (backbone network) receive a data packet with a bound segment identifier (BSID) from the first domain (metropolitan area network). They can use this checksum generation algorithm to generate an 8-bit hash value by adding the segment identifier (SID) of the header node to the bound segment identifier (BSID) as the first checksum. This first checksum is then compared with the second checksum in the data packet. If the first checksum and the second checksum are the same, the bound segment identifier (BSID) inserted into the data packet is trusted. The edge nodes of the second domain (backbone network) map the bound segment identifier (BSID) to the backbone network's segment identifier list (SID List), insert it into the header, and forward the data packet according to the policy.

[0092] This embodiment can determine the trustworthiness of the binding segment identifier (BSID). It can define the authentication information of the binding segment identifier (BSID) using reserved fields encapsulated in the hop-by-hop option header (HBH) or the destination option header (DOH). This solves the technical problem that backbone network resources are easily abused. Trustworthy data transmission is achieved based on the authentication of the binding segment identifier (BSID), and no additional overhead is required based on the existing encapsulation format.

[0093] In one embodiment, as shown in Figure 6, a cross-domain data processing method is provided. This method can be applied to the head node of a metropolitan area network as shown in Figure 1, and the method may include the following steps:

[0094] Step S601: Based on the segment identifier of the head node of the first field and the binding segment identifier of the second field, generate a second check code using a pre-configured check code generation algorithm.

[0095] In this step, the head node of the first domain (metropolitan area network) can obtain the segment identifier (SID) of the head node and the bound segment identifier (BSID) of the second domain (backbone network). Based on the segment identifier (SID) and the bound segment identifier (BSID), a second checksum is generated using a pre-configured checksum generation algorithm. This pre-configured checksum generation algorithm originates from the second domain. The checksum generation algorithm can be the Fletcher-8 algorithm.

[0096] Step S602: Send data packets to the edge node of the second domain.

[0097] In this step, after generating the second checksum, the head node of the first domain (metropolitan area network) can obtain a data packet including a segment identifier, a bound segment identifier, and a second checksum, and send this data packet to the edge node of the second domain (backbone network). The edge node of the second domain (backbone network) can generate a first checksum based on the segment identifier and the bound segment identifier using a checksum generation algorithm, and if the first checksum and the second checksum are the same, forward the data packet based on the bound segment identifier. Specifically, the processing of data packets from the first domain (metropolitan area network) by the edge node of the second domain (backbone network) can refer to the aforementioned embodiment of the cross-domain data processing method applied to the edge node of the second domain (backbone network).

[0098] In this embodiment, the head node of the first domain (metropolitan area network) can use a pre-configured checksum generation algorithm from the second domain (backbone network) to generate a second checksum based on the segment identifier (SID) of the head node and the bound segment identifier (BSID) of the second domain (backbone network) during the data packet transmission phase. After obtaining a data packet containing the segment identifier, the bound segment identifier, and the second checksum, the data packet is transmitted to the edge node of the second domain (backbone network) for verification of the trustworthiness of the bound segment identifier (BSID). This ensures data packet transmission while preventing the arbitrary abuse of network resources in the second domain (backbone network).

[0099] In one embodiment, after generating the second checksum using a pre-configured checksum generation algorithm based on the obtained segment identifier of the head node of the first field and the binding segment identifier of the second field in step S601, the following steps may be further included: and

[0100] Obtain the data packet to be processed; and insert the second checksum as the field value of the target field in the data packet to be processed into the data packet to be processed.

[0101] In this embodiment, referring to Figures 5(a) and 5(b), the head node of the first domain obtains the data packet to be processed. While pushing the binding segment identifier BSID, it can calculate the second check code by using a pre-configured check code generation algorithm, combining the segment identifier SID (metro SID[0]) of the head node with the binding segment identifier BSID of the second domain (backbone network). The second check code is then inserted into the data packet as the field value of the target field in the data packet to be processed, thereby obtaining a data packet containing the segment identifier, the binding segment identifier, and the second check code. Specifically, the head node of the first domain can write the second check code as the field value into the preset position (such as the first 8 bits) of the first reserved field of the hop-by-hop option header HBH encapsulation or the second reserved field of the destination option header DOH encapsulation, thereby obtaining a data packet containing the segment identifier, the binding segment identifier, and the second check code. The scheme of this embodiment can implement check code verification based on the existing encapsulation format without adding extra overhead.

[0102] In one embodiment, before generating the second check code using a pre-configured check code generation algorithm based on the obtained segment identifier of the head node of the first field and the binding segment identifier of the second field in step S601, the following steps may also be included:

[0103] The system receives the checksum generation algorithm sent by the first controller of the first domain and obtains the pre-configured checksum generation algorithm. The checksum generation algorithm of the first controller of the first domain is published by the second controller of the second domain.

[0104] In this embodiment, the head node of the first domain can receive a checksum generation algorithm sent by the first controller of the first domain, thereby obtaining a pre-configured checksum generation algorithm. The checksum generation algorithm of the first controller is published by the second controller of the second domain.

[0105] In one embodiment, before generating the second check code using a pre-configured check code generation algorithm based on the obtained segment identifier of the head node of the first field and the binding segment identifier of the second field in step S601, the following steps may also be included:

[0106] The system receives a checksum generation algorithm published by the second controller in the second domain to obtain a pre-configured checksum generation algorithm; it then sends the checksum generation algorithm to each trusted node in the first domain; wherein the checksum generation algorithm is used by each trusted node in the first domain to generate a second checksum.

[0107] In this embodiment, the head node of the first domain can also directly obtain the checksum generation algorithm published by the second controller of the second domain, thereby obtaining a pre-configured checksum generation algorithm. The head node can also send this checksum generation algorithm to each trusted node in the first domain, where it can be used to generate a second checksum. Thus, the checksum generation algorithm can be pre-configured from the second controller of the second domain to each trusted node, without needing to be transmitted over the network. The second controller of the backbone network and the first controller of the metropolitan area network can exchange information via an API interface (Application Programming Interface), for example, by using netconf / yang to distribute configurations.

[0108] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0109] Based on the same inventive concept, this application also provides a cross-domain data processing apparatus for implementing the cross-domain data processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more cross-domain data processing apparatus embodiments provided below can be found in the limitations of the cross-domain data processing method described above, and will not be repeated here.

[0110] In one embodiment, as shown in FIG7, a cross-domain data processing apparatus is provided, the apparatus 700 including:

[0111] The first acquisition module 701 is used to acquire, based on the received data packet from the first domain, the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet;

[0112] The first generation module 702 is used to generate a first check code based on the segment identifier and the bound segment identifier using a check code generation algorithm; and

[0113] The forwarding processing module 703 is used to forward the data packet according to the binding segment identifier when the data packet contains a second check code that is the same as the first check code;

[0114] The second checksum is generated by the head node using a pre-configured checksum generation algorithm based on the segment identifier and the bound segment identifier; the pre-configured checksum generation algorithm comes from the second field.

[0115] In one embodiment, the forwarding processing module 703 is further configured to obtain the field value of the target field in the data packet at a preset position; when the first check code is equal to the field value, it is determined that the data packet contains a second check code that is the same as the first check code.

[0116] In one embodiment, the target field includes either a first reserved field encapsulated in a hop-by-hop option header or a second reserved field encapsulated in a destination option header.

[0117] In one embodiment, the forwarding processing module 703 is further configured to determine that the binding segment identifier is an untrusted binding segment identifier when the data packet does not contain a second check code that is the same as the first check code.

[0118] In one embodiment, the device 700 may further include: an algorithm publishing module, configured to publish a checksum generation algorithm from a second controller of a second domain to a first controller of a first domain, and to send the checksum generation algorithm to each trusted node of the first domain by the first controller; the checksum generation algorithm is used by each trusted node of the first domain to generate a second checksum; and a data packet receiving module, configured to receive data packets.

[0119] In one embodiment, the first domain includes a metropolitan area network, and the second domain includes a backbone network.

[0120] In one embodiment, as shown in FIG8, a cross-domain data processing apparatus is provided, the apparatus 800 including:

[0121] The second generation module 801 is used to generate a second checksum based on the segment identifier of the header node of the first field and the bound segment identifier of the second field, using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm comes from the second field; and

[0122] The data packet sending module 802 is used to send data packets to the edge nodes of the second domain; the data packet includes a segment identifier, a binding segment identifier, and a second checksum.

[0123] The edge node is used to generate a first check code based on the segment identifier and the bound segment identifier using a check code generation algorithm, and forwards the data packet based on the bound segment identifier if the first check code and the second check code are the same.

[0124] In one embodiment, the second generation module 801 is further configured to acquire a data packet to be processed; and to insert a second checksum as the field value of a preset bit in the target field of the data packet to be processed into the data packet to be processed.

[0125] In one embodiment, the device 800 may further include: an algorithm configuration module, configured to receive a checksum generation algorithm sent by a first controller of a first domain, and obtain a pre-configured checksum generation algorithm; the checksum generation algorithm of the first controller of the first domain is published by a second controller of a second domain.

[0126] In one embodiment, the device 800 may further include: an algorithm configuration module, configured to receive a checksum generation algorithm published from a second controller in a second domain, and obtain a pre-configured checksum generation algorithm; send the checksum generation algorithm to each trusted node in the first domain; and use the checksum generation algorithm to generate a second checksum at each trusted node in the first domain.

[0127] Each module in the aforementioned cross-domain data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware within or independently of the processor in the network device, or stored in software within the memory of the network device, so that the processor can invoke and execute the corresponding operations of each module.

[0128] In one embodiment, a network device is provided, the internal structure of which can be shown in Figure 9. The network device includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is connected to the system bus via the input / output interfaces. The processor of the network device provides computing and control capabilities. The memory of the network device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interfaces of the network device are used for exchanging information between the processor and external devices. The communication interface of the network device can be used for wired or wireless communication with external devices; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a cross-domain data processing method.

[0129] Those skilled in the art will understand that the structure shown in Figure 9 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the network device to which the present application is applied. Specific network devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0130] In one embodiment, a network device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0131] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0132] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0133] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0134] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0136] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A cross-domain data processing method, the method comprising: Based on the received data packet from the first domain, obtain the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet; Based on the segment identifier and the bound segment identifier, a first verification code is generated using a verification code generation algorithm; as well as When the data packet contains a second check code that is the same as the first check code, the data packet is forwarded according to the binding segment identifier; The second checksum is generated by the head node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm comes from the second field.

2. The method according to claim 1, wherein, Before forwarding the data packet according to the binding segment identifier when the data packet contains a second checksum that is identical to the first checksum, the method further includes: Obtain the field value at a preset position in the target field of the data packet; and When the first checksum is equal to the field value, it is determined that the data packet contains a second checksum that is the same as the first checksum.

3. The method according to claim 2, wherein, The target field includes either a first reserved field encapsulated in the hop-by-hop option header or a second reserved field encapsulated in the destination option header.

4. The method according to claim 1, wherein, After generating a first checksum using a checksum generation algorithm based on the segment identifier and the bound segment identifier, the method further includes: If the data packet does not contain a second check code that is the same as the first check code, then the binding segment identifier is determined to be an untrusted binding segment identifier.

5. The method according to any one of claims 1 to 4, wherein, Before obtaining the segment identifier of the header node of the first domain and the binding segment identifier of the second domain from the received data packet from the first domain, the method further includes: The second controller of the second domain publishes the checksum generation algorithm to the first controller of the first domain, and the first controller sends the checksum generation algorithm to each trusted node in the first domain; the checksum generation algorithm is used by each trusted node in the first domain to generate the second checksum; and Receive the data packet.

6. The method according to any one of claims 1 to 4, wherein, The first domain includes a metropolitan area network, and the second domain includes a backbone network.

7. A cross-domain data processing method, wherein, The method includes: Based on the obtained segment identifier of the head node of the first field and the bound segment identifier of the second field, a second checksum is generated using a pre-configured checksum generation algorithm; the pre-configured checksum generation algorithm originates from the second field; and Send a data packet to the edge node of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum; The edge node is configured to generate a first checksum using the checksum generation algorithm based on the segment identifier and the binding segment identifier, and forward the data packet based on the binding segment identifier if the first checksum and the second checksum are the same.

8. The method according to claim 7, wherein, After generating the second checksum using a pre-configured checksum generation algorithm based on the segment identifier of the head node of the first field and the bound segment identifier of the second field, the process further includes: Acquire the data packet to be processed; and The second checksum is inserted into the data packet to be processed as the field value of the target field at a preset position.

9. The method according to claim 7 or 8, wherein, Before generating the second check code using a pre-configured check code generation algorithm based on the segment identifier of the header node of the first field and the bound segment identifier of the second field, the method further includes: The first controller of the first domain receives the checksum generation algorithm sent by the first controller of the first domain, and obtains the pre-configured checksum generation algorithm; the checksum generation algorithm of the first controller of the first domain is published by the second controller of the second domain.

10. The method according to claim 7 or 8, wherein, Before generating the second check code using a pre-configured check code generation algorithm based on the segment identifier of the header node of the first field and the bound segment identifier of the second field, the method further includes: Receive the checksum generation algorithm published from the second controller in the second domain, and obtain the pre-configured checksum generation algorithm; and The verification code generation algorithm is sent to each trusted node in the first domain; the verification code generation algorithm is used by each trusted node in the first domain to generate the second verification code.

11. A cross-domain data processing apparatus, the apparatus comprising: The first acquisition module is used to acquire, based on the received data packet from the first domain, the segment identifier of the header node of the first domain and the binding segment identifier of the second domain in the data packet; The first generation module is used to generate a first verification code based on the segment identifier and the bound segment identifier using a verification code generation algorithm; as well as The forwarding processing module is used to forward the data packet according to the binding segment identifier when the data packet contains a second check code that is the same as the first check code; The second checksum is generated by the head node using a pre-configured checksum generation algorithm based on the segment identifier and the binding segment identifier; the pre-configured checksum generation algorithm comes from the second field.

12. A cross-domain data processing apparatus, the apparatus comprising: The second generation module is used to generate a second check code based on the segment identifier of the head node of the first field and the binding segment identifier of the second field, using a pre-configured check code generation algorithm; the pre-configured check code generation algorithm comes from the second field. as well as A data packet sending module is used to send data packets to the edge nodes of the second domain; the data packet includes the segment identifier, the binding segment identifier, and the second checksum. The edge node is configured to generate a first checksum using the checksum generation algorithm based on the segment identifier and the binding segment identifier, and forward the data packet based on the binding segment identifier if the first checksum and the second checksum are the same.

13. A network device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 6 or any one of claims 7 to 10.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6 or any one of claims 7 to 10.

15. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6 or any one of claims 7 to 10.

Images