Distributed data plane verification method and system based on failure scenarios

Abstract

The present disclosure provides a distributed data plane verification method based on a fault scenario, comprising: generating a directed acyclic graph containing all valid paths in a preset fault scenario according to data plane verification requirements, a network topology structure, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario; assigning subtasks obtained by decomposing a counting task to each device node, so that a verifier on each device node performs counting based on the subtasks; in response to a judgment result that an actual fault link matches the preset fault scenario, flooding the actual fault link in the directed acyclic graph according to a valid path corresponding to an actual link fault state; and re-counting each device node in the valid path based on the subtasks, and taking a re-counting result as a data plane verification result. The present disclosure also provides a distributed data plane verification system based on a fault scenario.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of network security, and in particular, to a distributed data plane verification method and system based on fault scenarios. BACKGROUND

[0002] Network errors (such as cyclic forwarding, network black holes, and path point violations, etc.) as a result of various problems such as software errors, hardware errors, protocol error configurations, and supervisory negligence, are ubiquitous in all types of networks (such as enterprise networks, wide area networks, and data center networks, etc.) and can have catastrophic economic and social consequences, so how to effectively find network errors is a basic challenge faced by the network field. One major method for finding network errors is network verification, which automatically checks the control plane and data plane of network devices to find errors.

[0003] In the related art, the important problem of how to extend data plane verification to be applicable to actual large networks has been systematically solved. It adopts a distributed design to avoid the scalability bottleneck inherent in centralized design, and while discovering network errors in large networks, it can also support new services such as fast rollback and switching between multiple data planes, as well as data plane verification across management domains.

[0004] However, the fault scenarios (such as link faults) that occur in real networks cause the network state to change over time, and the data plane verification tools in the related art, while being able to cope with the problem of link faults, adopt a centralized structure, have large time overheads in coping with link fault problems, and cannot meet the efficiency requirements of verification, lacking scalability for deployment in large networks. SUMMARY

[0005] To solve at least one of the above problems, the present disclosure provides a distributed data plane verification method and system based on fault scenarios.

[0006] According to one aspect of the present disclosure, a distributed data plane verification method based on fault scenarios is provided, comprising: generating a directed acyclic graph containing all valid paths in a preset fault scenario according to data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario; assigning sub-tasks obtained by decomposing a counting task to each device node, so that a verifier on each device node performs counting based on the sub-tasks; in response to a judgment result that an actual fault link matches the preset fault scenario, flooding the actual fault link in the directed acyclic graph according to a valid path corresponding to the actual link fault state; and re-counting each device node in the valid path based on the sub-tasks, taking the re-counting result as a data plane verification result.

[0007] In some implementations, generating a directed acyclic graph (DAG) containing all valid paths in a preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario includes: generating an initial DAG corresponding to the preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario; traversing each device node in the initial link graph to the entry device node, adding new labels to each traversed link, and taking the union of the new labels with the existing old labels in the link to obtain the label set of each link; and cleaning each device node in the initial DAG graph to remove redundant device nodes to generate a DAG containing all valid paths in the preset fault scenario.

[0008] In some implementations, generating an initial directed acyclic graph corresponding to the preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario includes: setting search conditions and a search queue, wherein the initial value of the search conditions is empty; extracting a device node from the search queue, generating the next layer of device nodes based on the combination of automata and network topology, and adding the next layer of device nodes to the search queue; when a terminal node is found, recording all the links traversed from the terminal node to the entry device node, and adding the label to the links, wherein the label is used to characterize the link fault state corresponding to the terminal node; and constructing the initial directed acyclic graph corresponding to various link fault states in the preset fault scenario based on the device nodes at each layer and the links between them.

[0009] In some implementations, the method further includes: when at least one of the links is in a link failure state, resulting in no valid link between the ingress device node and the destination node, setting the link failure state of at least one of the links as a specific failure scenario, and feeding the specific failure scenario back to the verification planner, wherein the specific failure scenario causes the network to fail to meet the reachability requirements.

[0010] In some implementations, cleaning each device node in the initial directed acyclic graph to remove redundant device nodes and generate a directed acyclic graph containing all valid paths in the preset fault scenario includes: deleting links that do not have the set of price tags; deleting device nodes that are not connected by the links; and merging multiple device nodes with the same attribute symbol, both being the terminal node, or both not being the terminal node and having the same adjacent next-layer device node, to remove redundant device nodes.

[0011] In some implementations, the subtasks after decomposing the counting task are assigned to each device node so that the validators on each device node perform counting based on the subtasks include: initializing each device node; controlling each device node to synchronously update messages between adjacent device nodes along the reverse path of the directed acyclic graph, wherein the update messages include expected connections, withdrawn data packet space, and newly added counting results; and, based on the update messages and a distributed verification protocol, retrieving device nodes adjacent to each device node for counting, wherein the distributed verification protocol is used to standardize the data sharing method between the validators on each device node and their adjacent device nodes.

