Distributed Data Plane Verification Method and System

Abstract

This disclosure provides a distributed data plane verification method, comprising: in response to a current device node having the conditions for data packet conversion, the current device node converts a first subscription message sent by an upstream device node into a second subscription message; invoking the downstream device node to perform a counting task on the second subscription message, and feeding back the counting result of the second subscription message to the current device node; the current device node using the counting result of the second subscription message as the counting result of the first subscription message, and feeding it back to the upstream device node. This disclosure also provides a distributed data plane verification system.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, and in particular to a distributed data plane verification method and system for packet conversion. Background Technology

[0002] Network errors can have catastrophic economic and social consequences, making effective error detection a fundamental challenge in the networking field. A primary method for finding network errors is network verification, which automatically checks the control plane and data plane of network devices to locate errors. Data plane verification tools, as a crucial means of network verification, can detect errors before configuration and deployment; furthermore, they can check network correctness by analyzing whether the data plane (e.g., forwarding tables and access control lists) meets network requirements, directly reflecting the network's forwarding behavior, making verification relatively easy to implement.

[0003] Packet translation is a common problem in networks. Specifically, in packet networks and virtual private networks (VPNs), NAT (Network Address Translation) and IP (Internet Protocol) tunneling technologies are widely used. All Tier 1 network service providers and more than half of large network service providers use MPLS (Multi-Protocol Label Switching) tunneling. After passing through a NAT network device, the IP address of the packet changes (i.e., a translation between public and private IP addresses). When an IP tunnel exists, an IP packet is encapsulated within another IP packet at the tunnel inlet and decapsulated at the tunnel outlet. For MPLS tunnel inlet devices, an MPLS label is added to the Layer 2 header. Therefore, the inlet device transmits an MPLS label subscription message to downstream nodes in the DVnet, not an IP information predicate. The outlet device then removes the MPLS label from the upstream node and transmits the IP subscription message downstream.

[0004] However, data plane verification tools in related technologies cannot effectively handle packet translation problems. Taking two relatively advanced data plane verification tools in the industry, APT and Katra, as examples, APT proposes the concept of packet equivalence to address potential packet translation problems in networks, while Katra proposes a new formal network model and its semantics for layered networks with arbitrarily nested packet encapsulation and decapsulation. However, both approaches are based on a centralized architecture, and as the number of NATs or IP tunnels increases, network verification time inevitably extends. Summary of the Invention

[0005] To address at least one of the aforementioned problems, this disclosure provides a distributed data plane verification method and system.

[0006] According to one aspect of this disclosure, a distributed data plane verification method is provided, comprising: in response to a current device node having a data packet conversion condition, the current device node converts a first subscription message sent by an upstream device node into a second subscription message; invoking a downstream device node to perform a counting task on the second subscription message, and feeding back the counting result of the second subscription message to the current device node; the current device node using the counting result of the second subscription message as the counting result of the first subscription message, and feeding it back to the upstream device node.

[0007] In some implementations, the step of converting the first subscription message sent by the upstream device node into a second subscription message by the current device node includes: when the data packet conversion condition is that the current device node is a device node that implements network address translation, the current device node retrieves an address translation table; the current device node determines a preset protocol address that matches the first subscription message through the address translation table; and the current device node converts the network protocol address of the first subscription message into the preset protocol address to form a second subscription message with the preset protocol address.

[0008] In some implementations, the step of converting the first subscription message sent by the upstream device node into a second subscription message by the current device node includes: when the data packet conversion condition is that the current device node is a device node of the multiprotocol label switching tunnel, modeling a binary decision graph of the node labels and expanding the first subscription message to facilitate the input of the node labels; and when the current device node is the entry device node of the multiprotocol label switching tunnel, adding its own corresponding node label to the first subscription message so that the first subscription message is converted into a second subscription message with the node label of the current device node.

[0009] In some implementations, the step of converting the first subscription message sent by the upstream device node into a second subscription message by the current device node includes: when the data packet conversion condition is that the current device node is the entry device node of the Internet Protocol address tunnel, controlling the current device node to encapsulate a preset predicate before the predicate of the first subscription message, so as to convert the first subscription message into a second subscription message encapsulated with the preset predicate.

[0010] In some implementations, the step of invoking the downstream device node to perform a counting task on the second subscribed message and feeding back the counting result of the second subscribed message to the current device node includes: invoking the downstream device node on a valid path in a directed acyclic graph and initializing the downstream device node; controlling the validator of the downstream device node to perform a counting task on the second subscribed message based on a distributed verification protocol, wherein the distributed verification protocol is used to standardize the data sharing process between the validators on each device node and the expected adjacent device nodes; and controlling the downstream device node to synchronize the counting result of the second subscribed message to the current device node adjacent to itself along the reverse path of the valid path.

[0011] In some implementations, the step of having the current device node use the counting result of the second subscription message as the counting result of the first subscription message and feed it back to the upstream device node includes: when the current device node is an ingress device node, the current device node receives the counting results of the second subscription message from each of the downstream device nodes; controls the current device node to use the counting results of the second subscription message from each of the downstream device nodes as the counting result of the first subscription message; and uses the counting result of the first subscription message as the data plane verification result for the first subscription message and feeds it back to the upstream device, wherein the upstream device is an external network device.

[0012] In some implementations, the method further includes: in response to the current device node's update result of the data packet conversion rules, controlling the current device node to convert the first subscription message into an updated subscription message, and transmitting the updated subscription message to the downstream device node.

[0013] In some implementations, before the current device node converts the first subscription message sent by the upstream device node into a second subscription message, the process includes: constructing a directed acyclic graph containing all valid paths based on data plane verification requirements and network topology.

[0014] In some implementations, before the current device node converts the first subscription message sent by the upstream device node into a second subscription message, the method further includes: decomposing the verification task for the data packet conversion scenario and assigning the decomposed counting task to each device node, so that the verifier on each device node counts based on the corresponding counting task.

