Method and system for network validation using a hierarchy-based model

Abstract

Methods and systems for network verification are described. An input binary decision diagram (BDD) is defined to represent an input header space for querying a network property of interest. The input BDD is provided as input to a device-level BDD representing a source device in a logical topology representing connections between devices in the network. Each device in the network is represented by a respective device-level BDD in the logical topology. An output BDD is computed, the output BDD representing an output header space output by a destination device in the logical topology. The output BDD is computed by sequentially applying each device-level BDD in a logical path from the source device to the destination device to the input BDD. The output BDD is then reported and the reported output BDD is compared to an expected output BDD to verify the network property of interest.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Non-Provisional Application No. 17 / 080,112, filed October 26, 2020, entitled “METHODS AND SYSTEMS FOR NETWORK VERIFICATION USING HIERARCHY-BASED MODEL,” the contents of which are incorporated herein by reference to the extent permitted by law. TECHNICAL FIELD

[0003] The present invention relates to methods and systems for network verification, including methods and systems for network verification using hierarchy-based models and binary decision diagrams. BACKGROUND

[0004] As networks and network devices become more complex in their operation, it is increasingly difficult for network operators to ensure that network configurations and policies are designed and installed as intended. Moreover, given the scale of many existing networks, the use of traditional network testing tools (e.g., simple network management protocol (SNMP), or trace tools such as tracert or ping) limits the coverage of the network. Additionally, these network trace techniques are used to diagnose problems reactively after they occur.

[0005] To address some of the complexities and limitations mentioned above, it has been considered to use formal verification techniques previously used in software and chip design for verification of networks. The term “formal” refers to the use of mathematical models and computations to verify network configurations, as opposed to tracing the network by sending actual data packets. In the context of the present invention, formal network verification can be referred to simply as network verification. Network verification enables proactive and predictive identification of troublesome problems. However, practical application of network verification still faces challenges in scalability and real-time verification.

[0006] Generally, in network verification, a network to be verified is modeled using mathematical techniques, and then desired invariants of the network are checked in the model to specify the correct behavior of the network. Examples of existing network verification techniques can be classified into four categories, including model checking, theorem proving, Boolean satisfiability (SAT) / satisfiability modulo theory (SMT) solvers, symbolic execution, and symbolic simulation. However, these existing techniques suffer from drawbacks such as slow execution, limited application, or requiring excessive computational power.

[0007] Thus, improved techniques for network verification are needed. SUMMARY

[0008] In various examples, the disclosure describes methods and systems for network verification that help address some of the shortcomings of existing network verification techniques.

[0009] In the disclosed methods and systems, all network entities residing in a network device are considered in an aggregated model of the network device. This approach can help reduce or eliminate the problem of state explosion (the problem of the size of the system state space growing exponentially with the number of state variables).

[0010] The disclosed methods and systems also use a hierarchy-based model for verification, each hierarchy providing information at a different level of granularity. If a problem is detected when processing a higher-level model, the location of the fault can be specified by performing another processing in a smaller scope at a lower level of the model. This approach enables more specific localization of the source of the detected problem.

[0011] In some example aspects, the disclosure describes a method for verifying a network. The method includes providing an input binary decision diagram (BDD) as an input to a device-level BDD representing a source device in a logical topology representing connections between devices in the network, the input BDD representing an input header space for querying a network property of interest, each device in the network represented by a respective device-level BDD in the logical topology; computing an output BDD representing an output header space output by a destination device in the logical topology, wherein the output BDD is computed by sequentially applying each device-level BDD in a logical path from the source device to the destination device to the input BDD; reporting the output BDD; and comparing the reported output BDD to an expected output BDD to verify the network property of interest.

[0012] In any of the above examples, each device can be represented by a respective hierarchy-based model. The hierarchy-based model can include a device level corresponding to the respective device-level BDD, the hierarchy-based model can further include at least another hierarchy level lower than the device level, the at least another hierarchy level corresponding to one or more lower-level BDDs representing a respective one or more lower-level model entities of the respective device.

[0013] In any of the above examples, the one or more model entities can comprise one or more network entities (NEs) that reside on the respective device, and each NE can be represented by a respective NE-level BDD at an NE level that is lower than the device level in the hierarchy-based model.

[0014] In any of the above examples, the hierarchy-based model can further comprise a rule level that is lower than the NE level in the hierarchy-based model, the rule level corresponding to one or more rule-level BDDs that represent respective one or more rules implemented by the one or more NEs.

[0015] In any of the above examples, each lower-level BDD can be conjugated with a respective index variable that indicates a logical order of respective model entities in a logical path from an ingress to an egress of the respective device.

[0016] In any of the above examples, the method can comprise detecting a fault in the network at a device identified as faulty based on the reported output BDD, and performing lower-level validation using the hierarchy-based model representing the identified faulty device by: providing the input BDD as an input to one or more lower-level BDDs in the hierarchy-based model; computing an output BDD from each lower-level BDD; and identifying a faulty lower-level model entity of the identified faulty device from the computed output BDDs.

[0017] In any of the above examples, the lower-level validation can be repeated for each descending level of the hierarchy-based model.

[0018] In any of the above examples, the method can comprise generating a device-level BDD for a given device by: collecting data on device states and device configurations, the collected data including data on one or more model entities implemented by the given device; modeling each model entity as a respective Boolean function and encoding the respective Boolean function as a respective BDD; logically combining individual BDDs representing the one or more model entities within the given device; and storing the logical combination as a device-level BDD representing the given device.

[0019] In any of the above examples, each device can be represented by a respective hierarchical-based model. The hierarchical-based model can include a device level corresponding to the respective device level BDD, and can further include at least another hierarchy level lower than the device level, the at least another hierarchy level corresponding to one or more lower level BDDs representing respective one or more model entities implemented by the respective device. The method can include generating a hierarchical-based model for a given device by: collecting data regarding device state and device configuration, the collected data including data regarding one or more lower level model entities implemented by the given device; modeling each model entity corresponding to a lowest level of the hierarchical-based model as a respective Boolean function, and encoding the respective Boolean function as a respective BDD; for a given hierarchy level, generating a BDD for each incremental level of the hierarchical-based model by: generating a BDD representing a given model entity at the given hierarchy level by logically combining BDDs representing one or more lower level model entities implemented by the given model entity, the one or more lower level model entities belonging to a lower hierarchy level immediately below the given hierarchy level, each BDD representing a respective lower level model entity being conjugated with a respective index variable indicative of a logical order of the respective lower level model entity implemented by the given model entity; and storing the BDDs for each hierarchy level.

[0020] In some example aspects, the disclosure describes a computing system for verifying a network. The computing system includes: a processor device; and a memory storing instructions. The instructions, when executed by the processor device, cause the computing system to: provide an input binary decision diagram (BDD) as input to a device level BDD representing a source device in a logical topology, the logical topology representing connections between devices in the network, the input BDD representing an input header space for querying a network property of interest, each device in the network represented by a respective device level BDD in the logical topology; compute an output BDD representing an output header space output by a destination device in the logical topology, wherein the output BDD is computed by sequentially applying each device level BDD in a logical path from the source device to the destination device to the input BDD; report the output BDD; and compare the reported output BDD to an expected output BDD to verify the network property of interest.

[0021] In any of the above examples, the instructions can cause the computing system to perform any of the above example methods.

[0022] In some example aspects, the disclosure describes a computer-readable medium storing instructions. The instructions, when executed by a processor device of a computing system, cause the computing system to: provide an input binary decision diagram (BDD) as input to a device-level BDD representing a source device in a logical topology, the logical topology representing connections between devices in a network, the input BDD representing an input header space for querying a network property of interest, each device in the network represented by a respective device-level BDD in the logical topology; compute an output BDD representing an output header space output by a destination device in the logical topology, wherein the output BDD is computed by sequentially applying each device-level BDD in a logical path from the source device to the destination device to the input BDD; report the output BDD; and compare the reported output BDD to an expected output BDD to verify the network property of interest.