[0012] In some implementations, retrieving each device node in the valid path to recount based on the subtask and using the recount result as the data plane verification result includes: retrieving each device node in the valid path to execute the subtask to recount based on a distributed verification protocol, wherein the distributed verification protocol is used to standardize the data sharing process between the verifier on each device node and its adjacent device nodes; synchronizing the recount result to each of the adjacent device nodes along the reverse path of the valid path; each device node adjacent to the device node recounting based on the recount result; and the entry device node in the valid path receiving the recount result and using the recount result as the data plane verification result.

[0013] In some implementations, the method further includes: reporting the actual faulty link to the verification planner in response to a judgment result that the actual faulty link does not match the preset fault scenario.

[0014] In some implementations, the method further includes: defining a requirement specification language to control the data plane verification requirements to be represented as tuples consisting of a packet space, an ingress device node set, and behaviors, wherein the tuples also include a fault tolerance field, wherein when each packet in the packet space enters the network from any of the device nodes in the ingress device node set, any path of the packet satisfies the context specified in the behaviors, and the behaviors are specified as regular expression tuples of valid paths and matching operators.

[0015] According to another aspect of this disclosure, a distributed data plane verification system based on fault scenarios is provided, comprising: a verification planner, which is configured to generate a directed acyclic graph containing all valid paths in a preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in a preset fault scenario; further configured to assign subtasks decomposed from a counting task to each device node; further configured to, in response to a judgment result that the actual faulty link matches the preset fault scenario, retrieve valid paths corresponding to the actual link fault state from the directed acyclic graph and flood the actual faulty link; a plurality of verifiers, each verifier being deployed on each of the device nodes in the network, which counts based on the subtasks; further configured to, when the actual faulty link occurs, recount based on the subtasks, and use the result of the recount as the data plane verification result. Attached Figure Description

[0016] 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.

[0017] Figure 1 This is a block diagram of a distributed data plane verification method based on a fault scenario, which is an exemplary embodiment of this disclosure.

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

[0019] Figure 3 This is a schematic diagram of the architecture of DDPV according to an exemplary embodiment of this disclosure.

[0020] 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.

[0021] Figure 5 This is a schematic diagram of the storage structure of the DVM protocol according to an exemplary embodiment of this disclosure.

[0022] Figure 6A This is a schematic diagram illustrating the data plane verification requirements and network topology of an exemplary embodiment of this disclosure; Figure 6B This is a data plane schematic diagram of an exemplary embodiment of the present disclosure; Figure 6C This is a schematic diagram illustrating the generation process of a directed acyclic graph according to an exemplary embodiment of this disclosure; Figure 6D This is a schematic diagram of the counting process of a directed acyclic graph according to an exemplary embodiment of this disclosure.

[0023] Figure 7 This diagram illustrates the delay of the DDPV planner in calculating the directed acyclic graph under different fault scenarios, as an exemplary embodiment of this disclosure.

[0024] Figure 8A This diagram illustrates the average time and speedup of the DDPV planner in an exemplary embodiment of the present disclosure for validating a complete network after topology updates for 50 fault scenarios. Figure 8B The percentage of DDPV planners in exemplary embodiments of this disclosure with incremental verification time of less than 10ms in fault scenarios; Figure 8C This is a schematic diagram of the 80th percentile of the incremental verification time of the DDPV planner in a fault scenario, representing an exemplary embodiment of this disclosure.

[0025] Figure 9 This disclosure provides an exemplary implementation of the DDPV planner's burst update verification time and its speedup relative to other tools.

[0026] Figure 10A The percentage of incremental verification times of the DDPV planner in the exemplary embodiments of this disclosure that are less than 10ms; Figure 10B This is the 80th percentile of the incremental verification time of the DDPV planner in the exemplary embodiments of this disclosure.

[0027] Figure 11 The message overhead of the DDPV planner in incremental verification in the exemplary implementation of this disclosure. Detailed Implementation

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] Figure 1 This is a block diagram of a distributed data plane verification method based on a fault scenario, as exemplarily implemented in this disclosure. The following will be combined with... Figure 1 The distributed data plane verification method S100 based on fault scenarios is described in detail.

[0033] like Figure 1 As shown, the distributed data plane verification method S100 based on fault scenarios includes:

[0034] Step S102: Based on the data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link failure states in the preset failure scenarios, generate a directed acyclic graph containing all valid paths in the preset failure scenarios.

[0035] Step S104: The subtasks after the counting task is decomposed are assigned to each device node so that the verifiers on each device node can count based on the subtasks.

[0036] Step S106: In response to the judgment result that the actual faulty link matches the preset fault scenario, retrieve the effective path corresponding to the actual link fault state in the directed acyclic graph and flood the actual faulty link.

[0037] Step S108: Retrieve each device node in the valid path and recount it based on the subtask, and use the result of the recount as the data plane verification result.

[0038] In some implementations, step S102 is performed as follows: based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in a preset fault scenario, an initial directed acyclic graph corresponding to the preset fault scenario is generated, wherein the initial directed acyclic graph is fault-tolerant within the range of the maximum number of links that the network can tolerate; each device node in the initial directed acyclic graph is traversed to the ingress device node, new labels are added to each link traversed, and the new labels are combined with the existing old labels in the links to obtain the label set of each link; and each device node in the initial directed acyclic graph is cleaned to remove redundant device nodes in order to generate a directed acyclic graph containing all valid paths in the preset fault scenario.