[0015] In some implementations, the method further includes: defining a requirements specification language to control the representation of data plane verification requirements as tuples consisting of a packet space, an ingress device node set, and behaviors, wherein when each packet in the packet space enters the network from any device node in the ingress device node set, any path of the packet satisfies the context specified in the behavior, and the behavior is specified as a tuple of regular expressions for valid paths and matching operators.

[0016] According to one aspect of this disclosure, another distributed data plane verification system is provided, comprising: a verification planner and a plurality of verifiers, wherein the verifiers are deployed on device nodes, and in response to a current device node having packet conversion conditions, the verifiers of the current device node are configured to convert a first subscription message sent by an upstream device node into a second subscription message; the verifiers of the downstream device nodes are configured to perform a counting task on the second subscription message and feed back the counting result of the second subscription message to the current device node; the verifiers of the current device node are configured to use the counting result of the second subscription message as the counting result of the first subscription message and feed it back to the upstream device node. Attached Figure Description

[0017] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0018] Figure 1 This is a block diagram of a distributed data plane verification method according to an exemplary embodiment of this disclosure.

[0019] Figure 2 This is an abstract syntax diagram of the requirements specification language for an exemplary implementation of this disclosure.

[0020] Figure 3 This is a schematic diagram of the architecture of Tulkun, which is an exemplary embodiment of this disclosure.

[0021] Figure 4 This is a schematic diagram illustrating the process of converting a regular expression into a finite automaton according to an exemplary embodiment of this disclosure.

[0022] Figure 5 This diagram illustrates the key data structures and storage processes of the DVM protocol in an exemplary embodiment of this disclosure.

[0023] Figure 6 This is a schematic diagram of the Tulkun workflow, which is an exemplary embodiment of this disclosure.

[0024] Figure 7This is a schematic diagram illustrating Tulkun's handling of data packet conversion in an exemplary embodiment of this disclosure.

[0025] Figure 8 This is a schematic diagram illustrating the burst update verification time of the existence data packet conversion rules in an exemplary embodiment of this disclosure.

[0026] Figure 9 This is a schematic diagram illustrating the incremental update verification time of the existence data packet conversion rules in an exemplary embodiment of this disclosure. Detailed Implementation

[0027] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0028] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] Unless otherwise stated, the exemplary implementations / embodiments shown are to be understood as providing exemplary features of various details that provide ways in which the technical concepts of this disclosure can be implemented in practice. Therefore, unless otherwise stated, the features of various implementations / embodiments may be additionally combined, separated, interchanged and / or rearranged without departing from the technical concepts of this disclosure.

[0030] The terminology used herein is for the purpose of describing particular embodiments and is not restrictive. As used herein, unless the context clearly indicates otherwise, the singular forms “a” and “the” are intended to include the plural forms as well. Furthermore, when the terms “comprising” and / or “including” and variations thereof are used in this specification, it indicates the presence of the stated features, integrals, steps, operations, parts, components, and / or groups thereof, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, parts, components, and / or groups thereof. It should also be noted that, as used herein, the terms “substantially,” “about,” and other similar terms are used as approximate terms rather than as terms of degree, thus explaining the inherent biases in measurements, calculated values, and / or provided values ​​that would be recognized by one of ordinary skill in the art.

[0031] Figure 1 This is a block diagram of a distributed data plane verification method according to an exemplary embodiment of this disclosure. The following will be combined with… Figure 1 The distributed data plane verification method S100 is described in detail.

[0032] like Figure 1 As shown, the distributed data plane verification method S100 includes:

[0033] In step S102, in response to the current device node having the data packet conversion condition, the current device node converts the first subscription message sent by the upstream device node into a second subscription message.

[0034] Step S104: Invoke the downstream device node to perform the counting task of the second subscribed message, and feed back the counting result of the second subscribed message to the current device node.

[0035] In step S106, the current device node uses the count result of the second subscription message as the count result of the first subscription message and feeds it back to the upstream device node.

[0036] The upstream device node is the device node that sends the first subscription message, and it can be a device node outside the network.

[0037] The current device node is the device node that receives the first subscribed message. It is located in the network and can be the entry device node.

[0038] Downstream device nodes are those that receive the second subscribed message. They are located in the same network as the current device node and can be destination nodes. Multiple device nodes can exist between the downstream and current device nodes; the second subscribed message can reach the downstream device node through the remaining device nodes. The message passing path from the current device node to the downstream device node follows the same path direction as the valid paths in a directed acyclic graph.

[0039] When the network protocol IP address corresponding to the subscription message passes through a network device with NAT, the network protocol address will change. Therefore, the first subscription message is the message before the network protocol address changes; the second subscription message is the message after the network protocol address changes, and its corresponding network protocol address is the preset protocol address extracted from the network's address translation table.

[0040] In some implementations, step S102 includes: when the data packet conversion condition is that the current device node is a device node that implements network address translation, the current device node retrieves the address translation table; the current device node determines a preset protocol address that matches the first subscription message through the address translation table; and the current device node converts the network protocol address of the first subscription message into the preset protocol address to form a second subscription message with the preset protocol address.

[0041] In some implementations, step S102 includes: when the packet conversion condition is that the current device node is a device node of the multiprotocol label switching tunnel, modeling a binary decision graph for the node label and expanding the first subscription message to facilitate the input of the node label; and when the current device node is the entry device node of the multiprotocol label switching tunnel, the current device node adds its own corresponding node label to the first subscription message so that the first subscription message is converted into a second subscription message with the node label of the current device node.

[0042] Additionally, when the current device node is a node along the multiprotocol label switching tunnel, the current device node replaces its own corresponding node label in the labeled upstream node message, so that the upstream node message is converted into a subscription message with the current device node's node label. When the current device node is the exit node of the multiprotocol label switching tunnel, the current device node deletes the node label in the labeled first subscription message, restoring the first subscription message received by the ingress node from the upstream device.