[0023] In any of the example computer-readable media, the instructions can further cause the computing system to perform any of the example methods described above. BRIEF DESCRIPTION OF DRAWINGS

[0024] Reference will now be made to the drawings to describe, by way of example, example embodiments of the application. In this regard, the drawings represent example embodiments of the application, an appreciation of which can be gained from a reading of this disclosure, both of which are illustrative of embodiments of the application:

[0025] Figure 1 An example verification architecture that can be used to implement examples of the application is shown;

[0026] Figure 2 is a block diagram illustrating a simplified example of a computing system that can be used to implement examples of the application;

[0027] Figure 3 is a flow diagram illustrating an example method for network verification according to examples described herein;

[0028] Figure 4 An example implementation of the method in Figure 3 is shown;

[0029] Figure 5 is a flow diagram illustrating an example method for generating a BDD model according to examples described herein;

[0030] Figure 6 An example implementation of the method in Figure 5 is shown;

[0031] Figure 7 is a flow diagram illustrating an example method for generating a hierarchy-based model according to examples described herein;

[0032] Figure 8 An example implementation of the method in Figure 7 is shown.

[0033] Figure 9 is a flowchart showing an example method of network verification using a hierarchy-based model according to examples described herein; and

[0034] Figure 10 An example implementation of the method in Figure 9 is shown.

[0035] Similar reference characters can be used in different drawings to represent similar components. DETAILED DESCRIPTION

[0036] As used herein, the term“computer network” refers to a group of computing devices or electronic communication devices that communicate with one another using one or more standardized digital communication protocols. The communication can occur over any type of wired or wireless digital communication link or combination thereof. The devices can be routers, switches, computers such as servers or personal computers, mobile devices such as smartphones, internet of thing (IoT) devices, or any other device capable of sending, receiving, and / or routing communications over a digital communication network. Although some examples are described herein with reference to computer networks, it should be understood that the methods, systems, and media described herein can be applicable to systems other than computer networks that can be represented using Boolean functions or binary decision diagrams (BDDs) to represent system states.

[0037] As used herein, the term“network entity (NE)” refers to a data structure or set of rules applied by a device in a computer network to determine how to process a communication in the network based on the values of various data fields (also referred to simply as“fields”) present in the communication. Thus, an NE can be represented as a table that can be used to determine whether the values of the fields of a communication (e.g., a digital data packet) satisfy various criteria and, thereby, determine how to process the communication (e.g., forward to a particular device or port, transform, accept, or reject). NEs can include access control lists (ACLs), MAC address tables, IP address tables, NAT tables, etc. It should be understood that any set of rules used by a switch, router, or other network device to determine the processing of a data packet and, thus, potentially affect how a given communication is handled by the network, can potentially be represented as an NE.

[0038] As used herein, a "field" refers to a data field. A communication (e.g., a data packet) can specify a value for one or more fields, and a NE can specify one or more values or value ranges for a field as part of the rules that determine processing of the communication. Examples of common fields used in computer networks include IP addresses, MAC addresses, and port numbers.

[0039] To help understand the present invention, some known verification tools and their shortcomings are first discussed.

[0040] One network verification tool is the open source network analysis tool Batfish. This tool simulates the control plane to obtain forwarding rules (FIB). As a result, the execution of this tool tends to be very slow, e.g., requiring several hours to verify a relatively small network. Another existing network verification tool is Minesweeper. Since this tool is designed based on satisfiability module theory (SMT), it cannot provide more than one counterexample when a violation occurs. Another existing network verification tool is Veriflow, which is an enhanced version of another tool called Anteater. Veriflow extracts equivalence classes for the entire network, however, for networks composed of different segments controlled in different administrative domains, it can be difficult or impossible to perform such a task. Moreover, computing equivalence classes can be challenging or resource intensive for large scale networks. NetPlumber is another existing verification tool that employs a similar approach as Veriflow. NetPlumber only verifies the parts of the network that are affected by changes in network rules, rather than the entire network.

[0041] Another existing network verification tool is called Hassel-C (or HSA). This tool encodes the packet header into a subset of a geometric space. A drawback of this approach is that HSA suffers from state space explosion in cases where the number of bits required for the header space is large. Network optimized datalog (NOD) is another existing verification tool that is similar to HSS, but uses a different encoding technique. NOD is reportedly slow in performance.

[0042] Some conventional network verification tools use a model checking approach. In model checking, a single large model is constructed for the entire network, e.g., even the location of a packet is represented in a finite state machine (FSM) embedded in the single network model. The benefit of the conventional model checking approach is that the computation is fast because only one model needs to be considered for the entire network. However, the drawback is the lack of detailed information about the location or cause of a fault detected in the network. An example of a model checking approach is FlowChecker. FlowChecker uses model checking to verify the correctness of an OpenFlow network. However, FlowChecker was found to have scalability issues and can be limited to practical applications in relatively small networks.

[0043] Some conventional network verification tools use a symbolic execution or symbolic simulation approach. For example, HSA is based on symbolic execution. In symbolic execution, all possible executions of a system are determined by inputting different possible values of symbolic variables into the system and evaluating the resulting output of the system. Symbolic simulation uses a similar technique but is applied to a simulation model of the system rather than a real-world system. The symbolic simulation approach provides any desired level of detail for simulating network execution, however there is a state space explosion problem when the network is large and / or the network is modeled at a high level of detail.

[0044] The present disclosure describes methods and systems that help reduce the state space explosion problem without losing information about the source of a fault in a network. The disclosed methods and systems can provide the benefits of both model checking and symbolic execution without suffering all of the drawbacks of such approaches.

[0045] In the disclosed methods and systems, a verification model represents individual NEs. In the verification process disclosed herein, the header space is treated as a symbolic variable (based on the approach used in symbolic simulation) and the variable is passed through a path in the network. The network can be modeled without losing any verification context and without having to construct a large model that can cause the state space explosion problem. Thus, the disclosed methods and systems can increase the scalability for verifying large networks.

[0046] The disclosed methods and systems can also enable more precise localization of the source of a fault. Some existing verification techniques verify the network as a whole or at best provide counterexamples in which a desired invariant does not hold. However, the context embedded in the counterexamples is often not sufficient to precisely locate the source of the problem. The disclosed methods and systems utilize a hierarchical model and use a multi-scan verification process that enables more precise identification of the source of a fault in a network.

[0047] Figure 1 A simple example of a verification architecture 100 that can be used to implement the examples described herein is shown. The disclosed verification architecture 100 includes a network verification domain (NVD) 110, a verification service (VS) 130, and device models (DMs) 122 in a logical domain 120 generated by the VS 130.

[0048] The NVD 110 refers to the actual network to be verified and contains all the network devices to be verified as part of the network. The network devices 112 within the NVD 110 can be any device that participates in the transfer of packets in the network. For example, each network device 112 can independently be one of a router, a switch, a gateway, or any other network-enabled device, among other possible devices. Typically, the behavior of the network is modeled based on the network devices 112 used to manage network traffic, such as routers, switches, servers, firewalls, etc.

[0049] Each network device 112 is modeled by constructing a respective DM 122. The DM 122 modeling a given network device 112 is designed to represent the functional behavior of the network device 112 according to the verification requirements. For example, for data plane verification, each DM 122 represents the behavior of the corresponding network device 112 in the data plane. On the other hand, for control mechanism verification, each DM 122 represents the behavior of the corresponding network device 112 in running routing protocols and routing policies. Each DM 122 is represented as a Boolean function that is encoded as a BDD, such as a reduced ordered BDD (ROBDD). It should be understood that references to BDDs in this disclosure can be more specifically references to ROBDDs.