[0039] Step S102 may also include: determining the maximum number of fault-tolerant links in the network, which is determined based on the network operator, and, where conditions permit, all fault scenarios can be preset.

[0040] The specific process for generating the initial directed acyclic graph is as follows: Set search conditions and a search queue, where the initial value of the search conditions is empty; extract a device node from the search queue, generate the next-layer device node based on the combination of the automaton and the network topology, and add the next-layer device node to the search queue; when the terminal node is found, record all links traversed from the terminal node to the entry device node, and add labels to the links, where the labels are used to characterize the link fault state corresponding to the terminal node; and based on the device nodes at each layer and the links between them, construct an initial directed acyclic graph corresponding to various link fault states in the preset fault scenarios.

[0041] In addition, when at least one link is in a link failure state, resulting in no effective link between the ingress device node and the destination node, the link failure state of at least one link is set as a specific failure scenario, and the specific failure scenario is fed back to the verification planner, wherein the specific failure scenario causes the network to fail to meet the reachability requirements.

[0042] In some implementations, the cleaning of each device node in the initial directed acyclic graph includes: deleting links without a set of labels; deleting device nodes not connected by links; and merging multiple device nodes with the same attribute symbols, both being terminal nodes or both not being terminal nodes, and having the same adjacent next-layer device nodes to remove redundant device nodes.

[0043] In some implementations, step S104 is performed as follows: initializing each device node; controlling each device node to synchronously update messages between adjacent device nodes along the reverse path of the directed acyclic graph, wherein the update messages include expected connections, withdrawn data packet space, and newly added counting results; and based on the update messages and the distributed verification protocol, retrieving the device nodes adjacent to each device node for counting, wherein the distributed verification protocol is used to standardize the data sharing method between the verifier on each device node and its adjacent device nodes.

[0044] In some implementations, the execution steps of step S108 include: retrieving each device node in the valid path and executing a subtask to recount based on a distributed verification protocol, wherein the distributed verification protocol is used to standardize the data sharing process between the verifier on each device node and its adjacent device nodes; synchronizing the recount results to each device node adjacent to itself along the reverse path of the valid path; each device node adjacent to the device node recounting based on the recount results; and the entry device node in the valid path receiving the recount results and using the recount results as the data plane verification result.

[0045] In some implementations, the distributed data plane verification method S100 based on fault scenarios further includes: reporting the actual fault link to the verification planner in response to the judgment result that the actual fault link does not match the preset fault scenario.

[0046] In some implementations, the distributed data plane verification method S100 based on fault scenarios further includes: setting a requirement specification language to control the data plane verification requirements to be represented in the form of tuples consisting of a data packet space, an ingress device node set, and behaviors. The tuples also include a fault tolerance field. When each data packet in the data packet space enters the network from any device node in the ingress device node set, 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.

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

[0048] like Figure 2As shown, this disclosure presents the steps for setting up 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, an ingress set, and behaviors. 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.

[0049] Each data plane validation requirement is represented by a tuple consisting of a packet space, an ingress set, and a behavior. Operators can also include an optional field, fault scenes, in the tuple to specify fault tolerance. To specify behavior, we use the (match_op, path_exp) building block for entries. The basic syntax provides two match_op operators: exist count_exp (meaning the existence of a count result, where exist indicates existence and count_exp indicates the count result) and equal (meaning equivalence), to support specifying broad existence and equivalence requirements.

[0050] 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".

[0051] 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.

[0052] `path_exp` is specified as a regular expression on the device set and can be filtered using length constraints using the optional `length_filters`. For example, `(S.*D, "<= shortest+1")` represents all paths that match `S.*D` and whose number of occurrences does not exceed the shortest path + 1. Behaviors can also be specified as conjunctions, disjunctions, and negations of `(match_op, path_exp)`.

[0053] Table 1

[0054]

[0055]

[0056] Table 1 compares examples of requirements specified and verified in the DDPV (Distributed Data Plane Verification) tool with their corresponding specifications in the DDPV tool language. For example, when the data plane verification requirement is "reachability," the syntax is (P,[S],(exist>=1,S.*D)); when the data plane verification requirement is "isolation," the syntax is (P,[S],(exist==0,S.*D)), and so on. Using `exist count_exp`, operators can express simpler requirements, such as reachability, waypoint reachability, and acyclicity, as well as more advanced invariants (e.g., multicast, anycast, and non-redundant delivery routes).

[0057] DDPV provides operators with a mapping table (device node, IP address prefix), where each entry indicates how a destination IP address with that IP address prefix can reach the device node via its external port. If a mismatch occurs between the destination IP prefix in packet_space and path_exp for the end device, the system will return an error message so that operators can correct the requirement.

[0058] Figure 3 This is a schematic diagram of the architecture of DDPV according to an exemplary embodiment of this disclosure.

[0059] like Figure 3 As shown, DDPV consists of a centralized verification planner and verifiers on various device nodes in the network.