[0043] In some implementations, step S102 includes: when the data packet conversion condition is that the current device node is the entry device node of the Internet Protocol address tunnel, controlling the current device node to encapsulate a preset predicate before the predicate of the first subscription message, so as to convert the first subscription message into a second subscription message encapsulated with the preset predicate.

[0044] In addition, when the current device node is the exit device node of the Internet Protocol address tunnel, the current device node is controlled to decapsulate the predicate of the upstream subscription message with the predicate before the preset predicate, so as to restore the upstream node subscription message with the preset predicate to the first subscription message.

[0045] In some implementations, step S104 includes: retrieving downstream device nodes on the valid path of the directed acyclic graph and initializing the downstream device nodes; controlling the validators of the downstream device nodes to perform a counting task of the second subscription messages based on a distributed verification protocol, wherein the distributed verification protocol is used to standardize the data sharing process between the validators on each device node and the expected adjacent device nodes; and controlling the downstream device nodes to synchronize the counting results of the second subscription messages to the current device nodes adjacent to themselves along the reverse path of the valid path.

[0046] In some implementations, step S106 includes: when the current device node is the ingress device node, the current device node receives the counting results of each downstream device node for the second subscription message; controls the current device node to use the counting results of each downstream device node for the second subscription message as the counting result for the first subscription message; and uses the counting result for the first subscription message as the data plane verification result for the first subscription message, and feeds it back to the upstream device, wherein the upstream device is an external network device.

[0047] In some implementations, the distributed data plane verification method S100 further includes: in response to the current device node's update result of the data packet conversion rule, controlling the current device node to convert the first subscription message into an updated subscription message, and transmitting the updated subscription message to the downstream device node.

[0048] In some implementations, prior to step S102, the following steps are included: constructing a directed acyclic graph containing all valid paths based on data plane verification requirements and network topology.

[0049] In some implementations, before step S102, the method further includes: decomposing the verification task for the data packet conversion scenario and assigning the decomposed counting task to each device node, so that the verifier on each device node counts based on the corresponding counting task.

[0050] In some implementations, the distributed data plane verification method S100 further includes: setting a requirement specification language to control the data plane verification requirements to be represented in the form of a tuple consisting of a packet space, an ingress device node set, and behaviors, wherein when each packet in the packet space enters the network from any device node in the ingress device node set, any path of the packet satisfies the context specified in the behavior, and the behavior is specified as a tuple of regular expressions of valid paths and matching operators.

[0051] Figure 2 This is an abstract syntax diagram of the requirements specification language for an exemplary implementation of this disclosure.

[0052] like Figure 2As shown, this disclosure proposes steps for defining a requirements specification language to control the representation of data plane validation requirements as tuples consisting of a packet space, an ingress set, and behaviors. The abstract syntax of the requirements specification language is a declarative language, where each requirement is represented by at least a tuple consisting of a packet space (`packet_space`), an ingress set (`ingress_set`), and a behavior (`behavior`). When each packet in the packet space enters the network from any device node in the ingress set, any path of the packet must satisfy the context specified in the behavior, which is a tuple of valid paths (`path_exp`) and matching operators. The path set path_set is specified in a regular expression, for example, the data plane validation requirement (source address srcIP=10.0.1.0 / 24 and destination address dstIP=10.0.2.0 / 24, [S], S.*W.*D, "exist>=1") specifies that for any packet p with a source IP address in 10.0.1.0 / 24 and a destination IP address in 10.0.2.0 / 24, in all parallel universes of packet p, there exists at least one path that passes through path point W and reaches device node D with an external port in 10.0.2.0 / 24.

[0053] The distributed data plane verification framework Tulkun provides operators with a mapping table of device nodes and IP address prefixes. Each entry in the table indicates how a destination IP address with that IP address prefix can reach the device node via its external port. If a data plane verification request arises where the destination IP prefix of the terminal device node in the packet space and path set is inconsistent, the system will return an error message so that the operator can correct the request.

[0054] The requirements specification language introduces two requirements contexts, req_context: exist count_exp (meaning the existence count result value, where exist means existence and count_exp means the count result value) and equal (meaning equivalence), to support specifying a wide range of existence requirements and equivalence requirements.

[0055] Among them, exist count_exp (meaning the existence of a count result value) can not only be used to support common reachability and non-cycle requirements, but also to support advanced requirements such as "non-redundant delivery" and "elasticity".

[0056] The `equal` parameter is useful for verifying the integrity of packet path traces. As a concrete example, (srcIP=10.0.1.0 / 24 and dstIP=10.0.2.0 / 24, [S], SD|SD|S..D, "equal"), the total number of hops for all traces of packet p to device node D with an external port in any full set must not exceed 4 hops, and all paths from ingress device node S to device node D within less than 4 hops must be traces of packet p.

[0057] The requirements specification language also supports expressing requirements such as multicast and anycast through logical combinations of multiple (path_set, req_context) tuples. For example, a packet space H from 10.0.0.1 to 224.0.0.1, with two destination nodes D and E.

[0058] The tuple (H, [S], [(S.*D, "exsit >= 1") and (S.*E, "exist >= 1")]) specifies the multicast requirement for this packet space.

[0059] Additionally, regular expressions can be used to describe given requirements and validate how the planner determines the counting task on each device. Special attention is paid to requirements with logical combinations of multiple (path_set, exist count_exp) tuples, as regular expressions with an equal context can be validated locally. Specifically, composite requirements with regular expressions from different sources can be handled by adding virtual source devices connected to all sources. Therefore, we categorize composite requirements into two types based on the destination address of the regular expressions: those with different destination addresses and those with the same destination address.

[0060] Figure 3 This is a schematic diagram of the architecture of Tulkun, which is an exemplary embodiment of this disclosure.

[0061] Tulkun consists of a centralized verification planner and verifiers on various device nodes in the network.

