Method and system for distributed network authentication

Abstract

Methods and systems for partial or full distributed network verification are described. In partial distributed network verification, each network device generates a respective device-level binary decision diagram (BDD) that represents the logical behavior of the respective network device with respect to a network property of interest. The device-level BDD from each network device is received by a verification service that performs verification by generating an input BDD that represents an input header space, applying each device-level BDD in a logical path from a source device to a destination device, and reporting an output BDD. In full distributed network verification, each network device is responsible for computing a device-specific output BDD by applying a device-specific BDD that represents the logical behavior of the network device to a device-specific input BDD.

Description

[0001] Related applications cross-application

[0002] This application claims priority to U.S. Nonprovisional Application No. 17 / 131,102, filed December 22, 2020, entitled “Method and System for Distributed Network Authentication,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to methods and systems for network authentication, including methods and systems for network authentication using fully or partially distributed authentication services. Background Technology

[0004] As network and network equipment operations become increasingly complex, network operators are finding it increasingly difficult to ensure that network configurations and policies are designed and installed as intended. Furthermore, given the size of many existing networks, traditional network testing tools (such as Simple Network Management Protocol (SNMP)) or tracing tools like tracert or ping offer only limited network coverage. Moreover, such network tracing techniques are often used to reactively diagnose problems after they have occurred.

[0005] To address some of the aforementioned complexities and limitations, formal verification techniques previously used for software and chip design have been considered for network verification. The term "formal" refers to verifying network configurations using mathematical models and computations, rather than tracking the network by sending actual data packets. In the context of this disclosure, formal network verification can simply be referred to as network verification. Network verification provides proactive and predictive problem identification. However, practical applications of network verification still face challenges in terms of scalability and real-time verification.

[0006] Generally, in network verification, mathematical techniques are used to model the network to be verified (checked, tested, or confirmed) and then the desired network invariants are checked in the model to specify the correct (actual or more accurate) network behavior. For example, the confirmation can be done continuously, or at periodic intervals, or from time to time. Examples of existing network verification techniques can be categorized into four categories, including model checking, theorem proving, Boolean satisfiability (SAT) / satisfiability modulo theory (SMT) solvers, symbolic execution, and symbolic simulation. Most of the existing network verification methods rely on a centralized computing system that performs the necessary data collection and verification computation tasks. Due to the limitations of computing power and memory resources, and the challenges of collecting data from a large number of network devices in real time, such a centralized approach is difficult to scale to larger networks.

[0007] Therefore, there is a need for improved network verification techniques. SUMMARY

[0008] In various examples, the present disclosure describes methods and systems for network verification that help address some of the shortcomings of existing network verification techniques that rely on a centralized computing system to perform the verification.

[0009] In the disclosed methods and systems, a fully or partially distributed approach is used for network verification. Unlike a centralized system that collects data from all network devices, each network device is responsible for generating its own device model, which is a logical representation of its own logical behavior (e.g., as a Boolean decision graph). This distributed approach avoids the need to collect data from all network devices, which would cause time delays that negatively impact real-time network verification. Furthermore, the security of the network can be improved since there is no need to transmit detailed information of the network device configurations. The device model can be generated by the individual network device, rather than by a centralized system. When the configuration of the network device changes, the network device can also update the individual device model locally without the involvement of a central entity. Thus, the disclosed distributed approach for network verification can help reduce the time needed for model generation, thereby enabling more efficient use of time and computing resources for network verification.

[0010] The disclosed distributed approach for network verification can verify a part of the network (also referred to as a slice), or verify a specific function of the network, without having to verify the entire network. This approach is possible because each network device generates and stores its own verification model locally, rather than a single centralized model being generated and stored at a central entity of the entire network. This provides the technical effect that verification can be performed on a part of the network using fewer resources, without having to verify the entire network.

[0011] The disclosed distributed approach can also avoid the state explosion problem (and thus achieve higher scalability) compared to traditional centralized network verification approaches. Further advantages and technical effects are described in the detailed description.

[0012] In some example aspects, the disclosure describes a method for verifying a network. The method includes obtaining, from each network device in the network, a respective device-level binary decision diagram (BDD) representing a logical behavior of the respective network device with respect to a network property of interest; generating an input BDD as an input to a source BDD representing a source device in a logical topology of connections between the network devices, wherein the input BDD is defined to represent an input header space for querying the network property of interest; 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.

[0013] In any of the above examples, the method can include sending a request to each network device for a respective device-level BDD; and obtaining the respective device-level BDD in a respective response from the respective network device.

[0014] In any of the above examples, the method can include defining the logical topology according to the network property of interest, wherein the logical topology is defined using a topology graph and the device-level BDDs are respective vertices in the topology graph.

[0015] In any of the above examples, the method can include obtaining at least one device-level BDD from a transmission from a respective network device, wherein the transmission is received without a request for a device-level BDD.

[0016] In any of the above examples, the method can include identifying at least one boundary device in the network device, wherein the boundary device provides an interface between the network and one or more entities outside the network; obtaining information of the one or more entities outside the network from the at least one boundary device.

[0017] In any of the above examples, the information of the one or more entities outside the network can be used to generate the input BDD.

[0018] In some example aspects, the present disclosure describes a method for generating a model for network verification. The method includes collecting data about states and configurations of network entities in a network device; modeling each network entity as a respective Boolean function and encoding the respective Boolean function as a respective Binary Decision Diagram (BDD); logically combining the respective BDDs to obtain a device-level BDD, wherein the device-level BDD is a model representing logical behavior of the network device; and sending the device-level BDD to a verification service.

[0019] In any of the above examples, the device-level BDD can be generated in response to a request received from the verification service.

[0020] In any of the above examples, the method can include obtaining information of an uncommitted configuration of at least one network entity. The respective BDD encoded for the at least one network entity can represent the uncommitted configuration.

[0021] In any of the above examples, the method can include receiving a confirmation of implementation of the uncommitted configuration from the verification service; and in response to the confirmation, causing the uncommitted configuration to become a committed configuration implemented by the at least one network entity.

[0022] In some example aspects, the present disclosure describes a method for verifying a network. The method includes obtaining, at a network device, a device-specific input Binary Decision Diagram (BDD) representing a device-specific input header space to query a network property of interest; computing a device-specific output BDD representing a device-specific output header space, wherein the device-specific output BDD is computed by applying a device-specific BDD to the device-specific input BDD, and a device-level BDD representing logical behavior of the network device; storing the device-specific input BDD and the device-specific output BDD; and comparing the device-specific output BDD and the device-specific input BDD to verify the network property of interest of the network device.

[0023] In any of the above examples, the method can include sending the device-specific output BDD to one or more neighboring devices having a direct physical or logical connection with the network device.

[0024] In any of the above examples, the method can include identifying the one or more neighboring devices and establishing a point-to-point connection with each of the one or more neighboring devices.

[0025] In any of the above examples, the network device can be a border device configured to provide an interface between the network and one or more entities outside the network, and the obtaining the device-specific input BDD can include receiving the device-specific input BDD, wherein the device-specific input BDD is generated using collected configuration information about the one or more entities outside the network.

[0026] In any of the above examples, the obtaining the device-specific input BDD can include receiving the device-specific input BDD from a neighboring device having a direct physical or logical connection with the network device.

[0027] In any of the above examples, the method can include collecting data about states and configurations of network entities in the network device; modeling each network entity as a respective Boolean function and encoding the respective Boolean function as a respective BDD; logically combining the respective BDDs to obtain a device-level BDD, wherein the device-level BDD is a model representing logical behavior of the network device; and storing the device-level BDD.

[0028] In any of the above examples, the method can include synchronizing a validation clock with one or more neighboring devices, wherein the validation clock defines a synchronized timing for data collection.

[0029] In some example aspects, the disclosure describes a computing system, wherein the computing system includes a processor device and a memory storing instructions. When the instructions are executed by the processor device, the computing system is caused to perform any of the above example methods.

[0030] In some example aspects, the disclosure describes a computer-readable medium having stored therein instructions. When the instructions are executed by a processor device of a computing system, the computing system is caused to perform any of the above example methods. BRIEF DESCRIPTION OF DRAWINGS

[0031] The accompanying drawings, which are incorporated herein by reference, and wherein the same reference numerals designate similar or equivalent elements throughout the several views, illustrate example embodiments of the application and, together with the description, further serve to explain the principles of the application and to enable this and other embodiments of the application to be realized. In the drawings:

[0032] Figure 1 An example validation architecture that can be used to implement partially distributed network validation is shown in accordance with some examples of the disclosure;

[0033] Figure 2A And Figure 2B is a block diagram of a simplified example of a computing system that can be used to implement examples of the disclosure;

[0034] Figure 3 Flowchart of an example method for constructing a device model at a network device according to examples described herein;

[0035] Figure 4 An example implementation of the method in Figure 3

[0036] Figure 5 Flowchart of an example method for network verification in a lightweight verification service according to examples described herein;