[0060] The verification planner is used to generate a directed acyclic graph containing all valid paths in a preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario; it is also used to assign the subtasks after the counting task is decomposed to each device node; and it is also used to retrieve valid paths corresponding to the actual link fault state in the directed acyclic graph and flood the actual fault link in response to the judgment result that the actual fault link matches the preset fault scenario.

[0061] The verifiers are configured in multiple ways, with each verifier deployed on a different device node in the network. They count based on subtasks and are also used to recount based on subtasks when a link fails, with the result of the recount serving as the data plane verification result.

[0062] The validation planner is logically centralized. It collects validation requirements using the DDPV specification language, along with network topology and (device, IP prefix) mapping information, and determines the counting subtask for each network device to perform distributed validation of the 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 transform the data plane validation problem into a counting problem on a directed acyclic graph (DVNet): given a data packet p entering the DVNet, is there enough copies of data packet p in parallel universes along all paths of p to be delivered to the destination node of the DVNet?

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

[0065] Verifiers are configured on each device node and follow the DVM (Distributed Verification Messaging) protocol. Given a network device node, its verifiers receive subtasks decomposed from the verification planner, execute them, and then send the counting results to the corresponding neighboring device nodes in a message according to predefined communication instructions from the verification planner. To this end, we designed a DVM protocol that specifies how verifiers compute and update their tasks on the device node, and how they transmit the results to neighboring devices in an efficient and correct manner. In short, to execute the counting subtask on the device, the verifier first reads the device node's data plane and constructs an LEC (Local Equivalence Class) table. Next, the verifier uses the LEC table and the counting results received from downstream device nodes as input to compute the distinct packet spaces and the number of copies of packets arriving at the destination node from the corresponding nodes in the directed acyclic graph. These results are stored in the CIB (Counting Information Base) and incrementally sent to validators on other neighboring device nodes according to device communication instructions specified by the validator planner and the DVM protocol.

[0066] 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.

[0067] 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 DVNet (e.g., graph dual variables), this disclosure primarily utilizes automata theory to construct DVNet.

[0068] Specifically, given a regular expression, we first transform it into a finite automaton (Σ, Q, F, q0, δ). Here, Σ is an alphabet where each symbol represents an attribute 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.

[0069] 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 attribute symbol of a device in the network, and the attribute state 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.

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

[0071] 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.

[0072] 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.

[0073] Figure 5 This is a schematic diagram of the storage structure of the DVM protocol according to an exemplary embodiment of this disclosure.

[0074] 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 (packet_space, action) mapping table called the LECs table. Several existing data plane verification tools can be used to compute and maintain the LECs table. In practical applications, we choose to use a Binary Decision Diagram (BDD) 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.

[0075] Given a device node X, the 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 the attribute symbol X) of a different packet set. Specifically, for each device node X, three different types of CIBs are stored:

[0076] 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;

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

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

[0079] 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).

[0080] 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.

[0081] The update message includes three fields:

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

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

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

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

[0086] 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.

[0087] 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.

[0088] 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).

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

[0090] 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.