[0062] The validation planner component is logically centralized. It collects validation requirements using the Tulkun specification language, along with network topology and mapping information about device nodes and IP prefixes. It then defines the validation tasks for each device node to perform distributed validation of the data plane validation requirements. To this end, the validation planner first uses automata theory to multiply the requirement by the path set `path_set` of regular expressions in the network topology, ultimately obtaining a directed acyclic graph (DVNet). The DVNet compactly represents all allowed paths in the network that satisfy the requirement.

[0063] The validation planner can also transform the data plane validation problem into a counting problem on DVNet: given a packet p entering DVNet, are there enough copies of packet p in parallel universes along all paths of packet p to be delivered to the destination node of DVNet?

[0064] However, requiring the collection of data planes from all device nodes to perform direct counting on the DVNet remains centralized and non-scalable. Therefore, the verification planner further decomposes the counting problem into smaller counting tasks located at each device node in the DVNet: counting the number of packets that can travel from that device node to the destination node in the DVNet. These counting tasks, along with node-to-node communication instructions, are sent to the corresponding device nodes in the network topology and executed in a distributed manner to compute the final verification result.

[0065] Each device node in the network is configured with a validator equipped with the DVM (Distributed Verification Messaging) protocol. In response to the current device node having the conditions for packet transformation, the validator of the current device node converts the first subscription message sent by the upstream device node into a second subscription message; the validator of the downstream device node performs a counting task on the second subscription message and feeds back the counting result to the current device node; the validator of the current device node uses the counting result of the second subscription message as the counting result of the first subscription message and feeds it back to the upstream device node.

[0066] Specifically, given a device node, its validators receive counting tasks from the validator planner and execute them; then, according to predefined communication instructions from the validator planner, they send the counting results in messages to the corresponding neighboring device nodes. To this end, we designed a distributed validator DVM protocol, which specifies how validators calculate and update their counting tasks on the device node, and how they transmit the results to neighboring device nodes in an efficient and correct manner. In short, to execute a counting task on a device node, the validator first reads the device's data plane and constructs an LEC (Local Equivalence Class Table). Next, the validator uses the LEC table and the counting results received from downstream node devices as input to calculate the distinct packet spaces and the number of packet copies from the corresponding nodes in the DVNet to the destination node. These results are stored in the CIB (Counting Information Base) and incrementally sent to validators on other neighboring device nodes according to the device communication instructions specified by the validator planner and the DVM protocol.

[0067] Figure 4 This is a schematic diagram illustrating the process of converting a regular expression into a finite automaton according to an exemplary embodiment of this disclosure.

[0068] like Figure 4 As shown, given a regular expression and a network topology, DVNet is a directed acyclic graph that compactly represents all paths in the network that match the regular expression, in the set path_set. While there are different methods for constructing DVNets (e.g., graph dual variables), in Tulkun, automata theory is primarily utilized to construct DVNets.

[0069] Specifically, given a regular expression, we first transform it into a finite automaton (Σ, Q, F, q0, δ). Here, Σ is an alphabet where each symbol is an identifier of a device node in the network, Q is the set of states in the automaton, F is the set of accepting states, q0 is the initial state, and δ: Q × Σ → Q is the state transition function. For example, for the regular expression S.*W.*D with a network of device nodes S, W, A, B, C, D, its finite automaton is as follows: Figure 4 As shown.

[0070] After converting the regular expression into a finite automaton, the verifier multiplies this automaton with the network topology to obtain a product graph G0 = (V0, E0). Each node u ∈ V0 has an attribute dev, which represents the identifier of a device in the network, and an attribute state, which represents its state in the finite automaton of path_set. Given two nodes u, v ∈ V0, if (1) u.dev - v.dev is a link in the network, then there exists a link u → v ∈ E0, and (2) δ(u.state, v.dev) = v.state.

[0071] Finally, the verification planner performs state minimization on the product graph G0 to remove redundant nodes and assigns a unique identifier to each remaining node u, which is a concatenation of u.dev and an integer to obtain DVNet.

[0072] When the validation planner constructs the DVNet and specifies tasks on the corresponding device nodes, the DVM protocol specifies how validators on each device node can share their counting results with neighboring device nodes in an efficient and correct manner to collaboratively validate requirements. To simplify the demonstration example, we introduce a protocol assuming there is only one destination node in the DVNet.

[0073] Given nodes u and v in a DVNet, and a link u→v, the DVM protocol specifies the format and order of messages that v.dev needs to send to u.dev, as well as the forwarding behavior that u.dev should take when it receives a message from v.dev. The difference between the DVM protocol and vector-based routing protocols is that the DVM protocol lacks a message loop prevention mechanism. This is because messages in a DVNet are always sent in reverse order, making it a directed acyclic graph. Therefore, networks using the DVM protocol will not form any message loops.

[0074] Figure 5 This diagram illustrates the key data structures and storage processes of the DVM protocol in an exemplary embodiment of this disclosure.

[0075] like Figure 5As shown in (a), each device node stores two types of information: a Local Equivalence Class Table (LEC) and a Counting Information Base (CIB). Given a device X, each LEC corresponds to a set of packets, and their forwarding behavior is identical on X. X stores all its LECs in a mapping table called the LECs table (packet_space, forwarding_action). Several existing data plane verification tools can be used to compute and maintain the LECs table. In practical applications, we choose to use BDD (Binary Decision Diagram) to encode packet sets into predicates and use a BDD-based data plane verification tool to maintain the minimum number of LECs on the device. This is because the DVM protocol requires devices to perform packet set operations (e.g., intersection and union), which can be efficiently implemented using logical operations on BDD.

[0076] Given a device node X, a CIB stores copies of data packets from device node X to the destination node in the DVNet for each device node X (i.e., the device node with device ID X), representing a different set of packets. Specifically, for each device node X, three different types of CIBs are stored:

[0077] CIBIn(v): For each downstream neighbor v of device node X, device node X stores the latest unprocessed count result (predicate, count vector) received from v in a mapping;