[0050] BDDs are data structures used to represent Boolean functions. A BDD can be represented as a binary decision tree containing a top node, below which are one or more binary decision subtrees that recursively follow the same pattern. BDDs can be used to model decisions made by a corresponding network device 112 with respect to a particular communication over a network in the NVD 110 (i.e., modeling the network device 112 by the DM 122, which in turn is represented by a Boolean function encoded as a BDD). For example, a digital data packet sent in the NVD 110 can include one or more fields (e.g., internet protocol (IP) address, port number, and media access control (MAC) address) that are used by the network device 112 to decide how to handle the packet (e.g., forward to a particular other device, deny, grant access). The network device 112 can use one or more NEs (e.g., access control lists (ACLs), MAC address tables, network address translation (NAT) tables, forwarding information bases (FIBs), routing policies, protocol configurations, etc.) hosted on the network device 112 to make this decision. Each NE can be represented by a Boolean function, which can be modeled using a corresponding BDD. As will be further described below, the network device 112 can be modeled based on the BDDs of the NEs hosted on the network device 112.

[0051] A ROBDD is a reduced form of a BDD in which any isomorphic subgraphs are merged and any nodes with two isomorphic child nodes are removed. A ROBDD is a unique representation of a Boolean function. Typically, common usage of the term BDD refers specifically to a ROBDD.

[0052] The VS 130 performs operations for collecting data from the network devices 112, generating a validation model, and performing network validation. Additional details regarding the operations of the VS 130 will be further discussed below.

[0053] Figure 2 is a block diagram illustrating a simplified example of a computing system 220 (e.g., a server, computer, or cloud computing platform) suitable for implementing examples described herein. For example, the VS 130 can be implemented using the computing system 220. Other examples suitable for implementing the embodiments described in this disclosure can be used, including components other than those described below. While specific configurations have been Figure 2 A single instance of each component is shown, but multiple instances of each component can be present in the computing system 220.

[0054] The computing system 220 can include one or more processor devices 225, such as a processor, microprocessor, digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), dedicated logic circuitry, dedicated artificial intelligence processor unit, or a combination thereof. The computing system 220 can also include one or more optional input / output (I / O) interfaces 232 that can enable interfacing with one or more optional input devices 234 and / or optional output devices 236.

[0055] In the illustrated example, the input devices 234 (e.g., a keyboard, mouse, microphone, touchscreen, and / or keypad) and the output devices 236 (e.g., a display, speaker, and / or printer) are shown as being optional and external to the system 220. In other examples, there can be no input devices 234 and output devices 236, in which case the one or more I / O interfaces 232 can not be needed.

[0056] The computing system 220 can include one or more network interfaces 222 for wired or wireless communication with one or more devices or systems in a network, such as the network devices 112 in the NVD 110 modeled by the methods described herein. The network interfaces 222 can include wired links (e.g., Ethernet cables) and / or wireless links (e.g., one or more antennas) for intra-network and / or inter-network communication.

[0057] The computing system 220 can also include one or more storage units 224, which can include mass storage units such as solid state drives, hard disk drives, disk drives, and / or optical disk drives.

[0058] The computing system 220 can include one or more memories 228, which can include volatile or non-volatile memory (e.g., flash memory, random access memory (RAM), and / or read-only memory (ROM)). The non-transitory memory 228 can store instructions 238 for execution by the processor device 225 to, for example, perform examples described in the present disclosure. In some examples, the memory 228 can include software instructions 238 for execution by the processor device 225 to implement model generation and network verification disclosed herein. The software instructions 238 can also include other instructions to, for example, implement an operating system and other applications / functions.

[0059] The non-transitory memory 228 can also store generated verification models 244. The stored verification models 244 can include the DM 122 as well as models at different levels of granularity (e.g., a model of the entire network and / or models of individual NEs). In some examples, portions or all of the verification models 244 can be stored in external memory (e.g., an external database, or cloud-based storage) accessible by the computing system 220, e.g., where the verification models 244 require storage.

[0060] In some examples, the computing system 220 can additionally or alternatively execute instructions from external memory (e.g., an external drive in wired or wireless communication with the computing system 220), or can be provided executable instructions by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer-readable media include RAM, ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, CD-ROM, or other portable storage device.

[0061] It will be appreciated that, in some implementations, various components and operations described herein can be implemented on multiple separate devices or systems.

[0062] Referring again to Figure 1When network verification is first enabled, the NVD 110 and desired one or more verification invariants can be defined in the VS 130. The VS 130 can first collect data from all network devices 112 in the NVD 110 in order to build the DM 122 for all network devices 112. Each network device 112 can first register itself with the VS 130. Then, based on the defined NVD 110 and desired verification invariants, the VS 130 collects all relevant device states and device configurations from all network devices 112 that belong to the NVD 110 (as defined in the NVD definition). This phase can be referred to as a data collection phase. Data collection can be initially triggered by the VS 130 when network verification is initialized. Subsequently, each network device 112 registered on the VS 130 can unilaterally send unsolicited data to the VS 130. For example, a network device 112 can send data to the VS 130 if there has been any change in device state or configuration.

[0063] After sufficient data is collected from the network devices 112, the VS 130 builds the DM for all network devices 112. More details of model generation will be further described below. As shown in FIG. 1, the VS 130 creates a logical topology between the DMs 122 in the logical domain 120 based on the defined verification invariants. It is noted that the logical topology in the logical domain 120 does not necessarily match the physical topology between the network devices 112 in the NVD 110. For example, if the verification invariants are about reachability (the ability of each network device to receive communications such as packets) on an overlay network on the physical network, the logical topology can be generated by the VS 130 based on connections (or tunnels) between the network devices 112 on the overlay network. After the logical topology and the DMs 122 are generated, the VS 130 can perform verification of the network. Figure 1

[0064] ​In formal verification, each DM 122 is generated based on the configuration and state of the corresponding network device 112. In particular, the DM 122 is generated to represent how the corresponding network device 112 behaves with respect to a particular network property to be verified, as discussed further below. Verification is then performed by inputting a header space into the source DM 122, computing an output header space at the destination DM 122, and determining whether the desired verification property is satisfied. Some network properties that can be verified using the DMs 122 include reachability (e.g., whether there are any network devices 112 that packets cannot reach), loop detection (e.g., whether there are any packets that end up back at the source device 112), existence of black holes (e.g., whether there are any devices 112 that drop packets), route detection (e.g., to trace a route from a source device 112 to a destination device 112), and security vulnerabilities (e.g., whether a firewall provided by a network device 112 is operating correctly), among others. The DMs 122 can be generated only for network devices 112 (and network entities within the network devices 112) that are relevant to the network property of interest.

[0065] Header space is a technique used to model packets that are transmitted in a network. First, it should be understood that processing of packets in a network primarily involves information contained in the packet header, rather than the payload. Each network device 112 processes a packet by processing header fields that are encoded as a sequence of binary values (i.e., a sequence of "1" or "0" header bits). Thus, for verification purposes, a packet can be modeled as a packet header that is a point in the [0, 1, *] L space, where L is the length of the packet header, and * is a "wildcard" value that can be either "1" or "0". Thus, the header space is the space of all possible packet headers of length L, and is used to represent a set of possible packets rather than a single packet.

[0066] As the input header space traverses the logical path from the source DM 122 to the destination DM 122, each model encountered by the header space applies a Boolean function to the header space, which represents how the corresponding NE processes the header space (e.g., if the network is being verified for a reachability property, then which output port to send to). The output header space can then be used to verify whether the desired verification property is satisfied, using header space computation (which is well-known and not described in detail here).

[0067] An example of the verification process performed by the VS 130 is first described with reference to Figure 3 and Figure 4

[0068] Figure 3 ​is a flowchart illustrating an example method 300 for network verification performed by the VS 130 (e.g., implemented by the computing system 220 through execution of the instructions 238 by the processor device 225).