[0037] Figure 6 An example implementation of the method in Figure 5

[0038] Figure 7 An example verification architecture that can be used to implement fully distributed network verification according to some examples of the disclosure is shown;

[0039] Figure 8 Flowchart of an example method for network verification at a network device according to examples described herein;

[0040] Figure 9 An example implementation of the method in Figure 8

[0041] Figure 10 An example finite state machine that can be used to implement fully distributed network verification by a network device according to examples described herein is shown.

[0042] Similar reference numerals can be used to refer to similar components throughout various drawings. DETAILED DESCRIPTION

[0043] 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 computers such as routers, switches, servers, or personal computers, mobile devices such as smartphones, Internet of Things (IoT) devices, or any other device capable of transmitting, 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 are applicable to systems other than computer networks, which can represent system states using Boolean functions or Binary Decision Diagrams (BDDs). (Generally, one thing represents another when it symbolizes, includes relevant information about, indicates, or otherwise stands in for the thing being represented.) ​​​

[0044] As used herein, the term “network entity” (NE) refers to a set of data structures or rules applied by a device in a computer network for determining how to handle a communication in the network based on 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 values of fields of a communication (e.g., a digital packet) satisfy various criteria, thereby determining how to handle 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 will be appreciated that any set of rules used by a switch, router, or other network device to determine handling of a packet and thus how the network handles a given communication can potentially be represented as an NE.

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

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

[0047] One network verification tool is the open source network analysis tool Batfish. This tool simulates the control plane to obtain forwarding rules (FIBs) (as context dictates, to obtain is to get, which does not require getting by any particular means or from any particular source). As a result, the tool’s execution tends to be slow, e.g., hours are required to verify a relatively small network. Another existing network verification tool is Minesweeper. Because this tool is designed based on satisfiability modulo theory (SMT), it cannot provide multiple counterexamples when a violation occurs. Another existing network verification tool is Veriflow, which is an enhanced version of another tool called Anteater. Veriflow extracts equivalent classes for the entire network, but performing this task is difficult or impossible for networks composed of different segments controlled in different administrative domains. Moreover, computing equivalent classes is challenging or resource-intensive for large-scale networks. Another existing verification tool is NetPlumber, which employs a similar approach to Veriflow. NetPlumber only verifies the portion of the network affected by a change in network rules, rather than the entire network.

[0048] Another existing network verification tool is Hassel-C (or HSA). This tool encodes packet headers as a subset of a geometric space. A disadvantage of this approach is that state space explosion occurs with HSA in cases where the header space contains a large number of required bits. Another existing verification tool is Network Optimized Datalog (NOD), which is similar to HSA but uses a different encoding technique. NOD is said to have slow performance.

[0049] Some conventional network verification tools use a model checking approach. The model checking approach constructs a single large model for the entire network, e.g., even the location of a packet is represented in a finite state machine (FSM) embedded in a single network model. The benefit of the conventional model checking approach is that the computation is faster because only one model needs to be considered for the entire network. However, the disadvantage of this model is the lack of detailed information about the location or cause of a detected fault in the network. One example of this model checking approach is FlowChecker. FlowChecker uses model checking to verify the correctness of OpenFlow networks. However, FlowChecker has been found to have scalability issues, and FlowChecker is limited to practical use in relatively small networks.

[0050] Some conventional network verification schemes attempt to address the scalability issue. For example, Libra attempts to address the network snapshot inconsistency issue (i.e., network information captured at a single point in time) in an attempt to improve scalability. Libra is used to monitor a network event stream in order to capture configuration information (e.g., forwarding tables) of network devices when the network is stable. However, this approach still relies on a central entity.

[0051] 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 results of the system output. Symbolic simulation uses a similar technique but 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, but suffers from state space explosion when the network is large and / or the network is modeled at a high level of detail.

[0052] The present disclosure describes methods and systems that enable network verification in a partially or fully distributed manner. Such a distributed approach helps to address at least some of the shortcomings of centralized verification methods, such as state explosion, limited scalability, or potential security threats. The present disclosure describes both partially distributed network verification and fully distributed network verification. It should be understood that both approaches are considered distributed network verification approaches, and both partially and fully distributed network verification are more advantageous than traditional network verification schemes.

[0053] In the disclosed methods and systems, the 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 this variable is passed through paths in the network. The network can be modeled without losing any verification context, nor does it have to build large models that lead to state explosion problems. Thus, the disclosed methods and systems can improve scalability for verifying large networks.

[0054] Figure 1 A simple example of a partially distributed verification architecture 100 that can be used to implement examples described herein is shown. The disclosed verification architecture 100 includes a Network Verification Domain (NVD) 110, a Light Weight Verification Service (LWVS) 130, and a Distributed Verifier (DV) 114.

[0055] 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. In this example, the NVD includes four network devices 112a, 112b, 112c, 112d (generally referred to as network devices 112). Each network device 112 within the NVD 110 can be any device that participates in packet communication in the network. For example, each network device 112 can independently be one of the following: a router, a switch, a gateway, or any other network-enabled device, among other possible devices. Generally, 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. Although Figure 1A single NVD 110 is shown, but it will be appreciated that multiple NVDs 110 can be defined for verifying an entire network or a portion(s) of a network. Different NVDs 110 can be defined to include different network devices 112; different NVDs 110 can be defined to have different logical topologies (e.g., different logical connections among the same set of network devices 112, or different arrangements or interrelationships among logical components); different NVDs 110 can overlap (i.e., have one or more common network devices 112 and / or have one or more common logical connections). For example, NVDs 110 can be defined for a particular routing protocol (e.g., border gateway protocol (BGP)), a particular network layer (e.g., layer 2 topology), and other such possibilities. Thus, different NVDs 110 can be defined to be capable of verifying an entire network or a portion of a network, and can be specific to particular network properties or network mechanisms of interest.

[0056] Each network device 112a, 112b, 112c, 112d implements a respective distributed verifier (DV) 114a, 114b, 114c, 114d (generally referred to as DV 114) to perform the operations disclosed herein. The DV 114 can be implemented by software instructions, hardware components, or a combination of software and hardware. The network device 112 performs operations for computing a local verification model (referred to as a device model (DM)) and for participating in verification tasks. In the present example, each network device 112a, 112b, 112c, 112d computes a respective DM 122a, 122b, 122c, 122d (generally referred to as DM 122). The network device 112 transmits the respective computed DM 114 to the LWVS 130. The network device 112 can also store its respective computed DM 122 (also referred to as a local DM 122) in local memory (i.e., in memory of the respective network device 112). In some cases, a network device 112 does not have the capability to perform its own DV 114 (e.g., the network device 112 has limited processing capabilities and / or limited memory resources). If a given network device 112 does not have the capability to perform its own DV 114, the given network device 112 can provide information (e.g., information of its state and configuration) to the LWVS 130, which can compute the DM 122 for the given network device 112. Alternatively, the given network device 112 can provide information (e.g., information of its state and configuration) to a neighboring network device 112 (which does have the capability to compute a DM 122) to cause the neighboring network device 112 to compute the DM 122 on behalf of the given network device 112. The computed DM 122 (whether computed by the LWVS 130 or a neighboring network device 112) can be transmitted back to the given network device 112 for storage locally by the given network device 112.

[0057] In some cases, network devices 112 (e.g., network devices 112a, 112c, 112d) can be border network devices (or simply, border devices). Border devices are network devices 112 that interface with other entities outside of NVD 110. Generally, any entity outside of NVD 110 can be referred to as an external environment of NVD 110 and is not authenticated through authentication of NVD 110. Border devices can perform operations that other network devices 112 (e.g., network device 112b is not a border device) do not need to perform. For example, border devices can collect and transmit information about the configuration of the interface to the external environment connected to NVD 110 and / or about logical routing information received from other entities in the external environment. It should be noted that whether a given network device 112 acts as a border device depends on NVD 110. A network device 112 that is a border device for a first NVD 110 can not be a border device for a second NVD 110. It should be understood that references to network devices 112 in this disclosure are intended to encompass both border devices and non-border devices, while references to border devices are intended to be specific to border devices and not necessarily applicable to non-border devices.

[0058] Each network device 112 is modeled by a respective DM 122. DM 122 is computed from information about the state and configuration of the local network device 112. DM 122 modeling a given network device 112 is designed to represent the functional behavior of network device 112 according to the authentication requirements. For example, for data plane authentication, DM 122 represents the behavior of the respective network device 112 in the data plane. On the other hand, for control mechanism authentication, DM 122 represents the behavior of the respective network device 112 in running routing protocols and routing policies. Multiple DMs 112 can be generated for modeling the behavior of a single given network device 112 (e.g., a first DM 112 for modeling the behavior of the data plane and a second DM 112 for modeling the behavior of the control plane). Each DM 122 is represented as a Boolean function, which is encoded as a BDD, e.g., a reduced ordered BDD (ROBDD). It should be understood that references to BDDs in this disclosure can be more specifically references to ROBDDs.