[0078] LocCIB(X.node): It stores different predicates, which are tuples containing the latest packet copy count (predicate, count vector, forwarding action, causality) from device node X to destination node. The causality field records the input to obtain the count field.

[0079] CIBOut(X.node): It records the count results of the upstream node (predicate, count vector) that will be sent to device node X.

[0080] Figure 5 (a) also provides a DVNet example, including the count results of the LEC tables CIBIn(v), CIBIn(z), and LocCIB(u) at device nodes v, z, and u. In particular, the causal field is ([v, P1, 1], [z, P1, 1]), because the count value 2 of predicate P1 is calculated from the results of v and z (i.e., 2 = 1 + 1).

[0081] like Figure 5 As shown in (b), messages in the DVM protocol are sent via a TCP (Transmission Control Protocol) connection. A message is only processed after it has been fully received. The DVM protocol defines control messages such as OPEN and KEEPAlIVE to create and maintain connections between devices. We focus on update messages, which are used to transmit counting results from any device node to the upstream neighbor device node in the DVNet.

[0082] The update message includes three fields:

[0083] Expected connection: The expected connection is a tuple indicating the message used to compute the result propagating along the connection in the DVNet.

[0084] Withdraw predicates: Predicates whose counts have been updated and which are about to be deleted.

[0085] New count results: New count results contain the list of predicates with the latest counts.

[0086] The intended connection is to distinguish connections in DVNet that have the same pair of devices.

[0087] Update message invariants. For both withdrawn predicates and newly added count results, the DVM protocol maintains an important invariant: for each update message, the union of withdrawn predicates equals the union of predicates in the newly added count results. This ensures that nodes always receive the latest, complete count results from their downstream neighbors.

[0088] Update Message Processing. Consider two neighboring device nodes u and v on a DVNet, with a link u→v. Suppose u.dev receives a specified update message from v.dev, with the expected link being u→v. Then u.dev processes this message in three steps.

[0089] Step 1: Update CIBIn(v). u.dev updates CIBIn(v) by deleting each entry in CIBIn(v) that belongs to the predicate that needs to be withdrawn and inserting all new count results into CIBIn(v).

[0090] Step 2: Update LocCIB(u).

[0091] First, to update LocCIB(u), u.dev first finds all affected entries, i.e., the entries that need to be updated. Specifically, if an entry in LocCIB(u) has a causality field containing a predicate in v that belongs to the retraction predicate of this message, then that entry needs to be updated.

[0092] Secondly, it updates the count results for all affected entries one by one. Specifically, for each pair of affected entries r and entries r0 obtained from the newly received count results, u.dev calculates the intersection S of their packet spaces. If the intersection S is not empty, a new entry r is created in LocCIB(u) based on the intersection S. new r new The counting result is obtained through two steps: 1) in r new The causal relationship between the count and the previous count results is executed using the .count function. or 1) Perform the reverse operation to eliminate the latter's effect; 2) Perform the operation between the result of the last step and r0.count. or To obtain the latest counting results. Forwarding behavior r new `.action` is the same as `r.action`. The causal relationship of this entry inherits from that of `r`, and the tuple `(v, r0)` replaces the previous record for `v`. After calculating and inserting all new entries into `LocCIB(u)`, all affected entries will be deleted from `LocCIB(u)`.

[0093] Step 3: Update CIBOut(u). Specifically, the predicates for all entries deleted from LocCIB(u) are placed in the withdrawn predicates. For all inserted entries in CIBOut(u), they are merged based on whether the count values ​​are the same, and the resulting entries are placed in the newly added count results.

[0094] After processing the update message, for each upstream neighbor w of device node u, u.dev sends an update message consisting of the expected link w→u and CIBOut(u).

[0095] Data plane update processing. If the device has a data plane update (e.g., rule insertion / deletion or physical port activation / deactivation), the DVM protocol processes it in the same way it processes update messages. Unlike processing regular update messages, none of the CIBIn(v) need to be updated at this time. The count of newly inserted entries in LocCIB(u) is determined by inverting... or It is calculated by reading the relevant entries in different CIBIn(v). In CIBOut(u), only newly added count entries and predicates with new counts after updates will be used as withdrawn predicates.

[0096] Handling packet transformation. Tulkun categorizes the packet transformation methods used by most network protocols into three types:

[0097] Method 1: Packet conversion, rewriting the bits of the existing header; Method 2: Packet encapsulation, adding a header to the existing packet header; Method 3: Packet decapsulation, removing the outermost header from a packet.

[0098] NAT uses method 1, IP tunneling uses methods 2 and 3, and MLPS tunneling uses all of the above methods. Tulkun treats all three types of packet translation methods as NAT processing.

[0099] Assume device node X is configured with NAT. It needs to calculate the count result of predicate1 and has a rule specifying that X must convert packets in predicate1 to predicate2 before forwarding them. In the DVM protocol, for all device nodes X in the constructed DVNet, a subscription message sub(predicate1, predicate2) is sent to all v.dev, where v is a downstream node of device node X. This subscription message specifies that device node v should send the count result of predicate2 to the device node, instead of the count result of predicate1. Therefore, v.dev will then send the count result of predicate2 via an update message based on the subscription message. Next, X will use the received result to update the count result of predicate1 and pass this result to the upstream node of device node X. Furthermore, if X later updates its packet conversion rule, X needs to resend the corresponding subscription message.

[0100] Assume an IP tunnel is configured between device node A and device node B. Assume that when device node A enters the tunnel, it encapsulates a predicate 4 before the original packet predicate 3, and when device node B leaves the tunnel, it decapsulates predicate 4, restoring the original packet predicate 3. Therefore, we can consider this as performing one NAT translation T on device node A and one on device node B respectively. A and T B T A The implementation is as follows: predicate3→predicate4, TB: predicate4→predicate3. The result is that nodes between A and B will send the count result of predicate4 to their upstream nodes, and A updates the count result of predicate3 with the count result of predicate4. Similarly, device nodes after B will send the count result of predicate3 to their upstream device nodes, and B updates the count result of predicate4 with the count result of predicate3.