[0069] At 302, a header space is defined by the VS 130. The header space serves as an input for performing verification and can be considered a symbolic variable. The VS 130 can generate the header space by detecting the configuration of the network devices 112 that interface with other entities outside of the NVD 110 (e.g., entities that interface with devices that are not part of the network being verified). The header space can be defined using information extracted from the configuration or state of each network device 112 (e.g., based on device configuration data such as whether there is a locally attached LAN, static routes, etc.). For example, if a given network device 112 is (or includes) a border router that interfaces with other entities outside of the NVD 110 and the given network device 112 has an IP address of 192.168.10.10 / 24, then the VS 130 can define the header space as a symbolic variable representing the space of all possible packet headers that will be received at that IP address. In this particular example, the header space can be defined as (11000000, 10101000, 00001010, ********), which is the binary representation of 192.168.10.**** (where * is a wildcard that can be any binary value). In some examples, the header space can be configured by an operator of the VS 130.

[0070] At 304, the VS 130 defines a set of one or more queries in accordance with the network properties of interest to be verified. For example, if the network properties of interest are the reachability of all interfaces that connect the NVD 110 to entities outside of the NVD 110, then the VS 130 can first identify and obtain configuration information for all border devices 112 in the NVD 110 that interface with entities outside of the NVD 110, and then define queries in the form of header spaces based on source DMs 122 and destination DMs 122, where each source-destination DM pair represents a pair of border devices 112. It should be appreciated that other such queries can be defined for verifying other network properties of interest. Each query is defined as a header space. Since the header space is a multi-dimensional space with binary values in each dimension, the defined header space is represented as a BDD.

[0071] At 306, for each query, the VS 130 inputs (or provides) to the source DM 122 designated as the starting point of the query a BDD representing the corresponding input header space (also referred to as an input BDD). In the present disclosure, providing the input BDD to the source DM 122 can be understood to mean supplying the input BDD to the source DM 122.

[0072] At 308, the VS 130 computes the output header space by sequentially applying each device’s DM 122 to the input BDD along the path (in the logical topology of the logical domain 120) from the source DM 122 to the destination DM 122. It is noted that there can be multiple paths from the source DM 122 to the destination DM 122 in the logical topology, and thus there can be multiple output header spaces.

[0073] Each DM 122 is a Boolean function, represented by a BDD (referred to as a DM BDD). The DM BDD models how the corresponding network device 112 processes a received packet, e.g., by forwarding the packet via a particular output port, or by blocking the packet (also referred to as dropping the packet). For a given DM 122 along the logical path, the VS 130 computes the output header space (represented by an output BDD) by applying the given DM 122 to the header space input at the given DM 122 (it is noted that the header space input at the given DM 122 can be the output header space from a preceding DM 122 along the logical path). Since both the DM 122 and the input header space are represented by BDDs, applying the DM 122 to the header space is equivalent to conjoining the input BDD with the DM BDD. That is, a logical AND operation is performed between the input BDD and the DM BDD, mathematically represented as follows:

[0074] Output BDD = (Input BDD) Λ (DM BDD)

[0075] where Λ denotes the logical AND operation.

[0076] In this manner, each DM BDD along the logical path from the source model to the destination model is sequentially applied to the input BDD. It is noted that the input BDD traverses only one DM BDD at a time. After the VS 130 computes the output BDD for a given DM BDD (e.g., using the computation described above), the memory resources of the VS 130 can be repurposed for the next DM BDD encountered in the logical path.

[0077] At 310, the final output header space output from the destination DM 122 (as defined by the query) is reported as the reachable header space for the query. The output header space can be reported in the form of an output BDD. It can be noted that since the header space is computed using device-level BDDs (rather than a single network-level BDD as in some conventional approaches), if the reported header space is reduced, a packet drop problem can be identified at the particular DM 122 (and thus at the corresponding particular network device 112). For example, with BDD operations, the output header space can be compared to the input header space at each DM 122 to identify whether there is any dropped header space.

[0078] Figure 4 An example implementation of the method 300 is shown in a simplified logical topology of Figure 1 The logical topology includes four DMs 122, DM-A 122A, DM-B 122B, DM-C 122C, and DM-D 122D, each represented by a respective BDD. For purposes of discussion, Figure 4 The network property verified in the example logical topology can be reachability, and the query can define DM-A 122A as the source DM and DM-D 122D as the destination DM. Other queries can be used to perform verification of other network properties of interest in a manner similar to that described below.

[0079] The input header space (denoted as HS1) is input to DM-A 122A. As Figure 4 shown, in the example logical topology shown in Figure 4 there are two logical paths (i.e., Path 1 and Path 2) between the source DM (i.e., DM-A 122A) and the destination DM (i.e., DM-D 122D). The DMs along Path 1 are DM-A 122A, DM-C 122C, and DM-D 122D, and the output header space (denoted as HS3) is computed for Path 1 as follows:

[0080] HS3 BDD = (HS1 BDD) Λ (DM-A BDD) Λ (DM-C BDD) Λ (DM-D BDD).

[0081] Thus, the HS3 BDD represents the space of all headers that reach DM-D 122D from DM-A 122A when traversing along logical Path 1. In this example, there is also a dropped header space (denoted as HS2) that represents all headers that are blocked (or dropped) by DM-C 122C.

[0082] The DMs along path 2 are DM-A 122A, DM-B 122B, and DM-D 122D, and another output header space (denoted as HS4) is computed for path 2 as follows:

[0083] HS4 BDD = (HS1 BDD) A (DM-A BDD) A (DM-B BDD) A (DM-D BDD).

[0084] HS3 BDD and HS4 BDD are reported as the union of all output header spaces for the query. VS 130 can compare the reported output header spaces with the expected output to verify the network properties of interest (e.g., to check reachability, the expected output header space is the same as the input header space; other network properties can be verified by performing other comparison procedures as appropriate). If the reported output header spaces are not as expected, this can indicate that there is a fault in the network (e.g., a device that cannot be reached). VS 130 can identify the discarded header space (i.e., HS2 in this example), and pass the discarded header space through the various DMs 122 in order to identify the source of the discard. In this example, when the discarded header space is passed through DM-C 122C, the resulting output from DM-C 122C is a reduced or empty header space, indicating that DM-C 122C is the source of the fault. By modeling the network devices 112 as individual DMs 122, VS 130 is able to more precisely identify the source of the fault.

[0085] It should be appreciated that the verification process disclosed herein has some fundamental differences in how the header spaces are encoded compared to existing HSA methods. In HSA, the packet header is encoded as a subset of a geometric space. In contrast, in the disclosed verification process, the packet header is modeled as a BDD. In cases where the number of bits required for the header space is large, HSA suffers from a state space explosion problem. In contrast, the disclosed verification process uses BDDs, which are a more compact structure for representing the header space and avoid the state space explosion problem. Furthermore, HSA is typically limited to applications in the data plane. However, the disclosed verification method can be used for both data plane applications and control plane applications. This is because VS 130 can generate different logical topologies in logical domain 120 based on the type verification. For example, for a single physical network in NVD 110, there can be several different logical topologies (e.g., one topology represents logical connections in the data plane, another topology represents logical connections in the control plane), which can be selectively used for symbolic simulation.

[0086] Reference is now made to Figure 5 and Figure 6 to describe an example of how to generate a BDD model for a given DM 122.

[0087] Figure 5 is a flowchart illustrating an exemplary method 500 that can be performed by the VS 130 (e.g., implemented by the computing system 220 through execution of the instructions 238 by the processor device 225) to generate a BDD model for each DM 122.

[0088] At 502, data is collected about device state and device configuration for all network devices 112 in the NVD 110 representing the physical network to be verified. The data can be collected for specific network properties of interest (e.g., network properties to be verified).

[0089] At 504, for each given network device 112, the VS 130 determines all NEs involved in the property of interest (e.g., ingress / egress ACLs, FIBs, routing policies, protocol configurations, etc.), and determines the corresponding NE states and configurations. For example, the VS 130 can extract information about the NE states and configurations from the data collected at step 502.