[0059] A BDD is a data structure used to represent a Boolean function. A BDD can be represented as a binary decision tree, including a top node and one or more binary decision sub-trees recursively following the same pattern under the top node. BDDs can be used to model decisions made by a corresponding network device 112 (i.e., a network device 112 modeled by a DM 122, which in turn is represented by a Boolean function encoded as a BDD) with respect to a particular communication made in a network in the NVD 110. 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) according to which the network device 112 decides how to handle the data 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 base (FIB), routing policies, protocol configurations, etc.) hosted on the network device 112 to make the decision. Each NE can be represented by a Boolean function, which can be modeled using a corresponding BDD. As described in detail below, a network device 112 can be modeled based on BDDs of NEs hosted on the network device 112.

[0060] A ROBDD is a simplified form of a BDD in which any isomorphic sub-graphs are merged and any node with two isomorphic child nodes is removed. A ROBDD is a unique representation of a Boolean function. Typically, common usage of the term BDD refers specifically to a ROBDD.

[0061] The LWVS 130 performs operations to define the NVD 110, manage the network devices 112 (e.g., including assigning particular network devices 112 as boundary devices), and collect information from the network devices 112 (e.g., DMs 122 and external environment information). The LWVS 130 uses the collected information to perform network verification. The LWVS 130 can send requests for information (e.g., to multiple network devices 112 by broadcast, groupcast, or multicast, or to a network device 112 by unicast), which the network devices 112 can respond to with the corresponding DM 122 and (in the case of BDVs) external environment information. In some examples, the LWVS 130 can receive information from the network devices 112 without sending a request for the information. For example, when the status or configuration of a corresponding network device 112 changes, the network device 112 can unilaterally send unsolicited information (e.g., an updated DM 122) to the LWVS 130. Further details of the operations of the LWVS 130 will be described below.

[0062] The LWVS 130 can define a logical topology in the logical domain 120 between the DMs 122. The logical topology can be defined based on network properties of interest. It should be 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 property of interest is reachability of an overlay network on top of the physical network, the logical topology can be defined by the LWVS 130 based on connections (or tunnels) between the network devices 112 of that overlay network.

[0063] Figure 2A A block diagram of a simplified example of a computing system 220 that can be used to implement examples described herein is shown. For example, a network device 112 can be implemented using the computing system 220. Other examples suitable for implementing the embodiments described in this disclosure can be used, and can include different components than those described below. Although specific Figure 2A A single instance of each component is shown, but multiple instances of each component can be present in the computing system 220.

[0064] The computing system 220 can include one or more processing 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, which can connect with one or more optional input devices 234 and / or optional output devices 236.

[0065] 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 optional and external to the system 220. In other examples, any of the input devices 234 and output devices 236 can be absent, in which case the I / O interfaces 232 can not be needed.

[0066] The computing system 220 can include one or more network interfaces 222 for wired or wireless communication with one or more devices or systems of a network, such as the other network devices 112 in the NVD 110 and the LWVS 130. The network interfaces 222 can include wired links (e.g., Ethernet lines) and / or wireless links (e.g., one or more antennas) for intranet and / or Internet communications.

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

[0068] 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, such as to perform the examples described in this disclosure. In some examples, the memory 228 can include software instructions 238 for execution by the processor device 225 to implement various aspects of the distributed network verification disclosed herein. The software instructions 238 can also include other instructions, such as instructions to implement an operating system and other applications / functions. In this example, the DV 114 is implemented using the software instructions 238 stored in the memory 228.

[0069] The non-transitory memory 228 can also store data, including the DM 122 generated by the network device 112. In some examples (e.g., in a fully distributed network validation example), the memory 228 can also store the local validation data 126.

[0070] 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, Compact Disc Read Only Memory (CD-ROM), or other portable memory.

[0071] Figure 2B A block diagram showing a simplified example of another computing system 250 that can be used to implement examples described herein is shown. The computing system 250 can be a server, computer, or cloud computing platform, among other possibilities. For example, the LWVS 130 can be implemented using the computing system 250. Other examples suitable to implement the embodiments described in this disclosure can be used, which can include different components than those described below. Although Figure 2B A single instance of each component is shown, but multiple instances of each component can be present in the computing system 250. The computing system 250 can include components similar to those of the computing system 220, details of which need not be repeated. Figure 2A The computing system 250 can include components similar to those of the computing system 220, details of which need not be repeated.

[0072] The computing system 250 can include one or more processor devices 225, one or more optional input / output (I / O) interfaces 232 (for connection with one or more optional input devices 234 and / or one or more optional output devices 236), one or more network interfaces 222 (for wired or wireless communication with the network device 112), one or more storage units 224, and one or more memories 228.

[0073] The non-transitory memory 228 can store instructions 238 that are executed by the processor device 225, such as to perform examples described in this disclosure. In this example, the LWVS 130 is implemented using software instructions 238 stored in the memory 228. The non-transitory memory 228 can also store data, including the DMs 122 that have been received from the DVs 114, as well as the topology 123 defining the NVD 110 and the logical domains 120. In some examples, some or all of the DMs 122 and / or the topology 123 can be stored in external memory (e.g., an external database or cloud-based storage) that is accessible to the computing system 250.

[0074] In some examples, the computing system 250 can additionally or alternatively execute instructions from external memory (e.g., an external drive that is in wired or wireless communication with the computing system 250), 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 memory storage.

[0075] It will be appreciated that various components and operations described herein can be implemented using other computing systems and other computing architectures.

[0076] Figure 3 A flowchart of an example method 300 is shown that can be performed by a given network device 112 that implements a DV 114 (e.g., the computing system 220 executing instructions 238 using the processor device 225 to implement the method 300). For example, the steps of the method 300 can be encoded as operations to be performed by the DV 114 that is resident on the given network device 112. The method 300 can be performed to compute a local DM 122 that is representative of the given network device 112. The method 300 can be performed by the network device 112 at the beginning of network verification (e.g., triggered by a request for the DM 122 from the LWVS 130), or can be performed after any change in the state or configuration of the network device 112.

[0077] Optionally, at 302, the network device 112 receives a request from the LWVS 130 for a DM 122 that is representative of the given network device 112 behavior with respect to a network property of interest. The request from the LWVS 130 can also identify the network property of interest (e.g., reachability at Layer 2 or Layer 3 in the data plane, or reachability in the control plane). Alternatively, the network device 112 can determine that the state or configuration of the network device 112 has changed, and that the DM 122 needs to be updated, rather than receiving a request from the LWVS 130.

[0078] At 304, the network device 112 collects information about the state and configuration of the NEs of the network device 112. The network device 112 can first determine the NEs of the network device 112 that are relevant to the network property of interest (e.g., ingress / egress ACLs, FIB, routing policies, protocol configurations, etc.) and collect information about the state and configuration from the relevant NEs.

[0079] Optionally, at 306, the network device 112 can obtain information of uncommitted configurations of the NEs. The network device 112 can store different versions of configuration information of the NEs. Each version of the configuration information of a given NE can represent a committed configuration (i.e., a configuration currently implemented by the NE) or an uncommitted configuration (i.e., a configuration not currently implemented but possibly implemented in the future). The network device 112 can obtain information of the committed configurations from the current configurations of the NEs. Information of the uncommitted configurations can be obtained from the LWVS 130 or from the local memory of the network device 112.

[0080] Subsequent steps of the method 300 can be performed using information of committed or uncommitted configurations. That is, the DM 122 computed using the following steps can represent a configuration currently in use or can represent a possible configuration not currently in use. By constructing the DM 122 to represent a possible configuration not currently in use, the possible configuration can be validated before the possible configuration is actually implemented in the network device 112. This can enable a more proactive validation process.

[0081] At 308, the network device 112 models each NE as a respective Boolean function and encodes the Boolean function as a BDD. For example, each NE can be modeled as a transfer function or a FSM using the collected information (e.g., depending on whether the model represents data plane behavior or control plane behavior). The transfer function or FSM is represented as a Boolean function, which is then encoded as a BDD format. For example, if the network property of interest is reachability, all the NEs in a logical path between two ports of the network device 112 can be modeled as respective transfer functions and encoded as BDD format.