[0101] Assume device nodes A and B are the ingress and egress devices of an MPLS tunnel, respectively, with multiple other devices along the tunnel. Tulkun treats each device in the MPLS tunnel as having configured a NAT translation. Because MPLS is based on label forwarding, we first perform BDD modeling on the labels, and then extend the subscription function to support input data structures like labels. For the MPLS tunnel ingress device node A, it adds an MPLS label to the Layer 2 header. Therefore, device node A transmits the MPLS label subscription information `label_A` to downstream nodes in the DVNet, not the IP subscription information, but rather the MPLS label subscription information `label_A`, represented as `sub(predicate, label_A)`. Similarly, the egress device node B removes the MPLS label `label_preB` from the upstream node, and thus transmits the IP subscription information to downstream nodes, represented as `sub(label_preB, predicate)`. For each device node in the MPLS tunnel, after receiving the label `label_pre` from the upstream device, it replaces it with its own new label `label_node` and passes it downstream. Therefore, the subscription information in the DVNet is represented as `sub(label_pre, label_node)`.

[0102] Tulkun can easily treat packet translation in the network as NAT and extend subscription and update messages to support different types of protocols.

[0103] Suppressing output update messages. During network events (e.g., planned configuration updates), multiple data plane updates may occur within a short period. Verifying transient data planes is sometimes unnecessary and can waste computational and communication resources. Therefore, the DVM protocol provides an optional damping mechanism inspired by border gateway protocols. Specifically, after device u.dev has finished processing update messages, before sending new update messages, it first checks if there are still any unprocessed update messages for update connections. If so, it continues processing them until the message queue is empty. It then sends the latest CIBOut(u) in the last update message cycle.

[0104] Figure 6 This is a schematic diagram of the Tulkun workflow, which is an exemplary embodiment of this disclosure.

[0105] like Figure 6 The diagram illustrates the Tulkun workflow. Specifically, we considered... Figure 6(a) Network topology and a data plane verification requirement: For all packets arriving at 10.0.0.0 / 23, when they enter the network from S, they must be able to reach device D with external port access to 10.0.0.0 / 23 via a simple path (i.e., loop-free) and through device W (i.e., waypoint) (i.e., reachability).

[0106] After this request is sent to the validation planner, the validation planner multiplies the regular expression in path_set with the network topology to generate a directed acyclic graph (DVNet). DVNet compactly represents all paths in the network that conform to this regular expression. (See reference...) Figure 6 (c) Note that destination nodes in a DVNet are marked with double circles (e.g., D1), and device nodes in a DVNet are not mapped one-to-one with devices in the network. For example, device C is split into device node C1 and device node C2 because regular expressions allow packets to reach D via [C, W, D] or [W, C, D].

[0107] The calculated DVNet is used to verify whether the network's data plane meets the requirements. Figure 5 b) is transformed into a counting problem: in all parallel universes of p, is there at least one copy of p that arrives at 10.0.0.0 / 23 and is sent to D1? The verification planner then breaks this task down into a series of counting tasks, which are executed distributed across the corresponding devices.

[0108] Figure 6 c illustrates the distributed counting process. For simplicity, we use P1, P2, and P3 to represent the packet spaces of the target IP prefixes 10.0.0.0 / 23, 10.0.0.0 / 24, and 10.0.1.0 / 24, respectively. Note that P2∩P3= / 0 and P1=P2∪P3. A node in the DVNet uses the results of the counting task of the corresponding device's data plane and all its downstream neighboring device nodes as input and computes a (packet_space, count) mapping. This mapping records the number of packet copies in all parallel universes from the current device node in the DVNet to the destination node.

[0109] Each device node stores its computed mapping in its corresponding device's CIB and sends it to the upstream device of the current device node. For example, after device node D1 computes its mapping [P1, 1] (i.e., a copy of any packet in P1 will be sent to the correct external port), it sends this result to its upstream neighbors W1, W2, W3, W3, and C1. Since C1 has only one downstream neighbor D1, C1 checks C's data plane, computes its mapping as [P1, 1], and sends it to the devices W of its upstream neighbors W1 and W3. Because this is a reverse counting process, the ingress device S will eventually receive the complete count result as the final verification result.

[0110] In this example, Figure 6 The data plane in (b) does not meet the verification requirements. We provide details of the mapping calculation for device node A1 to illustrate how Tulkun catches this error during the counting process. When A1 receives [(P1, 0)] from B1 and [(P1, 1)] from W3, examining the data plane of device A reveals that for predicate P3, since A forwards all packets in P3 to W, the number of copies of each packet in P3 that can be sent from A to D is 1. However, for packets in predicate P2, A's operation is to forward them to either B or W, but not both. Therefore, in one parallel universe where A forwards packets in P2 to B, the number of copies delivered to D is 0. In another parallel universe, A forwards packets in P2 to W, and the count is 1. Therefore, the mapping record for P2 in A1 is (P2, [0, 1]), which indicates that in one parallel universe, packets in P2 cannot be delivered to D via A. Because S forwards P1 to A, once S1 receives such information, S can capture the error and alert the operator.

[0111] Handling incremental data plane updates. We'll demonstrate the Tulkun workflow by considering a scenario where B updates its data plane to forward P1 to W instead of C. Changes to different nodes are mapped using... Figure 6 The box in (c) is highlighted. In this case, B1 and B2 will update their mappings to [(P1, 1)] and [(P1, 0)] respectively, and send the updates to their upstream neighbors' devices. However, since W does not forward any packets to B, B2's upstream neighbor W3 does not need to update its mapping. In contrast, B1's upstream neighbor A1 will update its mapping to [(P1, 1)] because regardless of whether A forwards packets from P2 to B or W, one copy of each packet will be sent to D, and P2∪P3=P1. Similarly, S1 also updates its mapping to [(P1, 1)], i.e., the update satisfies the requirements.