[0090] At 506, the VS 130 models each NE in each network device 112 as a respective Boolean function. For example, the Boolean function used to model a given NE can be derived from the configuration of that given NE. The Boolean function is encoded in BDD format. For example, if the network property of interest is reachability, each NE can be modeled as a Boolean transfer function between two ports, and the function is encoded in BDD format.

[0091] At 508, the models of the NEs are combined to generate a single DM 122 representing the functionality of the given network device 122 based on the logical interactions of all the NEs belonging to the given network device 112 for the network property of interest. For example, if the property of interest is reachability, the models of all the NEs in a logical path from an ingress port to an egress port of a network device 112 can be combined using a logical AND operation to generate a single port-to-port model representing the reachability between the two ports of the network device 122. Then, the DM 122 for the network device 122 can be generated by connecting all the port-to-port models with a logical OR operation. In this way, a single DM 122 can be computed for each network device 112 to enable verification of the reachability property. Other models can be similarly generated to represent the behavior of each network device 112 with respect to other network properties of interest.

[0092] At 510, the VS 130 stores the model representing all DMs 122 of all network devices 112. Thus, the stored model represents the logical behavior of all network devices 112 in the NVD 110 with respect to the network property of interest, as well as the logical behavior of all NEs within each network device 112 with respect to the network property of interest. The stored DMs 122 can then be used to verify the behavior of the network according to the property of interest as described above.

[0093] Figure 6 An example implementation of some steps of the method 500 in a simplified network device 112 is shown. Figure 6 An example is shown of how to generate a port-to-port model in the logical domain 120 for a given network device 112 in the NVD 110 to verify the reachability property of the network.

[0094] In this example, the network device 112 includes a number n of NEs 114 (indicated as Network Entity 1, Network Entity 2, through Network Entity n) in a logical path from an ingress port A 116 to an egress port B 118. Each NE 114 can independently be any of the NEs discussed herein. In particular, with respect to the reachability property, each NE 114 can independently be a set of rules or tables (e.g., routing tables) used in the network device 112 for managing the routing of packets based on information contained in the packet headers. The configuration and state of each NE 114 is collected and determined at steps 502-504 described above. From this information, at step 506, each NE 114 is modeled as a Boolean function and encoded as a corresponding BDD 124 in the logical domain 120. For example, for data plane verification, each NE 114 can be modeled as a Boolean function that applies a forwarding rule based on binary bits in the packet header representing the addresses (e.g., IP or MAC addresses) of the source and / or destination of the packet. Each NE 114 can transform a packet from one state to another or change the position of the packet in the logical path.

[0095] In the illustrated example, a respective NE-level BDD 124 (indicated as BDD NEI, BDD NE2, through BDD NEn) is generated by the VS 130 for each respective NE 114 and stored. Each NE 114-level BDD 124 is the functions that a packet can encounter along a logical path from an ingress port to an egress port. A port-to-port model between port A and port B is then generated by combining all of the NE-level BDDs 124 using a logical AND operation, which is in the form of a port-to-port BDD that represents a Boolean function for controlling the routing of packets from ingress port A 116 to egress port B 118. Mathematically, the port-to-port BDD from port A to port B (denoted as BDD AB) can be generated as follows:

[0096]

[0097] where BDD NEI through BDD NEn are the BDDs 124 representing the n NEs 114 in the logical path between ingress port A 116 and egress port B 118, and the symbol A denotes a logical AND operation.

[0098] Port-to-port models can similarly be generated for all logical paths from all possible ingress ports to all possible egress ports of the network device 112. A DM 122 for the network device 112 is then generated by combining all of the port-to-port models using a logical OR operation. The DM 122 generated for a given network device 112 can then be stored by the VS 130 and used to verify the reachability properties of the network (e.g., using the method 300 as described above).

[0099] The above-described modeling approach can be used to verify any aspect or mechanism in a physical network. Notably, in the above-described approach, each network device is modeled as a respective BDD, and the network is verified by traversing the device-level BDDs one after another, rather than using a single network-level BDD for verification. This approach can help alleviate the state explosion problem.

[0100] Additionally, after traversing a device-level BDD in the logical topology, the memory resources used to store that device-level BDD can be reused for the next device-level BDD along the logical path. Thus, the maximum size of the BDDs that need to be processed at any time (and, by extension, the amount of computational and memory resources required by the processing steps) corresponds to the most complex (e.g., having the most NEs) network device in the network. The complexity of the BDDs is limited at the device level and does not increase as the size of the network increases. This enables greater scalability, as increasing the size of the network does not result in BDDs that exceed the computational or memory resources to be processed.

[0101] As the verification is performed by traversing the network at the device level rather than as a single network level BDD, more specific information about the source of a network failure can be determined. For example, if there is a packet drop issue in the network (e.g., as indicated by the reduced header space reported as the output header space when performing the verification), the particular network device where the packet drop issue is occurring can be identified.

[0102] As described above, a logical model (represented by a NE level BDD) is generated for each NE in a given network device in order to build a logical model (represented by a device level BDD) for the given network device. In order to be able to trace a problem to a particular NE, information associating the device level BDD (corresponding to the given network device) with the NE level BDDs (corresponding to the NEs in the given network device) should also be stored. Thereby, the device level logical model for a given network device can be associated with a hierarchy of lower level models corresponding to the NEs of the given network device. This hierarchical approach to model generation can enable more specific localization of the source of a detected network failure. More generally, a hierarchical device model can be generated at any desired level of granularity in order to represent the logical behavior of a device at any desired level of detail. For example, each logical rule applied by a given NE can also be modeled by a corresponding rule level BDD and associated with the NE level BDD representing the given NE.

[0103] Thus, each hierarchy level corresponds to a different range of actions, with lower level models representing a smaller range of behavior compared to higher level models. In general, the present invention can refer to a network device, NE, or rule as a model entity that applies a logical Boolean function (representable as a BDD) to an input packet. In the present invention, the term model entity is used to refer to how a given entity at any hierarchy level (e.g., network device, NE, rule, etc.) processes a logical representation of the header space (modeled by a Boolean function). Each model entity corresponds to a respective hierarchy level and can be represented by a respective model at that hierarchy level. In general, a single higher level model can represent the overall behavior of one or more lower level models associated with that higher level model. For example, a device level model represents the overall logical behavior of a device (including all NEs within the device), while a NE level model represents the logical behavior of a single NE within a device. At a lower hierarchy level, individual logical rules implemented by a single NE can be represented by a respective rule level model.

[0104] Using the hierarchical-based modeling approach disclosed herein, different logical models are generated with different validation context information and with different granularities and ranges of actions, and these logical models are related to each other in a hierarchical manner. Validation can then be performed at different hierarchical levels to more precisely identify the source of detected faults.

[0105] Figure 7 is a flowchart illustrating an example method 700 that can be performed by the VS 130 (e.g., implemented by the computing system 220 through execution of the instructions 238 by the processor device 225) to generate a hierarchical-based BDD model for each DM 122.

[0106] At 702, data is collected about device states and device configurations for all network devices 112 in the NVD 110 representing the physical network to be validated. The data can be collected for particular network properties of interest (e.g., network properties to be validated). The data is collected for all model entities within all network devices 112 up to a desired hierarchical level (e.g., up to the NE level or the rule level). For example, the hierarchical-based model can be predefined at the VS 130 prior to or at the beginning of the method 700 to have certain desired levels.

[0107] At 704, for each given network device 112, all model entities are determined for each desired level of the hierarchical-based model, and corresponding states and configurations of these model entities are also determined. For example, if the hierarchical-based model is to be generated up to the rule level, all NEs (e.g., ingress / egress ACLs, FIBs, routing policies, protocol configurations, etc.) and logical rules involved in the properties of interest are determined by the VS 130, and corresponding states and configurations are determined. The VS 130 can extract this information from the data collected at step 702.