[0091] 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)`.

[0092] 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.

[0093] 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).

[0094] 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.

[0095] 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.

[0096] The pre-computation and online recounting mechanism of directed acyclic graphs can improve their fault tolerance, enabling the network to verify network requirements such as reachability, loop-free paths, waypoints, and circular forwarding within the maximum number of fault-tolerant links.

[0097] The data plane verification requirement for a network can be transformed into a counting problem along a directed acyclic graph (DVNet) representing all valid paths in the network. Therefore, the Distributed Data Plane Verification (DDPV) framework pre-computes a DVNet containing all valid paths in fault scenarios specified by the operator and transforms it into a counting task. The counting task can be decomposed into subtasks on the DVNet and executed on device nodes in the distributed network, achieving scalability. Verifiers at each device node in the network first perform counting along paths corresponding to the original network topology; when a fault scenario occurs, distributed verifiers that detect link failures flood them using a link-state synchronization protocol. After synchronization, the destination recounts along the path in the DVNet corresponding to the fault scenario. If an unspecified fault scenario or a fault scenario with no valid path in the DVNet occurs, any device that discovers this during flooding will report it to the verification planner.

[0098] Based on the aforementioned pre-computation and online recounting mechanism, the execution process is explained in detail below using four steps:

[0099] Step 1: The operator specifies the maximum number of fault-tolerant links in the network.

[0100] Step 2: Generate a fault-tolerant DVNet. This step requires a search condition and a search queue. Initially, the search condition is empty, and the search queue contains only one element: the initial state of the automaton. A device node is retrieved from the search queue and combined with the automaton and the actual topology to generate a new device node. This new device node is added to the search queue, and a tree diagram is generated layer by layer in this manner. When the first terminal node is found, the number of symbols accepted by that device node is recorded. After each layer of search is completed, it is determined whether the next layer meets the shortest path or +n hop requirements. If it does, the search continues to the next layer; otherwise, the search stops. For each terminal node found, it is recorded in a table, along with all links it traverses to the ingress device node, and a label representing the current search condition is added to the label set. Each search condition or label represents a network fault state, represented by a set, where each item in the set represents a link currently disconnected due to a fault. A terminal node containing a certain label indicates that, under the network fault state of that label, the link formed by that terminal node and all its ingress device nodes constitutes a path that meets the requirements. In this way, the location where the next network error might occur is calculated, and then the nodes and tables are updated. If, during the calculation process, it is found that one or more links have broken, making it impossible to meet the network reachability requirements, these link breaks are added to the set of intolerable error scenarios (i.e., the aforementioned specific failure scenarios). Once these scenarios occur, the validator that discovered such error scenarios will report them to the validator planner.

[0101] Step 3: Label the links. Each node in the table traverses to the ingress device node, adding a label to each link it passes through. If the link already has a label, the union of the label and the old label is taken.

[0102] Step 4: Minimize. First, delete unlabeled links, then delete all device nodes without any connected links. If device node N1 and device node N2 simultaneously satisfy the following conditions: same attribute symbol, both are terminal nodes or neither is a terminal node, and have the same next hop, then merge them. During the merge, change all outgoing links of device node N2 to start from device node N1, and change all incoming links of N2 to end with N1; then delete N2. If the starting and ending device nodes of links E1 and E2 are the same, then merge them, and take the union of the labels of the two links as the label of the merged link.

[0103] The following is through Figure 6A to Figure 6D Demonstrate the DDPV workflow.

[0104] Figure 6A This diagram illustrates the data plane verification requirements and network topology for an exemplary embodiment of this disclosure.

[0105] like Figure 6AThe diagram illustrates the data plane verification requirements and network topology. The requirements are: for all packets arriving at 10.0.0.0 / 23, when they enter the network from the ingress device node S, they must be able to reach the device node D with an external port accessible to 10.0.0.0 / 23 via the shortest path (i.e., reachability); and, at most, the system can tolerate the scenario where any two links are disconnected (i.e., fault tolerance).

[0106] The network topology can be such that there is a link e1 from the ingress device node S to device node A, a link e3 from device node A to device node B, a link e4 from device node A to device node C, a link e2 from device node A to device node D, a link e7 from device node B to device node C, a link e5 from device node B to device node D, and a link e6 from device node C to device node D.

[0107] Figure 6B This is a schematic diagram of the data plane of an exemplary embodiment of this disclosure.

[0108] like Figure 6B The diagram shows the access port addresses matched by device nodes S, A, B, and C. For example, the access port address of device node A is 10.0.0.0 / 24. The diagram also provides the corresponding actions for device nodes S, A, B, and C. For example, the action of device node S is forwarding (ALL, {A}), the action of device node A is forwarding (ALL, {B, D}), the action of device node B is forwarding (ALL, {D}), and the action of device node C is forwarding (ALL, {D}).

[0109] Figure 6C This is a schematic diagram illustrating the generation process of a directed acyclic graph according to an exemplary embodiment of this disclosure.

[0110] like Figure 6C As shown, when Figure 6AAfter the data plane verification requirements are sent to the verification planner, the verification planner multiplies the regular expression in path_set with the network topology to generate DVNet, which compactly represents all paths in the network that conform to this regular expression. Using a breadth-first search algorithm to traverse the network topology, taking device node D1 with a layer height of 3 as an example, when the verification requirements are met by breadth-first traversal to this device node, the device node is marked, and the corresponding information is recorded in the table. The label set L indicates that the links on the path S1-A1-D1 are enabled without any link failures, and the edge set E records that the path from S to D1 passes through links e1 and e2. The shortest path from S to D will change if and only if any link in S1-A1-D1 is broken, and the network requirements need to be recalculated. Therefore, we analyze the case of a broken link in S1-A1-D1. When SA is broken, no data packets can reach D from S, so e1 will be added to the set U of intolerable error scenarios (i.e., specific failure scenarios). When AD is disconnected, the breadth-first search algorithm can continue from the third layer (the layer from which D1 is located). A path exists from B to C and D, and a path exists from C to B and D. To distinguish different paths, different indices are added to the device nodes to represent nodes on different paths. In the fourth layer, it is found that D2 and D3 can meet the shortest path reachability requirement when A1-D1 is disconnected. Therefore, these two device nodes are marked, and the corresponding information is updated in the table. For example, in the second row of the table, L records which links will activate the S1-A1-B1-D2 path when they are disconnected. It can be calculated that this path will be activated when AD is disconnected, AD and AC are disconnected, and AD and CD are disconnected. The edge set E represents that this path consists of SA, AB, and BD. Using this method, paths for all fault-tolerant scenarios can be calculated, while also obtaining the intolerable fault scenarios. Finally, links without labels are deleted, and then links that can be merged are merged using a merging strategy to obtain the final DVNet (i.e., DVNet). Figure 6C ).

[0111] Figure 6D This is a schematic diagram of the counting process of a directed acyclic graph according to an exemplary embodiment of this disclosure.

[0112] like Figure 6D As shown, the calculated DVNet is used to verify whether the network's data plane meets the requirements. Figure 6BThe requirement is transformed into a counting problem: in all parallel universes of packet p, whether at least one copy of packet p 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 subtasks, which are executed distributed across the corresponding devices.

[0113] Distributed counting is performed in reverse along the DVNet. When no links in the network are broken, a function with the tag containing... The path is calculated. Figure 6D In the process, the path S1-A1-D1 will be started for calculation. After node D1 calculates its mapping [P1, 1] (that is, a copy of any packet in P1 will be sent to the correct external port), it sends this result to its upstream neighbor A. As can be seen from the data plane, device node A can forward packets to device node D, so A1's count result is also [P1, 1]. Similarly, S1 can obtain a count result of [P1, 1] and uses this received result as the final verification result. A count value of 1 indicates that the shortest path reachability requirement is met.

[0114] When a link failure occurs and link e2 (i.e., AD) is disconnected, the edges labeled {e2} will be recounted, i.e., S1-A1, A1-B1, A1-C1, B1-D1, C1-D1. Device D1 calculates its mapping [P1, 1] and sends this result to its upstream neighbors B1 and C1. The data plane shows that B and C can forward the data packet to D, so their count results are both [P1, 1]. B and C forward this count result to A1. A can forward the data packet to B, but A cannot forward the data packet to C, so A's count result is [P1, 1]. Finally, the count result of S1 is [P1, 1], indicating that the shortest path reachability requirement is met.

[0115] Based on the aforementioned approach, numerous experiments will be provided below to demonstrate the feasibility and benefits of DDPV, and to show that it achieves substantial scalability and fault tolerance compared to other advanced data plane tools, while incurring minimal overhead on the device.

[0116] Table 2

[0117]

[0118]

[0119] Table 2 presents a data comparison table for thirteen network topology scenarios. To fully test the scalability of DDPV, we considered thirteen topology scenarios, and the corresponding datasets for these thirteen topologies are shown in Table 2 (not listed individually). Among them, the Internet2 (INet2) and Stanford (STFD) datasets are public datasets; Fattree-48 (FT-48) is a 48-gram fattree; and NGDC is a Clos-based real-world data center. For the WAN, we allocated link latency based on the topology. For the LAN and data center, we allocated a link latency of 10 microseconds. For each topology scenario, we generated 50 failure scenarios with ≤3 link failures based on Microsoft WAN statistics. For each failure scenario, we measured the verification time along the DVNet recount, including failure flooding (i.e., the time it takes for a distributed validator to flood a broken link to all distributed devices); and then generated 1K random rule updates to measure the incremental verification time. After each update, we progressively verified the network data plane.

[0120] To ensure fairness, under the same link failure scenario and dataset, we compared DDPV's performance with centralized data plane tools such as AP, APKeep, Deltanet, VeriFlow, and Flash. Performance tests included loop-free operation, black hole-free operation, and reachability (≤shortest path + 2), all common data plane requirements. The WAN / LAN had three link failures, and the DC had shortest path reachability for all ToR pairs. Since APKeep's source code is not publicly available, we implemented it based on APKeep's pseudocode.

[0121] We compared the verification time of DVNet recounting in fault scenarios for DDPV and centralized systems to demonstrate DDPV's advantages in achieving DPV scalability. Verification time is the time required from data plane updates on the device to the completion of verification of all requirements in the network, including network transmission and propagation delays. DVNet recounting time includes the fault flooding time, and the subsequent generation of 1K random rule updates to measure incremental verification time.

[0122] Figure 7 This diagram illustrates the delay of the DDPV planner in calculating the directed acyclic graph under different fault scenarios, as an exemplary embodiment of this disclosure.

[0123] from Figure 7We observed that the DDPV tool successfully identified all the errors we injected in all simulations. We calculated validation time as the time from the rule update reaching the device to validating all invariants (including propagation delay). For centralized DPV, we randomly assigned a device as the validator location and had all devices send their data planes to it along the lowest latency path. Figure 7 It can be seen that among the 11 topologies (excluding AT1-2 and AT2-2 with deduplication), DDPV calculates that the DVNet time tolerating 2-link-failure (3-link-failure) is <95s (<1440s).

[0124] Figure 8A This diagram illustrates the average time and speedup of the DDPV planner in an exemplary embodiment of the present disclosure for validating a complete network after topology updates for 50 fault scenarios. Figure 8B The percentage of DDPV planners in exemplary embodiments of this disclosure with incremental verification time of less than 10ms in fault scenarios; Figure 8C This is a schematic diagram of the 80th percentile of the incremental verification time of the DDPV planner in a fault scenario, representing an exemplary embodiment of this disclosure.

[0125] For each LAN / WAN, we generated 50 fault scenarios with ≤3 link failures based on Microsoft WAN statistics. For each scenario, we measured the verification time along the DVNet recount, where fault flooding occurs (see 8A); and subsequently generated 1K random rule updates to measure the incremental verification time (see [reference missing]). Figure 8B and Figure 8C The DDPV tool consistently outperforms other centralized tools. It demonstrates that by computing a fault-tolerant DVNet and recompiling online, the DDPV tool effectively revalidates in fault scenarios without involving the planner.

[0126] Figure 9 This disclosure provides an exemplary implementation of the DDPV planner's burst update verification time and its speedup relative to other tools.

[0127] For scenarios involving sudden updates, all forwarding rules are installed on the corresponding switches at once. The DDPV tool completed the verification in 0.99 seconds, which is 2.09 times faster than the best centralized DPV. Figure 9The validation time of the DDPV tool and its speedup compared to other tools are presented. For WAN / LAN, the DDPV tool completes validation in ≤1.60s, achieving a 6.21x speedup compared to the fastest centralized DPV. For DC, the DDPV tool completes NGDC validation in 40.45s, three orders of magnitude faster than AP, APKeep, and Veriflow (10 hours) (Delta-net reported a memory overflow error after 5 hours). Even compared to Flash (297.26s), a recent tool specifically designed for validating such large-scale networks, the DDPV tool is still 7.4x faster. This is because the DDPV tool breaks down validation into on-device tasks with dependency chains that are roughly linear with the network diameter. DCs have small diameters (e.g., 4 hops). The on-device validator achieves a very high level of parallelization, enabling scalability.

[0128] Figure 10A The percentage of incremental verification times of the DDPV planner in the exemplary embodiments of this disclosure that are less than 10ms; Figure 10B This is the 80th percentile of the incremental verification time of the DDPV planner in the exemplary embodiments of this disclosure.

[0129] For incremental updates, we randomly generated 10,000 rule updates and applied and validated them one by one. For 80% of the updates, the DDPV tool completed incremental validation in ≤5.42ms, compared to the best centralized DPV, which outperformed it by 4.90 times. Figure 10A This is because in DDPV tools, when a rule update occurs, only devices whose task results are affected need to incrementally update their results, and only these changed results are incrementally sent to neighbors. For most rule updates, the number of these affected devices is small. DDPV tools' 80th percentile verification time is 2355 times faster than the fastest centralized DPV. Figure 10B Across all datasets, the DDPV tool completed at least 72.72% of rule update validations in less than 10ms, while other tools achieved a lower limit of less than 1%. Figure 10A This demonstrates that the DDPV tool achieves scalable DPV across various networks and DPV scenarios.

[0130] Figure 11 The message overhead of the DDPV planner in incremental verification in the exemplary implementation of this disclosure.

[0131] For all datasets in our experiments and simulations, we first plot the CDF of the number of DVM UPDATE messages sent in the network for each rule update. Figure 11 a) and the CDF of the number of devices whose count changes with each rule update.Figure 11 b).

[0132] Figure 11 a shows that for each dataset, at least 70% of rule updates do not trigger any DVMUPDATE messages in the DDPV tool. Figure 11 b also shows that for at least 75% of rule updates, the number of devices whose counting results change does not exceed two. This indicates that by breaking down verification into counting tasks on each device, most incremental verification becomes local verification on a single network device, or only requires sharing the counting results among a small number of network devices. Therefore, DDPV achieves a significant expansion of incremental verification.

[0133] Next, we plotted the size of the DVM UPDATE messages generated in 10,000 rule updates. Figure 11 c). We observed that all UPDATE messages were less than 150KB, especially for NGDC and FT-48, where their UPDATE messages were less than 396 bytes. This indicates that DDPV has very low bandwidth overhead.

[0134] Finally, we plotted the number of CIB entries per device after 10,000 rule updates. Figure 11 d) shows that the validator on the DDPV tool device consumes only a small amount of memory on the commodity network switch.

[0135] These results show that DDPV incurs minimal storage and communication overhead on devices. Therefore, deploying DDPV on commercial network equipment is feasible.

[0136] DDPV enables scalable data plane inspection.

[0137] 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.

[0138] This disclosure can also quickly and accurately eliminate network data plane faults through deployment in actual networks, improve network reliability, accelerate the construction of my country's information infrastructure, enhance the economic and social benefits of large-scale networks, and provide strong infrastructure support for the development of new technologies and applications.

[0139] This disclosure also 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.

[0140] The distributed data plane verification method and system based on fault scenarios proposed in this disclosure are designed with a fault-tolerant directed acyclic graph pre-computation and online recounting mechanism. This allows the fault-tolerant mechanism to be activated when a link failure occurs in the network, so that the minimum number of distributed devices can participate in the recounting, thereby ensuring that network requirements are verified quickly and efficiently.

[0141] The fault-based distributed data plane verification system provided in this disclosure can also be implemented using a device that employs a hardware implementation of a processing system.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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).

[0146] 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).

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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 based on fault scenarios, characterized in that, include: Based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link failure states in a preset failure scenario, a directed acyclic graph (DAG) containing all valid paths in the preset failure scenario is generated. This includes: generating an initial DAG corresponding to the preset failure scenario; traversing each device node in the initial DAG towards the entry device node, adding new labels to each traversed link, and taking the union of the new labels with existing old labels in the link to obtain a label set for each link; and cleaning each device node in the initial DAG to remove redundant device nodes to generate a DAG containing all valid paths in the preset failure scenario. The counting task is broken down into subtasks and assigned to each device node so that the verifier on each device node can count based on the subtasks. In response to the judgment result that the actual faulty link matches the preset fault scenario, the effective path corresponding to the actual link fault state is retrieved from the directed acyclic graph and the actual faulty link is flooded. Each device node in the valid path is retrieved and recounted based on the subtask, and the result of the recount is used as the data plane verification result.

2. The distributed data plane verification method based on fault scenarios according to claim 1, characterized in that, The step of generating an initial directed acyclic graph corresponding to the preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario includes: Set the search criteria and search queue, where the initial value of the search criteria is empty; Extract one of the device nodes from the search queue, generate the next layer of device nodes based on the combination of automata and network topology, and add the next layer of device nodes to the search queue; When a terminal node is found, all links traversed from the terminal node to the ingress device node are recorded, and a tag is added to each link, wherein the tag is used to characterize the fault status of the link corresponding to the terminal node; and Based on the device nodes at each layer and the links between them, an initial directed acyclic graph is constructed corresponding to various link failure states in the preset failure scenario.

3. The distributed data plane verification method based on fault scenarios according to claim 2, characterized in that, Also includes: When at least one of the links is in a link failure state, resulting in no valid link between the ingress device node and the destination node, the link failure state of at least one of the links is set as a specific failure scenario, and the specific failure scenario is fed back to the verification planner, wherein the specific failure scenario causes the network to fail to meet the reachability requirements.

4. The distributed data plane verification method based on fault scenarios according to claim 1, characterized in that, The step of cleaning each device node in the initial directed acyclic graph, removing redundant device nodes, to generate a directed acyclic graph containing all valid paths in the preset fault scenario includes: Delete the link that does not contain the specified tag set; Delete the device node that is not connected to the link; and Multiple device nodes with the same attribute symbol, both being terminal nodes or not being terminal nodes, and having the same adjacent next-level device nodes are merged to remove redundant device nodes.

5. The distributed data plane verification method based on fault scenarios according to claim 1, characterized in that, The step of decomposing the counting task into subtasks and assigning them to each device node, so that the verifiers on each device node perform counting based on the subtasks, includes: Initialize each of the aforementioned device nodes; Control each of the device nodes to synchronously update messages between each adjacent device node along the reverse path of the directed acyclic graph, wherein the update messages include expected connections, withdrawn data packet space, and newly added counting results; Based on the update message and the distributed verification protocol, the device nodes adjacent to each of the device nodes are counted, wherein the distributed verification protocol is used to regulate data sharing between the verifiers on each of the device nodes and their adjacent device nodes.

6. The distributed data plane verification method based on fault scenarios according to claim 1, characterized in that, The process of retrieving each device node in the valid path and recounting them based on the subtask, using the result of the recount as the data plane verification result, includes: Each device node in the valid path is retrieved and the subtask is executed to recount based on the distributed verification protocol, wherein the distributed verification protocol is used to standardize the data sharing process between the verifier on each device node and its adjacent device nodes. The recount result is synchronized to each of the adjacent device nodes along the reverse path of the effective path. Each device node adjacent to the aforementioned device node recounts based on the result of the recount; and The entry device node in the valid path receives the result of the recount and uses the result of the recount as the data plane verification result.

7. The distributed data plane verification method based on fault scenarios according to claim 1, characterized in that, Also includes: In response to the judgment result that the actual faulty link does not match the preset fault scenario, the actual faulty link is reported to the verification planner.

8. The distributed data plane verification method based on fault scenarios according to claim 1, characterized in that, Also includes: A requirements specification language is defined to control the representation of the data plane verification requirements as tuples consisting of data packet space, ingress device node set, and behavior. The tuple also includes a fault tolerance field. Wherein, when each data packet in the data packet space enters the network from any of the device nodes in the set of ingress device nodes, any path of the data packet satisfies the context specified in the behavior, wherein the behavior is specified as a tuple of regular expressions for valid paths and matching operators.

9. A distributed data plane verification system based on fault scenarios, characterized in that, include: The verification planner is configured to generate a directed acyclic graph containing all valid paths in the preset fault scenarios based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in preset fault scenarios; it is also configured to assign subtasks decomposed from the counting task to each device node; and it is also configured to, in response to the judgment result that the actual faulty link matches the preset fault scenario, retrieve valid paths corresponding to the actual link fault state from the directed acyclic graph and flood the actual faulty link. as well as Multiple validators, each of which is deployed on each of the device nodes in the network, count based on the subtask; It is also used to recount based on the subtask when the actual faulty link occurs, and to use the result of the recount as the data plane verification result; The step of generating a directed acyclic graph containing all valid paths in the preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario includes: generating an initial directed acyclic graph corresponding to the preset fault scenario based on data plane verification requirements, network topology, network protocol prefixes of device nodes, and various link fault states in the preset fault scenario. The process involves traversing each device node in the initial directed acyclic graph toward the entry device node, adding new labels to each of the traversed links, and taking the union of the new labels with the existing old labels in the links to obtain the label set for each link; and cleaning each device node in the initial directed acyclic graph to remove redundant device nodes, thereby generating a directed acyclic graph containing all valid paths in the preset fault scenario.

Images