[0112] Figure 7 This is a schematic diagram illustrating Tulkun's handling of data packet conversion in an exemplary embodiment of this disclosure.

[0113] Handling packet transformations. We will demonstrate Tulkun's workflow for handling packet transformation rules by considering a new scenario. For Figure 6 In a network, suppose there is a device node X on the external network with an external IP address of 1.0.0.0 / 23. NAT is configured on device node S to translate external IP addresses to internal IP addresses. Specifically, when S receives the IP address 1.0.0.1 on port 1234, it will translate the IP address to 2.0.0.1 and forward it from port 3333. Figure 7 As shown in the diagram. In this scenario, when verifying the reachability of device node X to the destination IP address 10.0.0.0 / 23, X sends a subscription message p0 to all S.dev nodes in the DVNet. S.dev uses its local address translation table to translate p0 to p1 and sends it to the downstream node A.dev via a subscription message. Subsequently, the subscription message p1, not p0, will be transmitted in the DVNet. After each device completes its counting task, A.dev sends the counting result of p1 to its upstream node S.dev, and S.dev updates the counting result of p0 with the received counting result of p1.

[0114] Below, we compare Tulkun's performance with APT and Katra, two state-of-the-art centralized data plane verification tools for verifying the existence of packet transition rules. Specifically, we conducted the following experiments using three datasets representing different network sizes: INet2, BTNA, and OTEG, covering both LAN and WAN networks.

[0115] Table 1

[0116] network Number of devices Number of links Number of rules INet2 9 28 1.26×10^5 BTNA 36 76 2.52×10^5 OTEG 93 103 7.22×10^5

[0117] Table 1 is the data table used for experimental evaluation. It includes three networks, INet2, BTNA, and OTEG, as well as response data such as the number of devices, links, and rules for each network. For example, the number of devices in network INet2 is 9, the number of links is 28, and the number of rules is 1.26 × 10^5. These are not listed one by one.

[0118] Figure 8 This is a schematic diagram illustrating the burst update verification time of the existence data packet conversion rules in an exemplary embodiment of this disclosure.

[0119] Scenario of sudden updates. For each dataset, we randomly set up IP-in-IP tunnels between switches. The number of tunnels ranges from 50 to 250. Figure 8 The verification time for burst updates is presented. We observed that in all experiments, Tulkun significantly outperformed APT and Katra, with verification times 5.34 times and 16.58 times faster, respectively. Furthermore, we observed that Tulkun is insensitive to changes in the number of tunnels (increasing the number of tunnels did not significantly impact Tulkun's verification time), while the verification time of other tools increased with the number of tunnels. The reason is the same as why Tulkun outperformed other data plane verification tools in experiments without packet transition rules: Tulkun decomposes verification into lightweight on-device tasks, achieving high computational parallelism.

[0120] Figure 9 This is a schematic diagram illustrating the incremental update verification time of the existence data packet conversion rules in an exemplary embodiment of this disclosure.

[0121] Incremental update scenario. For each dataset, when a burst update containing 250 IP-in-IP tunnels ends, we randomly generate 1000 rule updates and apply them one by one. After each update, we incrementally validate the network. Figure 9 The structured data table CDF shows the incremental verification times for the three tools across three datasets. We note that Tulkun's 80th percentiles are 4.74, 48.53, and 7.98 ms, while APT and Katra's are 84.95, 340.17, and 333.71 ms and 36.82, 52.05, and 197.48 ms, respectively. We also observe that Tulkun's performance is similar to that of experiments on the same dataset without packet transition rules. This is because Tulkun handles packet transition rules through a sub-Pub mechanism between neighboring devices, while keeping the counting task lightweight on the device's verifier. When rule updates occur, only devices whose counting results may change need to incrementally update their results and send them incrementally to the required neighbors according to the DVM protocol.

[0122] The distributed data plane verification method proposed in this disclosure adds subscription and update operations during the counting task of directed acyclic graph transmission to transmit information on packet transformation, thereby achieving scalability of the data plane verification tool and avoiding the large time overhead of related technologies for packet transformation problems.

[0123] This disclosure addresses the critical issue of network data plane fault detection and troubleshooting by designing and implementing a fast and efficient network data plane verification technology applicable to large-scale networks. This provides key technical support for the automatic detection and troubleshooting of network data plane faults. Therefore, it can be applied to data plane verification in large-scale networks to ensure network security.

[0124] This disclosure, through deployment in actual networks, enables the rapid and accurate elimination of network data plane faults, improves network reliability, accelerates the construction of my country's information infrastructure, enhances the economic and social benefits of large-scale networks, and provides strong infrastructure support for the development of new technologies and applications.

[0125] This disclosure provides a prototype system solution for rapid and efficient network data plane verification technology for large-scale networks, enabling the formation and mastery of core network verification key technologies with independent intellectual property rights, creating practical industrial value, and laying the foundation for subsequent research and development of network data plane verification technology.

[0126] The distributed data plane verification system provided in this disclosure can also be implemented by a device that employs a hardware implementation of a processing system.

[0127] The apparatus may include corresponding modules that perform one or more steps in the flowchart above. Therefore, each or more steps in the flowchart above can be performed by a corresponding module, and the apparatus may include one or more of these modules. A module may be one or more hardware modules specifically configured to perform a corresponding step, or implemented by a processor configured to perform a corresponding step, or stored in a computer-readable medium for implementation by a processor, or implemented through some combination thereof.

[0128] This hardware architecture can be implemented using a bus architecture. A bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. The bus connects various circuits, including one or more processors, memory, and / or hardware modules. The bus can also connect various other circuits such as peripherals, voltage regulators, power management circuitry, external antennas, etc.

[0129] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, this diagram uses only one connection line, but this does not imply that there is only one bus or one type of bus.

[0130] Any process or method description in the flowcharts or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain. The processor performs the various methods and processes described above. For example, the method embodiments of this disclosure may be implemented as software programs tangibly contained in a machine-readable medium, such as memory. In some embodiments, part or all of the software program may be loaded and / or installed via memory and / or a communication interface. When the software program is loaded into memory and executed by the processor, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the processor may be configured to perform one of the methods described above by any other suitable means (e.g., by means of firmware).

[0131] The logic and / or steps represented in the flowchart or otherwise described herein may be specifically implemented in any readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0132] For the purposes of this specification, a "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM). Furthermore, a readable storage medium can even be paper or other suitable media on which a program can be printed, since a program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in memory.