[0108] At 706, the VS 130 models each model entity at the lowest hierarchical level as a respective Boolean function. For example, the lowest level of the hierarchical-based model can be defined as the rules implemented by each NE. The Boolean function used to model a given rule can be derived from the configuration data. The Boolean function is encoded in the BDD format and stored as a rule-level BDD.

[0109] At 708, a model of all model entities at a higher level of the hierarchy-based model is generated by combining the lower level models. Specifically, a model representing a given model entity residing at a given level of the hierarchy is generated by combining one or more models representing respective one or more other model entities that reside within the given model entity at the given level of the hierarchy, wherein the models being combined belong to a level of the hierarchy immediately below the given level of the hierarchy (i.e., one level down in the hierarchy).

[0110] As noted above, a packet traversing a logical path from an ingress port to an egress port of a network device encounters one or more NEs that reside in the network device. It is noted that the packet encounters the NEs in a particular logical order. If the processing of the header space is performed at the device level BDD, it is not important to know the order in which each NE operates on the header space. However, if the processing of the header space is performed at the more refined NE level BDD, it is useful to identify each NE level BDD within the network device in order to enable identification of NE level faults. More generally, it is useful to identify each lower level model that resides under a higher level model in order to enable precise determination of lower level fault sources.

[0111] Accordingly, step 708 includes step 710 to include information regarding the indices of the lower level models. To include the information regarding the indices of the lower level models, a new vector of BDD variables is introduced into the BDD space to represent the indices of the lower level models, wherein the value of each index variable indicates the logical order of the corresponding lower level model within the higher level model.

[0112] At 710, each lower level model (that resides within a given higher level model) is conjoined (using a logical AND) with a corresponding index variable that (in BDD format) represents the logical order of the lower level model within the given higher level model. Thereby, the order of the lower level models within the given higher level model is encoded within the lower level BDDs.

[0113] Mathematically, a model of a given higher level model entity at level i+1 of the hierarchy-based model can be represented as M i+1 , where l is an index representing the logical order of the lower level model entities within M i+1 . A lower level model entity at level i that resides in the higher level model entity M l can be represented by a corresponding Boolean function, denoted as C i+1 , where l is an index representing the logical order of the lower level model entities within M i+1 :

[0114]

[0115] The symbol ∨ represents the logical "OR" operation. In this formula, index j is used to index all lower-level models within a given model that are at level l. Using the above formula, each lower-level C is first evaluated. j And only at higher level C l All lower-level C within j Only after being assessed as false will a higher-level C assessment be conducted. l Therefore, model M i+1 Including from model M i+1 Information on the hierarchical relationships between entities within the model, and information indicating the model M. i+1 An index of the logical order of lower-level model entities within the model.

[0116] Step 708 (including step 710) is repeated for each desired level of the hierarchical model, moving sequentially from lower to higher levels until the highest level of the hierarchical model (e.g., the device level) is reached.

[0117] At 710, VS 130 stores models representing all DM 122 of all network devices 112. The stored models include hierarchical information, including information about the order of lower-level model entities residing within higher-level model entities, and information about the hierarchical relationships between these models. For example, VS 130 may store information indicating which lower-level models were used to construct which higher-level model. The stored DM 122 can be used to verify the behavior of the network based on attributes of interest. In particular, different hierarchical levels can be traversed during verification, as discussed further below.

[0118] It is understood that method 700 includes method 500 described above. For example, method 500 can be considered an implementation of method 700, in which a hierarchical model is generated up to the NE level.

[0119] Figure 8 An exemplary implementation of step 708 in method 700 is shown. In this example, the higher-level model (at level i+1) is the device-level model (i.e., DM 122), and the lower-level model (at level i) is the NE-level model. It should be understood that this example can be extrapolated to any level of a hierarchy-based model.

[0120] like Figure 8As shown, there are n lower level models (i.e., NE level BDDs 124, denoted as BDD NE1 to BDD NEn) at level i within the higher level model (i.e., DM 122). The groupings are traversed in a defined logical order corresponding to indices 1 to n. The NE level BDDs 124 are conjoined with an index variable (e.g., a binary representation of the index variable, denoted as BDD1 to BDDn) to encode the logical order of each NE level BDD 124, resulting in NE level BDDs CI to Cn. n The NE level BDDs are then combined to obtain the higher level model M i+1 In this example, the higher level model is DM 122.

[0121] Using a hierarchy-based model, network verification can be performed at different levels of detail. Verification performed using the highest hierarchy level (e.g., at the device level) can provide an overall check of the network, reporting an overall pass or fail. A first verification scan of the network can be performed at the device level to quickly check the overall performance of the network. Device level verification can be performed as described above with respect to method 300. Since in most cases there should be no faults in the network, device level verification provides a relatively quick way to verify the network. If a fault is encountered in the device level verification, additional verification can be performed at lower hierarchy levels to identify the source of the fault. Figure 3

[0122] Figure 9 is a flowchart illustrating an example method 900 of network verification using a hierarchy-based model, the method performed by VS 130 (e.g., implemented by computing system 220 through processor device 225 executing instructions 238).

[0123] At 902, verification is performed at a higher hierarchy level. For example, verification can first be performed at the highest hierarchy level, which can be at the device level. Verification can be performed similarly to method 300 described above. For example, verification can be performed by inputting (or providing) an input BDD representing an input header space to a source model (representing a source device 112 in NVD 110) at the higher hierarchy level. In the present disclosure, providing an input BDD to a source model can be understood to mean provisioning an input BDD to a source model. An output header space is then computed at the higher hierarchy level along a logical path from the source model to a destination model (representing a destination device 112 in NVD 110).

[0124] ​At 904, the BDD representing the output header space at the higher hierarchy level is reported. Using this output header space, the VS 130 determines whether there is a fault at the higher hierarchy level. If no fault is detected, the method 900 can end. If a fault is detected (e.g., the output header space is reduced or not as expected), the method 900 proceeds to step 906.

[0125] At 906, the header space BDD is passed through higher level BDDs representing each model entity at the higher hierarchy level, and the output header space is reported for each higher level BDD. The higher level BDDs that are faulty are identified (e.g., by identifying the higher level BDDs for which the output is reduced or empty header space).

[0126] At 908, a verification is performed on the identified faulty BDDs. This second verification is performed using the lower level BDDs that make up the faulty higher level BDDs. In some examples, this lower level verification can be performed similarly to the higher level verification. For example, the dropped BDD representing the dropped header space is input to the source model at the lower hierarchy level. Then, the output BDD representing the output header space is calculated at this lower hierarchy level along the logical path from the source model to the destination model. In some examples, the lower level verification can be performed only for the identified faulty BDDs, and all other BDDs along the logical path can remain at the higher level representation. That is, in addition to the identified faulty BDDs, the higher level BDDs can be used to traverse the logical path, with the faulty BDDs being replaced by the lower level BDDs at the next lower hierarchy level that make up the faulty BDDs. Similar to the process described above, the output from each lower level BDD can be reported. In some examples, the lower level verification can be performed only for the portion of the logical path that is specific to the identified faulty BDDs, rather than for the complete logical path from the source model to the destination model. For example, the header space can be input directly to the set of lower level BDDs that make up the identified faulty BDDs, and the output from each lower level BDD is reported accordingly.

[0127] At 910, the output BDD representing the output header space is reported for each lower level BDD. If the output BDD from a given model is empty, this indicates that the given model is the source of the fault. Since each lower level BDD is encoded with a respective index representing the logical order of the lower level BDD within the higher level BDD, the VS 130 uses this report to obtain the index of the lower level BDD that is the source of the fault. Thus, the VS 130 is able to identify the faulty lower level BDD within the faulty higher level BDD.

[0128] Steps 908 through 910 can be repeated for a third (or more) verification at each hierarchical level of the hierarchy until a desired level of granularity is reached (or until the lowest level of the hierarchy-based model is reached). For example, a first verification can be performed at the device level to identify a faulty DM 122, a second verification can be performed at the NE level to identify a faulty NE-level BDD 124 within the faulty DM 122, and a third verification can be performed to identify a faulty rule-level BDD within the faulty NE-level BDD 124.