[0082] At 310, based on the logical interactions of the NEs, the models of all relevant NEs of the given network device 112 are combined to generate a single DM 122 representing the functionality of the given network device 122 for the network property of interest. For example, if the property of interest is reachability, then the models of all NEs in the logical path from the ingress port to the egress port of the network device 112 can be combined using a logical AND (AND) operation to generate a single port-to-port model representing the reachability between the two ports of the network device 122. The DM 122 of the network device 122 can then be generated by connecting all the port-to-port models using a logical OR (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 similarly be generated to represent the behavior of each network device 112 for other network properties of interest. Thus, the computed DM 122 represents the logical behavior of the given network device 112 in the NVD 110, as well as the logical behavior of all NEs within the given network device 112 for the network property of interest.

[0083] At 312, the computed DM 122 is transmitted to the LWVS 130. The computed DM 122 can also be stored locally at the network device 122. The LWVS 130 can then use the DM 122 to perform verification of the network property of interest.

[0084] Optionally, at 314, if the DM 122 is generated using information of an uncommitted configuration of a given NE in the network device 112, then the network device 112 can receive confirmation from the LWVS 130 to implement the uncommitted configuration. For example, after the LWVS 130 has verified the correctness of the uncommitted configuration using the DM 122, the LWVS 130 can instruct the network device 112 to commit the verified configuration (i.e., the uncommitted configuration that has been verified using the DM 122 becomes the committed configuration for the given NE). The network device 112 implements the verified uncommitted configuration as the new configuration for the given NE. The previous committed configuration becomes the uncommitted configuration, which can be saved locally for later use.

[0085] Figure 4 An example implementation of some of the steps of the method 300 used in the simplified network device 112 is shown. Figure 4 An example is shown of how a given network device 112 uses the DV 114 to generate a port-to-port model for verifying a reachability property of a network.

[0086] In the present example, n NEs 115 (denoted as Network Entity 1, Network Entity 2 to Network Entity n) are included in the logical path from ingress port A 116 to egress port B 118 of network device 112. Each NE 115 can independently act as any NE discussed herein. In particular, with respect to reachability properties, each NE 115 can independently act as a set of rules or tables (e.g., routing tables) used in network device 112 for managing the routing of data packets based on information contained in the data packet header. Information of the configuration and state of each NE 115 is collected in steps 304-306 described above. From this information, in step 308, each NE 115 is modeled as a Boolean function and encoded as a corresponding BDD 124 in logic domain 120. For example, for data plane verification, each NE 115 can be modeled as a Boolean function that applies forwarding rules based on binary bits representing the source and / or destination address (e.g., IP or MAC address) of the data packet in the data packet header. Each NE 115 can transform a data packet from one state to another or change the position of the data packet in the logical path.

[0087] In the illustrated example, a corresponding NE-level BDD 124 (denoted as BDD NE1, BDD NE2 to BDD NEn) is generated for each corresponding NE 115 and stored by DV 114. Each NE-level BDD 124 is a function encountered by a data packet as it is transmitted along the logical path from ingress port to egress port. Then, by combining all NE-level BDDs 124 using a logical AND (AND) operation, a port-to-port model between ports A and B is generated that represents a Boolean function in the form of a port-to-port BDD that is used to control the routing of data 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 in the following way:

[0088]

[0089] where BDD NE1 to BDD NEn represent the BDDs 124 of the n NEs 115 in the logical path between ingress port A 116 and egress port B 118, and the symbol represents a logical AND (AND) operation.

[0090] 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. All port-to-port models are then combined using a logical OR (OR) operation to generate the DM 122 for the network device 112. The DM 122 generated for a given network device 112 can then be transmitted (or otherwise provided) to the LWVS 130 (optionally locally stored on the network device 112) for verifying reachability properties of the network.

[0091] As mentioned above, each network device 112 is responsible for locally building the respective DM 122 based on the state and configuration of the local NEs (i.e., the NEs belonging to the respective network device 112). The unprocessed data (or raw data) of the network device 112 does not need to be transmitted outside of the network device 112, which facilitates achieving higher data security. The network device 112 can respond to a request from the LWVS 130 to generate the DM 122 in a stable state and / or generate the DM 122 based on uncommitted configurations of the NEs.

[0092] In contrast to some other conventional network verification techniques that first attempt to compute the current state of the network based on the configuration information and then perform verification, the above-described approach utilizes the current state of the network devices 112 and the information of the configurations of the network devices 112 to generate the DM 122. In contrast to some existing techniques, the disclosed approach can achieve higher scalability and / or faster model generation.

[0093] As mentioned previously, the DM 122 generated by the network devices 112 is transmitted (or otherwise provided) to the LWVS 130 for performing network verification. Details regarding the operation of the LWVS 130 are now discussed.

[0094] Each DM 122 is a corresponding Boolean function (e.g., encoded as a corresponding BDD) representing the behavior of the corresponding network device 112 for a specific network attribute of interest. As discussed further below, the LWVS 130 receives DM 122 from network device 112 in NVD 110 and constructs a logical topology in logical domain 110. Then, by inputting the header space into the source DM 122, the output header space of the destination DM 122 is calculated, and authentication is performed to determine whether the required authentication attributes are satisfied. Some network attributes that can be authenticated using DM 122 include: reachability (e.g., whether there is a network device 112 that packets cannot reach), loop detection (e.g., whether any packets eventually return to the source device 112), black hole presence (e.g., whether there is a device 112 that loses packets), route detection (e.g., mapping routes from source device 112 to destination device 112), and security vulnerabilities (e.g., whether the firewall provided by network device 112 is functioning correctly), etc. DM 122 can be generated only for network device 112 (and network entities within network device 112) associated with network attributes of interest.

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

[0096] As the input header space is transmitted along the logical path from the source DM 122 to the destination DM 122, each DM 122 encountered by the header space applies a corresponding Boolean function to the header space. This Boolean function indicates how the corresponding network device 112 will process the header space (e.g., which output port to send to if verifying network reachability attributes). Then, through header space calculations (which are well-known and will not be detailed here), the output header space can be used to verify whether the required verification attributes are met.

[0097] Figure 5A flowchart showing an example method 500 for network validation performed by the LWVS 130 is shown. The LWVS 130 can be implemented by a server using software, hardware, or a combination of software and hardware, for example, by the computing system 250 using the processor device 225 to execute the instructions 238.

[0098] When network validation is first initiated, the NVD 110 and one or more network attributes of interest (i.e., attributes to be validated) can be defined by the LWVS 130. The network devices 112 in the NVD 110 can already be registered on the LWVS 130, or otherwise identified to the LWVS 130. For example, when the DV 114 is first initiated on a network device 112, the network device 112 can initiate a registration request to register the DV 114 on the LWVS 130. In another example, the LWVS 130 can discover the DV 114 residing on the network devices 112 in the network, for example, using a broadcast message. The definition of the NVD 110, the definition of the network attributes of interest, and the registration of the DV 114 can be performed prior to the method 500.

[0099] At 502, the LWVS 130 sends a request to the network devices 112 (e.g., to all of the network devices 112 having registered DVs 114) requesting transmission of respective DMs 122. In response to the request, each network device 112 sends the respective DM 122 representing the respective network device 112 to the LWVS 130.

[0100] In some examples, the step 502 can be performed outside of the method 500. For example, the LWVS 130 can request the DMs 122 from the network devices 112 at registration or at regular intervals (e.g., daily) rather than as part of validation. In addition, the network devices 112 can unilaterally send their DMs 122 to the LWVS 130 without a request by the LWVS 130 (e.g., if the DMs 122 have been updated to reflect recent state changes or configuration changes of the respective network devices 112). The LWVS 130 can store the received DMs 122 (e.g., in the memory 228) and retrieve the DMs 122 from storage when needed to perform validation.

[0101] At 504, based on the received DM 122, the LWVS 130 constructs a topology graph in the logical domain 120, which represents a logical topology of a network property of interest (e.g., reachability). The LWVS 130 can utilize additional global information, such as adjacency relationships, to construct the logical topology. Such global information can be provided (e.g., input) by an administrator on the network where the NVD 110 resides or by a network controller with global oversight on the network where the NVD 110 resides. In some examples (e.g., when performing an interior gateway protocol (IGP)), the network devices 112 are capable of providing such global information. In the topology graph, each vertex (or node) in the graph represents a respective network device 112, and each edge in the graph represents a connection (e.g., logical and / or physical connection) between two network devices 112 established according to the network property of interest. For example, the edges of the topology graph can represent BGP peering in the control plane, tunnel connections in overlay networks, or other possible logical and / or physical connections according to the network property of interest.

[0102] The logical topology can be dynamically constructed by the LWVS 130 at the time of performing the verification according to the network property of interest. This helps ensure that the verification is performed using a model that correctly reflects the latest state and configuration of each network device 112. This is in contrast to some conventional verification techniques, which rely on a single network-level model generated at a single point in time.

[0103] Optionally, at 506, the LWVS 130 can identify one or more network devices 112 that are border devices (i.e., located on the border of the defined NVD 110 and connected to an environment outside the NVD 110) based on the defined NVD 110 and can request any needed information of the external environment from the identified border devices. The requested information of the external environment can include, for example, information of configurations of external entities (i.e., entities that do not belong to the NVD 110) connected to the NVD 110 through the identified BDVs, information of IP addresses or network domains (e.g., virtual local area networks (VLANs) or virtual extensible local area networks (VXLANs)) of the external entities. The LWVS 130 can use the requested information to generate an input header space corresponding to the configurations of the external entities. In some examples, the LWVS 130 can not need the information of the external environment and can generate a broad input header space that contains all possible configurations that can be connected with the identified BDVs.

[0104] At 508, the LWVS 130 obtains an input header space for performing verification against the network property of interest. The input header space can be thought of as a symbolic variable representing the space of all possible packet headers that can be input to the NVD 110. In some examples, the input header space can be obtained from the network device 112 identified as a boundary device in optional step 506. For example, the network device 112 can generate the input header space and transmit it to the LWVS 130. For example, information of the configuration (e.g., IP address) of the external entity can be used to define the input header space, which represents the range of possible IP addresses of the external entity connected to the NVD 110 through the identified boundary device.

[0105] In another example, the LWVS 130 can generate the input header space by detecting the configuration of the network device 112 where the identified BDV resides. The input header space can be defined according to information extracted from the configuration or state of the network device 112 (e.g., based on device configuration data such as whether there is a locally connected LAN, static routes, etc.). For example, if a given network device 112 is (or includes) a boundary router connected to other entities outside the NVD 110, and the IP address of the given network device 112 is 192.168.10.10 / 24, then the LWVS 130 can define the input 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 the operator of the LWVS 130.

[0106] At 510, the LWVS 130 defines a set of one or more queries in terms of the network property of interest to be verified. For example, if the network property of interest is reachability of all interfaces connecting the NVD 110 to entities outside the NVD 110, the LWVS 130 can first identify all border devices, and then define a query in terms of a pair of DMs 122 representing a source border device and a destination border device in the form of a header space. It should be appreciated that other such queries can be defined to verify other network properties of interest. Generally, each query can include a source network device 112 (also referred to simply as a source device) and a destination network device 112 (also referred to simply as a destination device). Each query can be defined as a header space. Since a header space is a multi-dimensional space in which the values in each dimension are binary, the defined header space can be represented as a BDD. The BDD representing the query can be referred to as an input BDD. In this way, the LWVS 130 generates an input header space representing the query, which is input to the DMs 122 at step 512.

[0107] At 512, the LWVS 130 computes an output header space (represented by an output BDD) for each input BDD representing a query. The output BDD is computed by applying the DM 122 of each network device 112 encountered along a logical path from the source network device 112 to the destination network device 112 (according to the topology graph in the logical domain 120) to the input BDD. The LWVS 130 can use the topology graph to identify all possible logical paths from the source network device 112 to the destination network device 112, compute the output header space for the respective specified path resulting from traversal of each logical path, and compute the final output header space as the union of the output header spaces for the specified paths.

[0108] For each logical path, the LWVS 130 computes the header space for the specified path by sequentially applying the DM 122 of each network device 112 along the path from the source network device 112 to the destination network device 112 to the input BDD. Each DM 122 is a Boolean function represented by a respective BDD (referred to as a DM BDD). The DM BDD models how the respective network device 112 processes a received data packet, e.g., by forwarding the data packet through a particular output port, or by blocking the data packet (also referred to as dropping the data packet).

[0109] The LWVS 130 traverses one DM 122 at a time along a logical path, updating the header space as each DM 122 is applied. For clarity, the result of applying a given DM 122 to the header space is referred to herein as a device-specific output header space (represented by a device-specific output BDD); the header space obtained by traversing a given logical path from the source network device 112 to the destination network device 112 is referred to herein as a path-specific output header space (represented by a path-specific output BDD); and the header space obtained by traversing all possible logical paths from the source network device 112 to the destination network device 112 is referred to herein as the final output header space (or simply the output header space) (represented by a final output BDD).

[0110] It should be noted that the input to a given DM 122 (also referred to as a device-specific input header space) is the device-specific output header space from the previous DM 122 along the logical path (except for the special case where the given DM 122 corresponds to the source network device 112, in which case the device-specific input header space is simply the input header space defined for the query). For a given DM 122, the LWVS 130 computes the device-specific output header space (represented by a device-specific output BDD) by applying the given DM 122 to the device-specific input header space input into the given DM 122. Since both the DM 122 and the device-specific input header space are represented by BDDs, applying the DM 122 to the header space is equivalent to combining the device-specific input BDD with the DM BDD. That is, a logical AND (AND) operation is performed between the input BDD and the DM BDD, which is mathematically represented as follows:

[0111] Device-specific output BDD = (device-specific input BDD) Λ (DM BDD)

[0112] where Λ denotes the logical AND (AND) operation.

[0113] In this way, each DM BDD is sequentially applied (although the order can be interrupted) one at a time along the logical path from the source network device 112 to the destination network device 112. Since only one DM BDD is applied at a time, the memory resources of the LWVS 130 can be reused for the next DM BDD encountered on the logical path after the LWVS 130 has already computed the device-specific output BDD for the given DM BDD (e.g., using the computation described above). In some examples, the LWVS 130 is capable of processing multiple logical paths in parallel.

[0114] At 514, the final output header space output by the destination network device 112 (as defined by the query) is reported as the reachable header space for the query. The final output header space can be reported in the form of a final output BDD.

[0115] At 516, the reported output BDD is compared to the expected output BDD to verify the network property of interest. In some cases, the verification indicates that the network is operating as expected, while in other cases, the verification reveals a positive or negative deviation from the expected network performance. For example, if the network property of interest is reachability, the expected output BDD can be the original input BDD defined at the beginning of the query. If the reported output BDD is reduced compared to the original input BDD, it can indicate that reachability for all packets and all network devices 112 is not satisfied. It is 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 report shows a reduction in header space, the problem of packet drop can be identified at a particular DM 122 (and a corresponding particular network device 112). For example, by using BDD operations, the device-specific output header space can be compared to the device-specific input header space at each DM 122 to identify whether any header space is dropped at a particular DM 122.

[0116] Figure 6 An exemplary implementation of the method 500 is shown in use in a simplified logical topology. The logical topology includes four DMs 122, DM-A 122A, DM-B 122B, DM-C 122C, and DM-D 122D (corresponding to network device A 112A, network device B 112B, network device C 112C, and network device D 112D, respectively), each of which is encoded using a respective BDD. For ease of discussion, Figure 6 The network property verified in the example implementation has reachability, and network device A 112A and network device D 112D have been identified as border devices. A first query can be defined with network device A 112A as the source device and network device D 112D as the destination device (correspondingly, DM-A 122A is the source DM and DM-D 122D is the destination DM); a second query can be defined with network device D 112D as the source device and network device A 112A as the destination device (correspondingly, DM-D 122D is the source DM and DM-A 122A is the destination DM). Verification and use of other queries for other network properties of interest can be performed in a manner similar to that described below.

[0117] As Figure 6As shown in the example topology diagram, the logical path from DM-A 122A to DM-D 122D (i.e., Path 1) can be different from the logical path from DM-D 122D to DM-A 122A (i.e., Path 2) (e.g., DM-C 122C and DM-B 122B can represent unidirectional routing devices).

[0118] The input header space (denoted as HS1) represents the space of all packet headers that can be input to DM-A 122A. In some examples, HS1 can represent the IP address range of external entities connected to NVD 110 through network device A 112A. In some examples, network device A 112A can use information collected from external entities to define HS1, and HS1 can be sent by network device A 112A to LWVS 130. Alternatively, LWVS 130 can use the information of external entities provided by network device A 112A to define HS1. Similarly, another input header space (denoted as HS4) represents the space of all packet headers that can be input to DM-D 122D.

[0119] The DMs along Path 1 are DM-A 122A, DM-C 122C, and DM-D 122D, and the output header space (denoted as HS3) for Path 1 is calculated as follows:

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

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

[0122] The DMs along Path 2 are DM-D 122D, DM-B 122B, and DM-A 122A, and the other output header space (denoted as HS5) for Path 2 is calculated as follows:

[0123] HS5 BDD = (HS4 BDD) Λ (DM-D BDD) Λ (DM-B BDD) Λ (DM-A BDD)

[0124] The output header spaces (denoted by HS3 BDD and HS5 BDD in this example) are reported as the result of the verification process, respectively.

[0125] The LWVS 130 compares the reported output header space to the expected output to verify the network properties of interest (e.g., to check reachability, the output header space is expected to be identical to the input header space for each query; other network properties can be verified by performing other appropriate comparison procedures). If the reported output header space is different from the expected, it indicates that there is a failure (e.g., a device is unreachable) in the network. In some examples, a reference number can be assigned for the query being performed, the input header space for the query can be associated with the reference number assigned for the query, and each reported output header space can be associated with the reference number assigned for the query. In this way, each reported output header can be compared to the appropriate input header space to identify any failures (e.g., any dropped header space).

[0126] In this example, there is no dropped header space on path 2, and the output HS5 is identical to the input HS4 as expected. Thus, the LWVS 130 determines that there is no failure on path 2. However, there is one dropped header space (i.e., HS2) on path 1. This means that, for HS2, the invariance of reachability is not supported; however, the packets belonging to HS3 are able to reach the destination along path 1. The LWVS 130 can identify the dropped header space (i.e., HS2 in this example) by comparing the output HS3 and the input HS1. To identify the source of the failure, the LWVS 130 can transmit the dropped header space along path 1 through the individual DMs 122 and check the device-specific output header space at each DM 122. In this example, when the dropped header space passes through DM-C 122C, the device-specific output reported by DM-C 122C is a reduced or empty header space, indicating that DM-C 122C is the source of the failure. By modeling the network devices 112 as individual DMs 122, the verification procedure is able to identify the source of the failure in a more precise manner.

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

[0128] In the above-described partially distributed network verification method, each network device 112 is responsible for determining its own transfer function and generating its own DM 122. There is no need for a central entity to collect raw data about the state or configuration at the network devices 112. This can reduce or eliminate the need for a time-consuming data collection process. Before being transmitted to the LWVS 130, the information of the state and configuration of the network devices 112 is first encoded as a BDD. Thus, the raw data of the device configuration and state are not directly exposed to possible external detection, which can reduce or eliminate the risk of data theft, thereby improving the security of the verification process.

[0129] Because the DMs 122 are generated in a distributed manner, the generation of the DMs can be done in a parallel and asynchronous manner. This can help reduce the time needed for DM generation, help reduce the burden of computing resources at the central entity, and help ensure that each DM 122 is updated immediately or soon after a state or configuration change at the network device 112. The distributed DM generation approach also helps improve scalability, as generating a DM 122 for a large network with a large number of network devices 112 is not limited by the computing resources at the central entity.

[0130] The disclosed network verification method can also dynamically generate different logical topologies for verifying different aspects of the NVD 110. For example, different logical topologies can be defined according to a particular routing protocol (e.g., BGP), network layer (e.g., Layer 2 topology), etc. The LWVS 130 can also define the NVD 110 according to the verification needed. In this way, the LWVS 130 is able to verify a particular part of the network or a single mechanism of interest.

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

[0132] Further, after traversing the device-level BDDs in the logical topology, the memory resources used to store the device-level BDDs can be reused for the next device-level BDD on the logical path. Thus, the maximum size of the BDDs that need to be processed at any time (and the amount of computational and memory resources required for that processing step) corresponds to the most complex network device in the network (e.g., the network device with the most NEs). The upper bound on the complexity of the BDDs depends on the device level, and does not increase as the network size increases. This enables higher scalability, as increasing the network size does not cause the processing of the BDDs to exceed the computational or memory resources.

[0133] Because the verification is traversing the network at the device level, rather than a single network-level BDD, it is possible to determine the source and more specific information of a network fault. For example, if there is a packet loss issue in the network (e.g., the reported output header space shows a decrease in header space when the verification is performed), it is possible to identify the specific network device where the packet drop issue is occurring.

[0134] In some examples, the above partially distributed network verification approach can be modified to be fully distributed by distributing the functionality of the LWVS 130 to the network devices 112.

[0135] In the disclosed fully distributed network verification example, there is no central entity (e.g., the LWVS described above). All operations in the verification process, including generating the DMs and using the DMs to compute the output header space, are performed by the network devices 112 (e.g., implementing respective DVs 114).

[0136] Figure 7 A simple example of a fully distributed verification architecture 700 that can be used to implement the examples described herein is shown. The disclosed verification architecture 700 includes the NVD 110 and the network devices 112, similar to the example architecture 100 in Figure 1 In Figure 7 the DMs 122 and the verification data 126 reside on the DVs 114. It should be understood that this is intended to illustrate that each DV 114 manages a respective local DM 122 and local verification data 126. However, it should be understood that the DMs 122 and the verification data 126 can be stored in a centralized manner, and accessed by the DVs 114 as needed. Figure 7The illustrations in the figures are not necessarily reflective of physical implementations (e.g., the local DM 122 and the local verification data 126 can be stored in local memory of the network device 112, rather than in the DV 114). The network devices 112 at the boundary of the defined NVD 110 (also referred to as border devices) are the access points for traffic to the NVD 110. In some examples, a network controller or administrator can define the NVD 110 and can configure the network devices 112 to identify whether a given network device 112 is a border device. In other examples, the network devices 112 can use a peer-to-peer protocol (e.g., Link Layer Discovery Protocol (LLDP) or BGP) to identify direct neighbors and define the topology of the NVD 110 in a distributed manner. The input header space represents the space of all possible traffic related to the network property of interest, which can be notionally input to the NVD 110 at the border devices.

[0137] There is no central entity in the fully distributed verification architecture 700. Instead, each network device 112 maintains a respective local set of verification data in addition to generating and maintaining a respective local DM 122, which includes verification data 126a, 126b, 126c, 126d (generally referred to as local verification data 126). The network device 112 can use the local verification data 126 to track its own device-specific input header space and device-specific output header space. For example, the network device 112 can maintain the local verification data 126 as a table, where each table entry (i.e., row) of the table includes: an identification of an ingress port that receives a device-specific input header space; an identification of an egress port that sends a device-specific output header space; the received device-specific input header space; the sent device-specific output header space; an identification of a logical path traversed by the device-specific input header space. The identifier of the logical path can be created, for example, by concatenating identifiers of the DVs 114 corresponding to the network devices 112 encountered in the logical path (any other suitable technique can be used to encode the logical path). For example, the reported output header space can include an identifier of the logical path traversed using the device-specific input header space. In some examples, the logical path can be similarly tracked and reported using a partially distributed network verification approach (i.e., refer to the description of Figure 1

[0138] For example, a table entry maintained by a given network device 112 can be as follows:

[0139]

[0140]

[0141] ​The above example shows that the device-specific input header space is the HS4 received at ingress port 1. The HS4 has traversed DVa (corresponding to network device 112a) and then DVc (corresponding to network device 112c) before. The result of applying the local DM 122 is the device-specific output header space HS5 sent through egress port 2.

[0142] In a fully distributed network verification, each network device 112 generates its own local DM 122 to represent the behavior of the respective network device 112. The network devices 112 can generate the DMs using a similar approach to the partially distributed network verification method, but omit any communication with a central entity, e.g., using steps 304-312 described above.

[0143] Figure 8 A flowchart illustrating an example method 800 for network verification is shown, which can be performed by a given network device 112 implementing a DV 114 (e.g., the computing system 220 executing the instructions 238 using the processor device 225 to implement the method 800). For example, the steps of the method 800 can be encoded as operations to be performed by the DV 114 residing on the given network device 112. The method 800 can be performed at preconfigured time intervals (e.g., based on a verification clock that is synchronized across all DVs 114). The method 800 can also be performed in response to a trigger, e.g., when the local DM 122 at the network device 112 has been updated (e.g., in response to a change in the state or configuration of the network device 112). The steps of the method 800 are now discussed in the context of the given network device 112.

[0144] Optional step 802 can be performed at the first time network validation is initiated. At optional step 802, a given network device 112 can initialize itself. The initialization performed by the given network device 112 can include establishing point-to-point connections with directly adjacent network devices 112 (i.e., network devices 112 that have a direct logical and / or physical connection with the given network device 112). The point-to-point connections (also referred to as peer-to-peer connections or peer-to-peer links) can be maintained over a direct physical link or a logical link (e.g., using Internet Protocol Security (IPsec), Generic Routing Encapsulation (GRE), or Virtual Extensible Local Area Network (VXLAN) tunneling). Any suitable mechanism, such as Open Settlement Protocol (OSP) or BGP, can be used to establish the point-to-point connections. Similarly, any suitable protocol, including Transmission Control Protocol (TCP), OSP, or BGP, can be used for event monitoring and data exchange between network devices 112 during validation. Any suitable topology discovery protocol, such as LLDP, can be used to discover adjacent network devices 112 and establish point-to-point connections. Alternatively, the topology can be pre-configured (e.g., as in BGP).

[0145] The initialization can also include each network device 112 synchronizing validation clocks with its adjacent network devices 112 for data collection. This can include synchronizing data collection frequency and / or time intervals (e.g., depending on the desired validation policy), which helps ensure that the validation is able to reflect the state and configuration of all network devices 112 at the same (or approximately the same) time. To ensure a consistent state of the NVD 110, all network devices 112 should use the same variable definitions with the same header space order (e.g., configured by an administrator or network controller for all network devices 112). The validation process should only continue after the NVD 110 is in a stable or converged state.

[0146] Optionally, if the given network device 112 is being initialized or needs to update the local DM 122 (e.g., if the state or configuration of the network device 112 has changed), at step 804, the given network device 112 can collect data and generate a local DM 122 (e.g., using steps 304-312 described above). The generated local DM 122 can be encoded in BDD format or binary tree (or prefix tree) format, stored locally by the given network device 112.

[0147] In some examples, initializing a given network device 112 and generating a local DM 122 can be performed prior to method 800, and not as part of method 800.

[0148] At 806, the given network device 112 obtains a device-specific input header space. For example, an administrator or network controller can configure the given network device 112 as a border device, and can define a query (including defining the given network device 112 as a source device and another network device 112 as a destination device) to generate the input header space for the given network device 112 (e.g., using configuration information for the external environment). For example, the given network device 112 can collect configuration information for the connected external LAN or configuration information for static external routes.

[0149] If the given network device 112 is not a border device, the device-specific input header space can be obtained by receiving the device-specific input header space from an adjacent network device 112 at an ingress port of the given network device 112.

[0150] At 808, the given network device 112 computes a device-specific output header space by applying its local DM 122 to the device-specific input header space. If the verified network property is reachability, the computed device-specific output header space can be referred to as a reachability header space.

[0151] At 810, the computed device-specific output header space is stored in the local verification data of the given network device 112 (e.g., in the local memory 228 of the network device 112). The network device 112 stores a record in the local verification data 126 that indicates the ingress port that received the device-specific input header space, the device-specific input header space, the logical path traversed by the device-specific input header space (prior to reaching the given network device 112), the computed device-specific output header, and the egress port that sent the device-specific output header space. The stored record enables the network device 112 to compute whether there are any faults (e.g., dropped header spaces) locally, and enables the network device 112 to retrieve results of previous queries (e.g., in response to a request from an administrator or network controller, or if the same query is repeated).

[0152] At 812, the computed device-specific output header space is sent out each egress port of the network device 112. The device-specific output header space is sent to each neighboring network device 112 with which the network device 112 has established a point-to-point connection. The network device 112 can also add an identifier of its own DV 114 to the identification of the logical path and send the logical path identifier along with the device-specific output header space. For example, the network device 112 can concatenate the identifier of its own DV 114 to the end of the logical path identifier. If the computed device-specific output header space is empty, a message with the zero space is sent to the neighboring network device 112. The neighboring network device 112 that receives the input header space of zero space can act as a relay, simply transmitting the zero space to its respective neighboring network device 112.

[0153] In addition to transmitting the device-specific output header space, the given network device 112 also transmits the original device-specific input header space obtained at step 806, along with the logical path through which the original device-specific input header space has traveled. Thus, the given network device 112 also acts as a relay, as the input header space received through the ingress port is also transmitted through each egress port to the neighboring network devices 112. Transmitting the original input header space to the neighboring network devices 112 in a relay fashion enables the final destination device to obtain the initial input header space that was initiated at the source device, thereby enabling the final destination device to provide an end-to-end report for the query.

[0154] In some cases, if the given network device 112 is implementing a master DV, step 812 is not performed. The network device 112 implementing the master DV receives the header spaces from all neighboring network devices 112, but does not send any header spaces. For example, the role of the master DV can be configured by an administrator or a network controller. As described above, the network device 112 implementing the master DV performs all of the operations of a regular (i.e., non-master) DV. The network device 112 assigned the role of the master DV also performs the function of a reporting server. For example, when a query is completed at the destination device (and the address of the network device 112 as the master DV is configured on the destination device), the destination device reports the end-to-end result of the query to the master DV (the destination device can also store a copy of the result locally). The network device 112 as the master DV can then store the result of the query without applying the result to its own DM. In this way, the results of all queries can be stored on a single device. An administrator or network controller can then obtain the results of all queries from the master DV, rather than requesting the results from each individual destination device (as different queries can be conducted on different destination devices).

[0155] At 814, the network device 112 verifies the network attribute of interest using the stored local verification data. For example, the network device 112 can determine whether there are any failures (e.g., dropped header space) locally.

[0156] Figure 9 An exemplary implementation of the method 800 used in a simplified logical topology is shown. The logical topology reflects the connections between five network devices 112 (i.e., network device A 112A, network device B 112B, network device C 112C, network device D 112D, and network device E 112E) that implement respective DVs 114, i.e., DV-A 114A, DV-B 114B, DV-C 114C, DV-D 114D, and DV-E 114E (managing DM-A 122A, DM-B 122B, DM-C 122C, DM-D 122D, and DM-E 122E, respectively). A local verification data set of the respective verification data 126 resides on each respective network device 112. Each DM 122 can be represented by a respective BDD. The solid lines connecting the network devices 112 represent physical and / or logical connections between the respective network devices 112, and the dashed-line arrows represent the paths traversed by the header space. For ease of discussion, Figure 9 The network attribute verified in this example is reachability. Other network attributes of interest can be verified and other queries used in a manner similar to that described below. In this example, network device A 112A and network device D 112D are identified as border devices.

[0157] In Figure 9In the illustrated example, verification is performed starting from the input header space defined by network device A 112A, which is input into DM-A 122-A. The input header space defined by network device A 112A can be denoted as HS1, which is considered to be received through ingress port 1 (e.g., ingress port 1 is the interface with an entity outside of NVD 110). In this example, network device A 112A has two neighbors (i.e., network device C 112C and network device B 112B), to which it can reach through respective egress ports 2 and 3. Network device A 112A computes a device-specific output header space from the ingress port to each egress port, and sends the computed device-specific output header space through the respective port to each neighboring network device 112. The device-specific output header space denoted as HS2 is sent through egress port 2 to network device C 112C, and the device-specific output header space denoted as HS3 is sent through egress port 3 to network device B 112B. Network device A 112A also sends the path identifier and the original HS1 to each neighboring network device 112. The local verification data 126A of network device A 112A can store the following table entries:

[0158] Inlet port Outlet port Input HS Output HS Path 1 2 HS1 HS2 Empty 1 3 HS1 HS3 Empty

[0159] Where the "empty" value for the path indicates that network device A 112A itself is the beginning of a logical path in the logical topology.

[0160] In a similar manner, header spaces are transmitted to other network devices 112 in the logical topology. For example, network device B 112B applies its local DM-B 122B to compute an output header space denoted as HS6, and sends HS6 to network device E 112E along with the path identifier (the identifier of DV-B has been added to the path) and the received HS1 and HS3. The local verification data 126B of network device B 112B can store the following table entries:

[0161] Inlet port Outlet port Input HS Output HS Path 1 2 HS3 HS6 DV-A

[0162] Network device C 112C applies its local DM-C 122C to compute an output header space denoted as HS4, and sends HS4 to network device D 112D along with the path identifier (the identifier of DV-C has been added to the path) and the received HS1 and HS2. The local verification data 126C of network device C 112C can store the following table entries:

[0163] Inlet port Outlet port Input HS Output HS Path 1 2 HS2 HS4 DV-A

[0164] Network device D 112D receives HS4. Network device D 112D applies its local DM-D 122D to compute an output header space, denoted as HS5, and sends HS5 to network device E 112E along with the path identifier (the identifier of DV-D has been added to the path) and the received HS1, HS2, and HS4. The local verification data 126D of network device D 112D can store the following table entry:

[0165] Inlet port Outlet port Input HS Output HS Path 1 2 HS4 HS5 DV-A, DV-C

[0166] In this example, network device E 112E has been assigned the role of master DV. Therefore, network device E 112E does not transmit header spaces to any other network device 112. The header spaces received by network device E 112E and their associated paths can be stored in local verification data 126E, as follows:

[0167]

[0168] Network device E 112E also receives header spaces sent by neighboring network devices 112 in a relay fashion, and can also store this information in local verification data 126E. For example, network device E 112E can store the end-to-end results of a query in a table as described above (e.g., the initial input header space for a query is stored on the source device, and the final output header space is stored on the destination device).

[0169] In a fully distributed network verification approach, there is no central entity to supervise the operations of all network devices 112. Instead, each network device 112 is responsible for managing its own operations. For example, each network device 112 can implement its respective DV 114 using a finite state machine (FSM).

[0170] Figure 10 For one example state diagram, the diagram illustrates example states and transitions of a FSM that a network device 112 can use to implement a DV 114. It should be understood that this is illustrative only, but the present disclosure is not limited thereto.

[0171] DV 114 starts in an initialization state 1002. While the DV 114 is in the initialization state 1002, initialization operations are performed, such as discovering point-to-point neighboring devices, establishing point-to-point connections with neighboring devices, and synchronizing clocks with neighboring devices. Upon completion of initialization, the synchronized clocks trigger a transition to a data collection start state 1004. In the data collection start state 1004, information about the state and configuration of the network device 112 (and logical entities within the network device 112) is collected, any updates to the local data are detected. If the network device 112 is a border device, information about the external environment is also collected. Upon completion of data collection, the DV 114 transitions to a model construction state 1008. During this state, the collected data is used to determine a Boolean function that represents the behavior of the network device 112, and the Boolean function is encoded in the local DM 122 (e.g., represented as a BDD). Upon completion of the local DM 122, the DV 114 stores the local DM 122 in local memory. Upon storing the local DM 122, the DV 114 transitions to a model ready state 1012. In the model ready state 1012, the network device 112 is ready to participate in fully distributed network verification.

[0172] While the DV 114 is in the model ready state 1012, if the state or configuration of the network device 112 changes, the DV 114 transitions back to the data collection start state 1004 to collect data for the changed state or configuration, and updates the local DM 122 to reflect the changed state or configuration.

[0173] When the device-specific input header state is obtained, the DV 114 transitions from the model ready state 1012 to a compute header space state 1014. For example, if the network device 112 is a border device, the device-specific input header state can be obtained by an administrator or network controller that can use information collected from the external environment to define the device-specific input header state of the network device 112. If the network device 112 is a non-border device, the device-specific input header state can be obtained by the network device 112 by receiving the device-specific input header state from a neighboring device. In the compute header space state 1014, the network device 112 computes its device-specific output header space (e.g., as described above). Upon computing the device-specific output header space, the network device 112 updates the local verification data to store the computed device-specific output header space (e.g., as described above).

[0174] After the local verification data is updated with the computed device-specific output header space, the network device 112 sends the computed device-specific output header space through each egress port. After the device-specific output header space is sent, the DV 114 transitions back to the model-ready state 1012. It should be noted that if the network device 112 is the destination device and has the role of the master DV, the sending of the device-specific output header space can be omitted and the master DV will directly transition to the model-ready state 1012.

[0175] In the fully distributed network verification examples disclosed herein, the verification can be performed in parallel by different network devices 112 as the header spaces are transmitted throughout the network. As a result, the model states and required resources for performing the verification can be distributed across the network devices 112, which helps to mitigate the state explosion problem and achieve higher scalability.

[0176] In some examples, the network devices 112 can generate a hierarchy-based DM 122 that includes models representing the behaviors of individual network entities within the respective network devices 122. Examples of using hierarchy-based models for network verification are described in U.S. Patent Application No. 17 / 080,112, entitled “Method and System for Network Verification Using Hierarchy-Based Models,” the entire contents of which are incorporated by reference in the present application. It should be understood that the partial and fully distributed network verification techniques disclosed herein are equally applicable to using hierarchy-based models.

[0177] It is also noted that, in some examples, rather than preparing a logical model representing the entire device (e.g., using the collected state and configuration data), a more detailed model can be derived using statistical data of previous faults and / or ranges of known changes in the network collected through various techniques known in the art (e.g., see Steffen et al., “Probabilistic verification of network configurations,” SIGCOMM’20). This can allow 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. This approach can reduce the resources required for model generation (e.g., required memory and / or required computation time).

[0178] In various examples, the present disclosure describes methods and systems for partial distributed network verification (e.g., using a central lightweight entity) and methods and systems for fully distributed network verification (i.e., without any central entity). Both partial and fully distributed network verification can be considered as distributed network verification.

[0179] In the disclosed distributed network verification method and system, at least the operations for data collection and model generation are distributed across individual network devices, instead of being performed by a central entity. The distributed approach has advantages over existing centralized network verification techniques. For example, the disclosed method and system for distributed network verification can achieve higher scalability and can mitigate the state explosion problem. The disclosed method and system for distributed network verification can also achieve higher data security.

[0180] In some examples, the disclosed method and system for distributed network verification can enable network verification to be performed in a more efficient manner (e.g., requiring less computation time) because at least some verification operations can be performed in parallel. Moreover, since device models are generated locally by each network device, changes to the state and / or configuration of a given network device can be reflected in an updated device model that is generated locally by the given network device. This can avoid the need to regenerate a model for the entire network. In a fully distributed example, a given network device is responsible for computing an updated device-specific output header space and sending it to its neighbors.

[0181] The disclosed method and system for distributed network verification can verify a portion (or a shard) of a network, or verify a specific network mechanism, without having to verify the entire network.

[0182] Compared to existing centralized network verification schemes, using a lightweight central entity (in the example of partially distributed network verification) or omitting any central entity (in the example of fully distributed network verification) is more cost-effective because the overhead associated with a central entity can be reduced or avoided.

[0183] The disclosed examples can be relatively easy to implement in existing computing systems. As discussed earlier, the disclosed method and system for distributed network verification can utilize some existing protocols for point-to-point communication. In some examples, data collection can be performed using existing tools, e.g., command-line queries.

[0184] The present disclosure describes a method for network verification that can verify a network by dynamically traversing a logical model (e.g., represented by a BDD) for each network device one by one, instead of traversing one aggregated model for the entire network. This approach helps mitigate the state explosion problem caused by model checking. After each device-level BDD is traversed, the verification service resets the BDD, reusing memory resources to process the next device-level BDD. Moreover, the maximum BDD that needs to be processed is capped at the device level, and does not increase as the size of the network increases. Therefore, the disclosed method has higher scalability compared to traditional verification methods.

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

[0186] Although the present disclosure describes methods and processes with steps performed in a certain order, one or more steps of the methods and processes can be omitted or changed, or performed in an order other than as described. Where appropriate, one or more steps can be performed concurrently.

[0187] Although the present disclosure is described in terms of methods, one skilled in the art will appreciate to implement the various aspects and features of the methods by various components, whether by hardware components, software, or any combination thereof. 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 a digital video disc (DVD), a CD-ROM, a universal serial bus (USB) flash disk, a removable hard disk, or other storage media. 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 the examples of the methods disclosed herein.

[0188] The present disclosure can be implemented in other specific forms without departing from the subject matter of the claims. The described exemplary embodiments are merely illustrative in all aspects and are not restrictive. Features selected from one or more of the above-described embodiments can be combined to create alternative embodiments not explicitly described, and it is understood that features suitable for such combinations are within the scope of the present disclosure.

[0189] All values and subranges within the disclosed ranges are also disclosed. In addition, although systems, devices, and processes disclosed and shown herein can include particular numbers of elements / components, the systems, devices, and components can be modified to include more or less of such elements / components. For example, although any element / component disclosed can be referred to in a singular sense, 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 appropriate technical alterations.

Claims

1. A method for verifying a network, characterized by, The method comprises: obtaining a respective device-level Binary Decision Diagram (BDD) from each network device in the network, the BDD representing a logical behavior of the respective network device with respect to a network property of interest; generating an input BDD for querying the network property of interest, wherein the input BDD represents an input header space representing possible packet headers received at a source device in a logical topology representing connections between the network devices; computing an output BDD for 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 as a reachable header space; comparing the reported output BDD to an expected output BDD to verify the network property of interest.

2. The method of claim 1, wherein, The method further comprises: sending a request for the respective device-level BDD to each network device; obtaining the respective device-level BDD in a respective response from the respective network device.

3. The method of claim 1, wherein, The method further comprises: defining the logical topology in accordance with the network property of interest, wherein the logical topology is defined using a topology graph, and the device-level BDDs are respective vertices in the topology graph.

4. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: obtaining at least one device-level BDD from a transmission from a respective network device, wherein the transmission is received without a request for the device-level BDD.

5. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: identifying at least one border device in the network devices, wherein the border device provides an interface between the network and one or more entities outside the network; obtaining information about the one or more entities outside the network from the at least one border device.

6. The method of claim 5, wherein, The information about the one or more entities outside the network is used to generate the input BDD.

7. A method for verifying a network, characterized by, The method comprises: obtaining a device-specific input Binary Decision Diagram (BDD) at a network device for querying a network property of interest, the device-specific input BDD representing a device-specific input header space representing possible packet headers received; computing a device-specific output BDD representing a device-specific output header space, wherein the device-specific output BDD is computed by applying the device-specific BDD to the device-specific input BDD; storing the device-specific input BDD and the device-specific output BDD; comparing the device-specific output BDD and the device-specific input BDD to verify the network property of interest of the network device.

8. The method of claim 7, wherein, The method further comprises: sending the device-specific output BDD to one or more neighboring devices having a direct physical or logical connection with the network device.

9. The method of claim 8, wherein, The method further comprises: identifying the one or more neighboring devices and establishing a point-to-point connection with each of the one or more neighboring devices.

10. The method according to any one of claims 7 to 9, characterized in that, The network device is a border device configured to provide an interface between the network and one or more entities outside the network, and obtaining the device-specific input BDD comprises: receiving the device-specific input BDD, the device-specific input BDD being generated using collected configuration information about the one or more entities outside the network.

11. The method according to any one of claims 7 to 9, characterized in that, Obtaining the device-specific input BDD comprises receiving the device-specific input BDD from a neighboring device having a direct physical or logical connection with the network device.

12. The method according to any one of claims 7 to 9, characterized in that, The method further comprises: collecting data about the state and configuration of network entities in the network device; modeling each network entity as a respective Boolean function and encoding the respective Boolean function as a respective BDD; logically combining the respective BDDs to obtain a device-level BDD, wherein the device-level BDD is a model representing the logical behavior of the network device; storing the device-level BDD.

13. The method of claim 12, wherein, The method further comprises: synchronizing a validation clock with one or more neighboring devices, wherein the validation clock defines a synchronized timing for data collection.

Images