[0133] It should be understood that various parts of this disclosure can be implemented in hardware, software, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0134] Those skilled in the art will understand that all or part of the steps of the methods described above can be implemented by a program instructing related hardware, and the program can be stored in a readable storage medium. When executed, the program includes one or a combination of the steps of the method implementation.

[0135] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a readable storage medium. The storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0136] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A distributed data plane verification method, characterized in that, include: In response to the current device node having the data packet conversion condition, the current device node converts the first subscription message sent by the upstream device node into a second subscription message, including: when the data packet conversion condition is that the current device node is the entry device node of the Internet Protocol address tunnel, controlling the current device node to encapsulate a preset predicate before the predicate of the first subscription message, so as to convert the first subscription message into a second subscription message encapsulated with the preset predicate; The downstream device node is invoked to perform a counting task on the second subscribed message, and the counting result on the second subscribed message is fed back to the current device node; The current device node uses the count result of the second subscription message as the count result of the first subscription message and feeds it back to the upstream device node; Specifically, when the current device node is the exit device node of the Internet Protocol address tunnel, the current device node is controlled to restore the upstream node subscription message encapsulated with the preset predicate to the first subscription message.

2. The distributed data plane verification method according to claim 1, characterized in that, The step of converting the first subscription message sent by the upstream device node into a second subscription message by the current device node includes: When the packet translation condition is that the current device node is a device node that implements network address translation, the current device node retrieves the address translation table. The current device node determines the preset protocol address that matches the first subscription message through the address translation table; and The current device node converts the network protocol address of the first subscription message into the preset protocol address to form a second subscription message with the preset protocol address.

3. The distributed data plane verification method according to claim 1, characterized in that, The step of converting the first subscription message sent by the upstream device node into a second subscription message by the current device node includes: When the packet conversion condition is that the current device node is a device node in a multiprotocol label switching tunnel, a binary decision graph is modeled for the node label, and the first subscription message is expanded to facilitate the input of the node label; and When the current device node is the ingress device node of the multiprotocol label switching tunnel, the current device node adds its own corresponding node label to the first subscription message, so that the first subscription message is converted into the second subscription message with the node label of the current device node.

4. The distributed data plane verification method according to claim 1, characterized in that, The step of invoking the downstream device node to perform a counting task on the second subscribed message and feeding back the counting result of the second subscribed message to the current device node includes: The downstream device node is retrieved on a valid path in the directed acyclic graph and initialized. The validator controlling the downstream device node performs a counting task on the second subscribed message based on a distributed verification protocol, wherein the distributed verification protocol is used to regulate the data sharing process between the validators on each device node and the expected adjacent device nodes; The downstream device node is controlled to synchronize the counting result of the second subscribed message to the current device node adjacent to it along the reverse path of the effective path.

5. The distributed data plane verification method according to claim 1, characterized in that, The step of having the current device node use the count result of the second subscription message as the count result of the first subscription message and feed it back to the upstream device node includes: When the current device node is the ingress device node, the current device node receives the counting results of the second subscription message from each of the downstream device nodes; The current device node is controlled to use the count results of the second subscription message by each of the downstream device nodes as the count result of the first subscription message; and The counting result of the first subscription message is used as the data plane verification result for the first subscription message and fed back to the upstream device, wherein the upstream device is an external network device.

6. The distributed data plane verification method according to claim 1, characterized in that, Also includes: In response to the current device node's update result of the data packet conversion rules, the current device node is controlled to convert the first subscription message into an update subscription message and transmit the update subscription message to the downstream device node.

7. The distributed data plane verification method according to claim 1, characterized in that, Before the current device node converts the first subscription message sent by the upstream device node into a second subscription message, the process includes: Based on the data plane verification requirements and network topology, construct a directed acyclic graph containing all valid paths; and The verification task for the data packet conversion scenario is decomposed, and the decomposed counting task is assigned to each device node so that the verifier on each device node can count based on the corresponding counting task.

8. The distributed data plane verification method according to claim 1, characterized in that, Also includes: Define a requirements specification language to control how data plane verification requirements are represented as tuples consisting of data packet space, set of entry device nodes, and behaviors. In this context, when each data packet in the packet space enters the network from any device node in the set of ingress device nodes, any path of the data packet satisfies the context specified in the behavior. The behavior is specified as a tuple of regular expressions for valid paths and matching operators.

9. A distributed data plane verification system, characterized in that, include: A verification planner and multiple verifications, wherein the verifications are arranged on device nodes. In response to the current device node having the packet conversion condition, the verifier of the current device node is used to convert the first subscription message sent by the upstream device node into the second subscription message, including: when the packet conversion condition is that the current device node is the entry device node of the Internet Protocol address tunnel, controlling the current device node to encapsulate the predicate of the first subscription message with a preset predicate, so as to convert the first subscription message into the second subscription message encapsulated with the preset predicate; The verifier of the downstream device node is used to perform a counting task on the second subscribed message and feed back the counting result of the second subscribed message to the current device node; The verifier of the current device node is used to take the counting result of the second subscription message as the counting result of the first subscription message and feed it back to the upstream device node; Specifically, when the current device node is the exit device node of the Internet Protocol address tunnel, the current device node is controlled to restore the upstream node subscription message encapsulated with the preset predicate to the first subscription message.

Images