[0129] Thus, the VS 130 can identify the source of the detected fault up to any desired level of granularity.

[0130] Figure 10 An example implementation of the method 900 is shown. In the simplified logical topology shown, there are three DMs 122 in a single logical path, each represented by a respective BDD (denoted as BDD_DM1, BDD_DM2, BDD_DM3). In this hierarchy-based model, the device level is the highest hierarchy level, followed by the NE level as the next lower hierarchy level, and the rule level is the lowest hierarchy level. For purposes of discussion, in this example, the network properties verified in the first verification are reachability, and the input header space is generated for a query that starts with BDD_DM1 as the source model and BDD_DM3 as the destination model. Other queries can be used to perform verification of other network properties of interest in a manner similar to that described below. Figure 10 The network properties verified in the first verification can be reachability, and the input header space is generated for a query that starts with BDD_DM1 as the source model and BDD_DM3 as the destination model. Other queries can be used to perform verification of other network properties of interest in a manner similar to that described below.

[0131] Verification is performed starting with a first verification performed at the highest hierarchy level (i.e., the device level in this example). In the first verification, the input header space is input to BDD_DM1, and the output header space is reported after the input header space passes through BDD_DM2 and finally reaches BDD_DM3. In this example, a dropped header space is reported for BDD_DM2, indicating that BDD_DM2 is the source of the detected fault in the network.

[0132] To more precisely identify the source of the detected fault, the identified faulty higher-level BDD (BDD_DM2 in this case) is replaced with a more refined lower-level BDD (i.e., the NE-level BDD 124). In a second verification, the VS 130 inputs the dropped header space and obtains the index of the NE-level BDD (BDD_NE3 in this example) that is the source of the fault.

[0133] For the third verification, the method is repeated, replacing the faulty NE-level BDD with the next lower level BDD (i.e., the rule-level BDD 126) in the third verification. The discarded header space is input by the VS 130 and the index of the rule-level BDD that was the source of the fault (BDD_Rule2 in this example) is obtained.

[0134] This example illustrates how the VS 130 can use multiple verification scans of models at different hierarchy levels to more precisely locate the source of a detected fault. Using a hierarchy-based approach to verification enables more detailed information to be obtained (using lower level models) to more precisely locate the source of a fault, and also enables overall verification of the network to be performed more quickly (using higher level models) in the absence of a fault. Furthermore, as previously mentioned, using device-level models for network-level verification helps to avoid the problem of state explosion. Thus, a hierarchy-based approach can enable more efficient network verification and more precise fault localization.

[0135] It can be noted that, in some examples, instead of preparing a logical model (e.g., using collected state and configuration data) to represent all devices and network entities, various techniques known in the art can be utilized to derive a more detailed model using collected statistical data of previous faults and / or ranges of known changes in the network (e.g., see Steffen et al., Probabilistic verification of network configurations”, SIGCOMM’20). This can enable the logical model to be generated to focus on only certain aspects of interest (e.g., only on functions known to be prone to faults and / or known to have been changed), rather than generating a fully detailed model for all devices and entities. Such an approach can reduce the resources required for model generation (e.g., required memory and / or required computation time).

[0136] Although the present application has described examples in which the highest hierarchy level in the hierarchy-based model is the single device level (i.e., a single DM represents a single network device), the present application can also be applied to abstracting portions of a network that contain multiple network devices. That is, the hierarchy-based model can include hierarchy levels above the single device level. For example, there can be a hierarchy level that represents groups of devices as a single logical model.

[0137] Methods for network verification are described in which a network can be verified by dynamically traversing a logical model (e.g., represented by a BDD) representing network devices one by one instead of traversing an aggregated model representing the entire network. Such methods can help alleviate the state explosion problem of model checking. After traversing each device-level BDD, the verification service can reset the BDD, re-use memory resources for processing the next device-level BDD. Moreover, the maximum BDD that needs to be processed is limited at the device level, instead of increasing as the network size increases. Thus, the disclosed methods can achieve better scalability compared to conventional verification methods.

[0138] In various examples, the present disclosure describes a hierarchy-based approach for network verification in which the approach can more accurately identify the source of detected network faults compared to conventional verification methods, which typically use a single network-level verification scan.

[0139] The present disclosure can be applicable to verification of any type of network including wired and wireless networks and any individual mechanism in a network domain.

[0140] Although the present disclosure describes methods and processes with steps in a particular order, one or more steps of the methods and processes can be omitted, or can be changed or modified appropriately. One or more steps can be performed in an order different from that described, where appropriate.

[0141] Although the present disclosure is described in terms of methods, one of ordinary skill in the art will appreciate that the present disclosure is also directed to various components for performing at least some aspects and features of the methods, whether by hardware components, software, or any combination of the two. Accordingly, the technical solutions of the present disclosure can be embodied in the form of a software product. The appropriate software product can be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer-readable medium, including, for example, a DVD, a CD-ROM, a USB flash drive, a removable hard disk, or other storage medium. The software product includes instructions tangibly stored thereon, which enable a processor device (e.g., a personal computer, a server, or a network device) to perform examples of the methods disclosed herein.

[0142] The present disclosure can be implemented in other specific forms without departing from the subject matter of the claims. The described exemplary implementations are to be considered in all respects as illustrative only and not restrictive. Features selected from one or more of the above-described embodiments can be combined to create alternative implementations not explicitly described, features suitable for such combinations being understood to be within the scope of the present disclosure.

[0143] All values and subranges within the disclosed ranges are also disclosed and contemplated. In addition, while the systems, devices, and processes disclosed and shown herein can include particular numbers of elements / components, the systems, devices, and processes can be modified to include more or less such elements / components. For example, while any of the elements / components disclosed can be referred to in the singular, the embodiments disclosed herein can be modified to include a plurality of such elements / components. The subject matter described herein is intended to cover and encompass all technical equivalents to the disclosed subject matter.

Claims

1. A method for verifying a network, characterized in that, The method includes: An input binary decision graph (BDD) is provided as input to the device-level BDD representing the source devices in the logical topology, which represents the connections between devices in the network. The input BDD represents the input header space for querying network attributes of interest, and each device in the network is represented by the corresponding device-level BDD in the logical topology. The output BDD representing the output header space of the destination device in the logical topology is calculated, wherein the output BDD is calculated by sequentially applying the input BDD to each device-level BDD in the logical path from the source device to the destination device; The report describes the output BDD; and The reported output BDD is compared with the expected output BDD to verify the network properties of interest and detect faults in the network, including: The discarded BDD is determined by calculating the difference between the expected output BDD and the reported output BDD, where the discarded BDD represents the discarded header space; The discarded BDD is provided as input to each individual device-level BDD, and it is determined whether the output of each individual device-level BDD is a reduced or empty header space compared to the discarded header space represented by the discarded BDD; and A faulty device represented by a specific single device-level BDD is identified as a source of fault in the network, and the faulty device is determined to output a reduced or empty header space.

2. The method according to claim 1, characterized in that, Each device is represented by a corresponding hierarchical model, which includes a device level corresponding to the corresponding device level BDD, and the hierarchical model also includes at least one other hierarchical level below the device level, which corresponds to one or more lower-level BDDs representing one or more lower-level model entities of the corresponding device.

3. The method according to claim 2, characterized in that, The one or more model entities include one or more network entities (NEs) residing on the respective devices, each NE being represented by a corresponding NE level BDD at a lower NE level than the device level in the hierarchical model.

4. The method according to claim 3, characterized in that, The hierarchical model also includes rule levels below the NE level in the hierarchical model, the rule levels corresponding to one or more rule levels BDD representing one or more rules implemented by the one or more NEs.

5. The method according to claim 2, characterized in that, Each lower-level BDD is conjugate with a corresponding index variable that indicates the logical order of the corresponding model entities in the logical path from the entry to the exit of the corresponding device.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Based on the reported output, BDD detects faults in the network at the identified faulty devices; and Lower-level verification is performed using a hierarchical model representing the identified faulty device in the following manner: Provide input BDDs as inputs to one or more lower-level BDDs in the hierarchical model; Calculate the output BDD from each lower-level BDD; and Identify the faulty lower-level model entities of the identified faulty device from the calculated output BDD.

7. The method according to claim 6, characterized in that, The lower-level validation is repeated for each descending level of the hierarchical model.

8. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Generate device-level BDDs for a given device using the following methods: Collect data on device status and device configuration, including data on one or more model entities implemented by the given device; Each model entity is modeled as a corresponding Boolean function, and the corresponding Boolean function is encoded as a corresponding BDD; Logical combinations represent the individual BDDs of one or more model entities within the given device; and The logical combination is stored as a device-level BDD representing the given device.

9. The method according to any one of claims 1 to 5, characterized in that, Each device is represented by a corresponding hierarchical model, the hierarchical model including a device level corresponding to the corresponding device-level BDD, the hierarchical model also including at least another hierarchical level below the device level, the at least another hierarchical level corresponding to one or more lower-level BDDs representing one or more model entities implemented by the corresponding device, the method further including: Generate a hierarchical model for a given device using the following methods: Collect data on device status and device configuration, including data on one or more lower-level model entities implemented by the given device; Each model entity corresponding to the lowest level of the hierarchical model is modeled as a corresponding Boolean function, and the corresponding Boolean function is encoded as a corresponding BDD; For a given hierarchical level, a BDD is generated for each incremental level of the hierarchical model in the following manner: A BDD representing a given model entity is generated by logically combining BDDs representing one or more lower-level model entities implemented by a given model entity at the given hierarchical level, wherein the one or more lower-level model entities belong to a lower hierarchical level immediately below the given hierarchical level. Wherein, each BDD representing a corresponding lower-level model entity is conjugate with a corresponding index variable indicating the logical order of the corresponding lower-level model entities implemented by the given model entity; and Store BDDs for each hierarchy level.

10. A computing system for verifying a network, characterized in that, The computing system includes: Processor devices; and A memory for storing instructions that, when executed by the processor device, cause the computing system to: Define an input binary decision graph (BDD), whereby the input BDD represents the input header space used to query network attributes of interest; The input BDD is provided as input to the device-level BDD representing the source device in the logical topology, which represents the connections between devices in the network, and each device in the network is represented by the corresponding device-level BDD in the logical topology; The output BDD representing the output header space of the destination device in the logical topology is calculated, wherein the output BDD is calculated by sequentially applying the input BDD to each device-level BDD in the logical path from the source device to the destination device; The report describes the output BDD; and The reported output BDD is compared with the expected output BDD to verify the network properties of interest and detect faults in the network, including: The discarded BDD is determined by calculating the difference between the expected output BDD and the reported output BDD, where the discarded BDD represents the discarded header space; The discarded BDD is provided as input to each individual device-level BDD, and it is determined whether the output of each individual device-level BDD is a reduced or empty header space compared to the discarded header space represented by the discarded BDD; and A faulty device represented by a specific single device-level BDD is identified as a source of fault in the network, and the faulty device is determined to output a reduced or empty header space.

11. The computing system according to claim 10, characterized in that, Each device is represented by a corresponding hierarchical model, which includes a device level corresponding to the corresponding device level BDD, and the hierarchical model also includes at least one other hierarchical level below the device level, which corresponds to one or more lower-level BDDs representing one or more lower-level model entities of the corresponding device.

12. The computing system according to claim 11, characterized in that, The one or more model entities include one or more network entities (NEs) residing on the respective devices, each NE being represented by a corresponding NE level BDD at a lower NE level than the device level in the hierarchical model.

13. The computing system according to claim 12, characterized in that, The hierarchical model also includes rule levels below the NE level in the hierarchical model, the rule levels corresponding to one or more rule levels BDD representing one or more rules implemented by the one or more NEs.

14. The computing system according to claim 11, characterized in that, Each lower-level BDD is conjugate with a corresponding index variable that indicates the logical order of the corresponding model entities in the logical path from the entry to the exit of the corresponding device.

15. The computing system according to any one of claims 10 to 14, characterized in that, The instructions also enable the computing system to: Based on the reported output, BDD detects faults in the network at the identified faulty devices; and Lower-level verification is performed using a hierarchical model representing the identified faulty device in the following manner: Provide input BDDs as inputs to one or more lower-level BDDs in the hierarchical model; Calculate the output BDD from each lower-level BDD; as well as Identify the faulty lower-level model entities of the identified faulty device from the calculated output BDD.

16. The computing system according to claim 15, characterized in that, The lower-level validation is repeated for each descending level of the hierarchical model.

17. The computing system according to any one of claims 10 to 14, characterized in that, The instructions also enable the computing system to: Generate device-level BDDs for a given device using the following methods: Collect data on device status and device configuration, including data on one or more model entities implemented by the given device; Each model entity is modeled as a corresponding Boolean function, and the corresponding Boolean function is encoded as a corresponding BDD; A logical combination represents the individual BDDs of one or more model entities within the given device; as well as The logical combination is stored as a device-level BDD representing the given device.

18. The computing system according to any one of claims 10 to 14, characterized in that, Each device is represented by a corresponding hierarchical model, the hierarchical model including a device level corresponding to the corresponding device-level BDD, the hierarchical model also including at least another hierarchical level below the device level, the at least another hierarchical level corresponding to one or more lower-level BDDs representing one or more model entities implemented by the corresponding device, the instructions also causing the computing system to: Generate a hierarchical model for a given device using the following methods: Collect data on device status and device configuration, including data on one or more lower-level model entities implemented by the given device; Each model entity corresponding to the lowest level of the hierarchical model is modeled as a corresponding Boolean function, and the corresponding Boolean function is encoded as a corresponding BDD; For a given hierarchical level, a BDD is generated for each incremental level of the hierarchical model in the following manner: A BDD representing a given model entity is generated by logically combining BDDs representing one or more lower-level model entities implemented by a given model entity at the given hierarchical level, wherein the one or more lower-level model entities belong to a lower hierarchical level immediately below the given hierarchical level. Each BDD representing a corresponding lower-level model entity is conjugate with a corresponding index variable indicating the logical order of the corresponding lower-level model entities implemented by the given model entity; as well as Store BDDs for each hierarchy level.

19. A computer-readable medium storing instructions, characterized in that, When the instructions are executed by the processor device of the computing system, the computing system: Define an input binary decision graph (BDD), whereby the input BDD represents the input header space used to query network attributes of interest; The input BDD is provided as input to the device-level BDD representing the source device in the logical topology, which represents the connections between devices in the network, and each device in the network is represented by the corresponding device-level BDD in the logical topology; The output BDD representing the output header space of the destination device in the logical topology is calculated, wherein the output BDD is calculated by sequentially applying the input BDD to each device-level BDD in the logical path from the source device to the destination device; The report describes the output BDD; as well as The reported output BDD is compared with the expected output BDD to verify the network properties of interest and detect faults in the network, including: The discarded BDD is determined by calculating the difference between the expected output BDD and the reported output BDD, where the discarded BDD represents the discarded header space; The discarded BDD is provided as input to each individual device-level BDD, and it is determined whether the output of each individual device-level BDD is a reduced or empty header space compared to the discarded header space represented by the discarded BDD; and A faulty device represented by a specific single device-level BDD is identified as a source of fault in the network, and the faulty device is determined to output a reduced or empty header space.

20. The computer-readable medium according to claim 19, characterized in that, Each device is represented by a corresponding hierarchical model, which includes a device level corresponding to the corresponding device level BDD, and the hierarchical model also includes at least one other hierarchical level below the device level, which corresponds to one or more lower-level BDDs representing one or more lower-level model entities of the corresponding device.

Images