AdamMC: A Model Checker for Petri Nets with Transits against Flow-LTL

The correctness of networks is often described in terms of the individual data flow of components instead of their global behavior. In software-defined networks, it is far more convenient to specify the correct behavior of packets than the global behavior of the entire network. Petri nets with transits extend Petri nets and Flow-LTL extends LTL such that the data flows of tokens can be tracked. We present the tool AdamMC as the first model checker for Petri nets with transits against Flow-LTL. We describe how AdamMC can automatically encode concurrent updates of software-defined networks as Petri nets with transits and how common network specifications can be expressed in Flow-LTL. Underlying AdamMC is a reduction to a circuit model checking problem. We introduce a new reduction method that results in tremendous performance improvements compared to a previous prototype. Thereby, AdamMC can handle software-defined networks with up to 82 switches.


Introduction
In networks, it is difficult to specify correctness in terms of the global behavior of the entire system.Instead, the individual flow of components is far more convenient to specify correct behavior.For example, loop and drop freedom can be easily specified for the flow of each packet.Petri nets and LTL lack this local view.Petri nets with transits and Flow-LTL have been introduced to overcome this restriction [10].A transit relation is introduced to follow the flow induced by tokens.Flow-LTL is a temporal logic to specify both the local flow of data and the global behavior of markings.The global behavior as in Petri nets and LTL is still important for maximality and fairness assumptions.In this paper, we present the tool AdamMC3 as the first model checker for Petri nets with transits against Flow-LTL and its application to software-defined networking.
In Fig. 1, we present an example of a Petri net with transits that models the security check at an airport where passengers are checked by a security guard.The number of passengers entering the airport is unknown in advance.Rather than introducing the complexity of an infinite number of tokens, we use a fixed number of tokens to model possibly infinitely many flow chains.This is done by the transit relation which is depicted with colored arrows.
The left-hand side of Fig. 1 models passengers who want to reach the terminal.There are three tokens in the places airport, queue, and terminal.Thus, transitions start and en are always enabled.Each firing of start creates a new flow chain as depicted by the green arrow.This models a new person arriving at the airport.Meanwhile, the double-headed blue arrow maintains all flow chains that are still in place airport.Passengers have to enter the queue and wait until the security check is performed.Therefore, transition en continues every flow chain in airport to queue.Checking the passengers is carried out by transition check which becomes enabled if the security guard work s.Thus, passengers residing in queue have to wait until the guard check s them.Afterwards, they reach the terminal.The security guard is modeled on the right-hand side of Fig. 1.By firing comeToWork and thus moving the token in place home, her flow chain starts and she can repeatedly either idle or work, check passengers, and return.Her transit relation is depicted in orange and models exactly one flow chain.
In Fig. 1, we define the checkpoints cp 1 and cp 2 and the booth as a security zone and require that passengers never enter the security zone and eventually reach the terminal.The flow formula ϕ = A(airport → ( ¬(cp 1 ∨ cp 2 ∨ booth) ∧ terminal)) specifies this.AdamMC verifies the example from Fig. 1 against the formula check → ϕ specifying that if passengers are checked regularly then they cannot access the security zone and eventually reach the terminal.
In this paper, we present AdamMC as a full-fledged tool.First, AdamMC can handle Petri nets with transits and Flow-LTL formulas in general.Second, AdamMC has an input interface for a concurrent update and a software-defined network and encodes both of them as a Petri nets with transits.Common as-sumptions on fairness and requirements for network correctness are also provided as Flow-LTL formulas.This allows users of the tool to model check the correctness of concurrent updates and to prevent packet loss, routing loops, and network congestion.Third, AdamMC provides algorithms to check safe Petri nets against LTL with both places and transitions as atomic propositions which makes it especially easy to specify fairness and maximality assumptions.
The tool reduces the model checking problem for safe Petri nets with transits against Flow-LTL to the model checking problem for safe Petri nets against LTL.We develop the new parallel approach to check global and local behavior in parallel instead of sequentially.This approach yields a tremendous speed-up for a few local requirements and realistic fairness assumptions in comparison to the sequential approach of a previous prototype [10].In general, the parallel approach has worst-case complexity inferior to the sequential approach even though the complexities of both approaches are the same when using only one flow formula.
As last step, AdamMC reduces the model checking problem of safe Petri nets against LTL to a circuit model checking problem.This is solved by ABC [2,4] with effective verification techniques like IC3 and bounded model checking.AdamMC verifies concurrent updates of software-defined networks with up to 38 switches (31 more than the prototype) and falsifies concurrent updates of software-defined networks with up to 82 switches (44 more than the prototype).
The paper is structured as follows: In Sec. 2, we recall Petri nets with transits and Flow-LTL.In Sec. 3, we outline the three application areas of AdamMC: checking safe Petri nets with transits against Flow-LTL, checking concurrent updates of software-defined networks against common assumptions and specifications, and checking safe Petri nets against LTL.In Sec. 4, we algorithmically encode concurrent updates of software-defined networks in Petri nets with transits.In Sec. 5, we introduce the parallel approach for the underlying circuit model checking problem.In Sec. 6, we present our experimental evaluation.

Petri Nets With Transits and Flow-LTL
A safe Petri net with transits N = (P, T, F, In, Υ ) [10] contains the set of places P, the set of transitions T, the flow relation F ⊆ (P×T)∪(T ×P), and the initial marking In ⊆ P as in safe Petri nets [27].In a safe Petri net, reachable markings contain at most one token per place.The transit relation Υ is for every transition t ∈ T of type Υ (t) ⊆ (pre N (t) ∪ { }) × post N (t).With p Υ (t) q, we define that firing transition t transits the flow in place p to place q.The symbol denotes a start and Υ (t) q defines that firing transition t starts a new flow for the token in place q.Note that the transit relation can split, merge, and end flows.A sequence of flows leads to a flow chain which is a sequence of the current place and the fired outgoing transition.Thus, Petri nets with transits can describe both the global progress of tokens and the local flow of data.
Flow-LTL [10] extends Linear-time Temporal Logic (LTL) and uses places and transitions as atomic propositions.It introduces A as a new operator which uses LTL to specify the flow of data for all flow chains.For Fig. 1, the formula A(booth → check ) specifies that the guard performs at least one check.We call formulas starting with A flow formulas.Formulas around flow formulas specify the global progress of tokens in the form of markings and fired transitions to formalize maximality and fairness assumptions.These formulas are called run formulas.Often, Flow-LTL formulas have the form run formula → flow formula.

Application Areas
AdamMC consists of modules for three application areas: checking safe Petri nets with transits against Flow-LTL, checking concurrent updates of softwaredefined networks against common assumptions and specifications, and checking safe Petri nets against LTL.The general architecture and workflow of the model checking procedure is given in Fig. 2. AdamMC is based on the tool Adam [14].
Petri Nets with Transits Petri nets with transits follow the progress of tokens and the flow of data.Flow-LTL allows to specify requirements on both.For Petri nets with transits and Flow-LTL (Input II), AdamMC extends a parser for Petri nets provided by APT [30], provides a parser for Flow-LTL, and implements two reduction methods to create a safe Petri net and an LTL formula.The sequential approach is outlined in [10] and the parallel approach in Sec. 5. Software-Defined Networks Concurrent updates of software-defined networks are the second application area of AdamMC.The tool automatically encodes an initially configured network topology and a concurrent update as a Petri net with transits.The concurrent update renews the forwarding table.We provide parsers for the network topology, the initial configuration, the concurrent update, and Flow-LTL (Input I).In Sec. 4, we present the creation of a Petri net with transits from the input and Flow-LTL formulas for common network properties like connectivity, loop freedom, drop freedom, and packet coherence.
Petri Nets AdamMC supports the model checking of safe Petri nets against LTL with both places and transitions as atomic propositions.It provides dedicated algorithms to check interleaving-maximal runs of the system.A run is interleaving-maximal if a transition is fired whenever a transition is enabled.Furthermore, AdamMC allows a concurrent view on runs and can check concurrencymaximal runs which demand that each subprocess of the system has to progress maximally rather than only the entire system.State-of-the-art tools like LoLA [32] and ITS-Tools [29] are restricted to interleaving-maximal runs and places as atomic propositions.For Petri net model checking (Input III), we allow Petri nets in APT and PNML format as input and provide a parser for LTL formulas.
The construction of the circuit in Aiger format [3] is defined in [11].MCHyper [15] is used to create a circuit from a given circuit and an LTL formula.This circuit is given to ABC [2,4] which provides a toolbox of modern hardware verification algorithms like IC3 and bounded model checking to decide the initial model checking question.As output for all three modules, AdamMC transforms a possible counterexample (CEX) from ABC into a counterexample to the Petri net (with transits) and visualizes the net with Graphviz and the dot language [9].When no counterexample exists, AdamMC verified the input successfully.

Verifying Updates of Software Defined Networks
We show how AdamMC can check concurrent updates of realistic examples from software-defined networking (SDN) against typical specifications [19].SDN [25,6] separates the data plane for forwarding packets and the control plane for the routing configuration.A central controller initiates updates which can cause problems like routing loops or packet loss.AdamMC provides an input interface to automatically encode software-defined networks and concurrent updates of their configuration as Petri nets with transits.The tool checks requirements like loop and drop freedom to find erroneous updates before they are deployed.

Network Topology, Configurations, and Updates
A network topology T is an undirected graph T = (Sw , Con) with switches as vertices and connections between switches as edges.Packets enter the network at ingress switches and they leave at egress switches.Forwarding rules are of the form x.fwd(y) with x, y ∈ Sw .A concurrent update has the following syntax: where a switch update can renew the forwarding rule of switch x from switch z to switch y, introduce a new forwarding rule from switch x to switch y, or remove an existing forwarding rule from switch x to switch z.

Data Plane and Control Plane as Petri Net with Transits
For a network topology T = (Sw , Con), a set of ingress switches, a set of egress switches, an initial forwarding table, and a concurrent update, we show how data and control plane are encoded as Petri net with transits.Switches are modeled by tokens remaining in corresponding places s whereas the flow of packets is modeled by the transit relation Υ .Specific transitions i s model ingress switches where new data flows begin.Tokens in places of the form x.fwd(y) configure the forwarding.Data flows are extended by firing transitions (x,y) corresponding to configured forwarding without moving any tokens.Thus, we model any order of newly generated packets and their forwarding.Assuming that each existing direction of a connection between two switches is explicitly given in Con, we obtain Algorithm 1 which calls Algorithm 2 to obtain the control plane.Algorithm 2: Control plane For the update, let SwU be the set of switch updates in it, SeU the set of sequential updates in it, and PaU the set of parallel updates in it.Depending on update's type, it is also added to the respective set.The subnet for the update has an empty transit relation but moves tokens from and to places of the form x.fwd(y).Tokens in these places correspond to the forwarding table.The order of the switch updates is defined by the nesting of sequential and parallel updates.
Fig. 3: Overview of the sequential approach: Each firing of a transition of the original net is split into first firing a transition in the subnet for the run formula and subsequently firing a transition in each subnet tracking a flow formula.The constructed LTL formula skips the additional steps with until operators.
The update is realized by a specific token moving through unique places of the form u s , u f , s s , s f , p s , p f for start and finish of each switch update u ∈ SwU , each sequential update s ∈ SeU , and each parallel update p ∈ PaU .A parallel update temporarily increases the number of tokens and reduces it upon completion to one.Algorithm 2 defines the update behavior between start and finish places and connects finish and start places depending on the subexpression structure.

Assumptions and Requirements
We use the run formula pre (t) → t to assume weak fairness for every transition t in our encoding N. Transitions, which are always enabled after some point, are ensured to fire infinitely often.Thus, packets are eventually forwarded and the routing table is eventually updated.We use flow formulas to test specific requirements for all packets.Connectivity (A( s∈egress s)) ensures that all packets reach an egress switch.Packet coherence (A( ( s∈initial s) ∨ ( s∈final s))) tests that packets are either routed according to the initial or final configuration.Drop freedom (A ( e∈egress ¬e → f ∈Con f )) forbids dropped packets whereas loop freedom (A ( s∈Sw \egress s → (s U ¬s))) forbids routing loops.We combine run and flow formula into fairness → requirement.

Algorithms and Optimizations
Central to model checking a Petri net with transits N against a Flow-LTL formula ϕ is the reduction to a safe Petri net N > and an LTL formula ϕ > .The infinite state space of the Petri net with transits due to possibly infinitely many flow chains is reduced to a finite state model.The key idea is to guess and track a violating flow chain for each flow subformula A ψ i , for i ∈ {1, . . ., n}, and to only once check the equivalent future of flow chains merging into a common place.
AdamMC provides two approaches for this reduction: Fig. 3 and Fig. 4 give an overview of the sequential approach and the parallel approach, respectively.Both algorithms create one subnet N > i for each flow subformula A ψ i to track the corresponding flow chain and have one subnet N > O to check the run part of the formula.The places of N > O are copies of the places in N such that the current state of the system can be memorized.The subnets N > i also consist of the original places of N but only use one token (initially residing on an additional Fig. 4: Overview of the parallel approach: The n subnets are connected such that for every transition t ∈ T there are (|Υ (t)| + 1) n transitions, i.e., there is one transition for every combination of which transit of t (or none) is tracked by which subnet.We use until operators in the constructed LTL formula to only skip steps not involving the tracking of the guessed chain in the flow formula.place) to track the current state of the considered flow chain.The approaches differ in how these nets are connected to obtain N > .Sequential Approach The places in each subnet N > i are connected with one transition for each transit (T fl = t∈T Υ (t)).An additional token iterates sequentially through the subnets to activate or deactivate the subnet.This allows each subnet to track a flow chain corresponding to firing a transition in N > O .The formula ϕ > takes care of these additional steps by means of the until operator: In the run part of the formula, all steps corresponding to moves in a subnet N > i are skipped and, for each subformula A ψ i , all steps are skipped until the next transition of the corresponding subnet is fired which transits the tracked flow chain.This technique results in a polynomial increase of the size of the Petri net and the formula: We refer to [11] for formal details.Parallel Approach The n subnets are connected such that the current chain of each subnet is tracked simultaneously while firing an original transition t ∈ T. Thus, there are (|Υ (t)| + 1) n transitions.Each of these transitions stands for exactly one combination of which subnet is tracking which (or no) transit.Hence, firing one transition of the original net is directly tracked in one step for all subnets.This significantly reduces the complexity of the run part of the constructed formula, because no until operator is needed to skip sequential steps.A disjunction over all transitions corresponding to an original transition suffices to ensure correctness of the construction.Transitions and next operators in the flow parts of the formula still have to be replaced by means of the until operator to ensure that the next step of the tracked flow chain is checked at the corresponding step of the global timeline of ϕ > .In general, the parallel approach results in an exponential blow-up of the net and the formula: For the practical examples, however, the parallel approach allows for model checking Flow-LTL with few flow subformulas with a tremendous speed-up in comparison to the sequential approach.We refer to App.A for formal details.Optimizations Various optimizations parameters can be applied to the model checking routine described in Sec. 3 to tweak the performance.Table 1 gives an overview of the major parameters.We found that the versions of the sequential and the parallel approach with inhibitor arcs to track flow chains are generally Table 1: Overview of optimization parameters of AdamMC: The three reduction steps depicted in the first column can each be executed by different algorithms.The first step allows to combine the optimizations of the first and second row.faster than the versions without.Furthermore, the reduction step from a Petri net into a circuit with logarithmically encoded transitions had oftentimes better performance than the same step with explicitly encoded transitions.However, several possibilities to reduce the number of gates of the created circuit worsened the performance of some benchmark families and improved the performance of others.Consequently, all parameters are selectable by the user and a script is provided to compare different settings.An overview of the selectable optimization parameters can be found in the documentation of AdamMC [12].Our main improvement claims can be retraced by the case study in Sec. 6.

Evaluation
We conduct a case study based on SDN with a corresponding artifact [16].The performance improvements of AdamMC compared to the prototype [10] are summarized in Table 2.For realistic software-defined networks [19], one ingress and one egress switch are chosen at random.Two forwarding tables between the two switches and an update from the first to the second configuration are chosen at random.AdamMC verifies that the update maintained connectivity between ingress and egress switch.The results are depicted in rows starting with T. For rows starting with F, we required connectivity of a random switch which is not in the forwarding tables.AdamMC falsified this requirement for the update.The prototype implementation based on an explicit encoding can verify updates of networks with 7 switches and falsify updates of networks with 38 switches.We optimize the explicit encoding to a logarithmic encoding and the number of switches for which updates can be verified increases to 17.More significantly, the parallel approach in combination with the logarithmic encoding leads to tremendous performance gains.The performance gains of an approach with inferior worst-case complexity are mainly due to the smaller complexity of the LTL formula created by the reduction.The encoding of SDN requires fairness assumptions for each transition.These assumptions (encoded in the run part of the formula) experience a blow-up with until operators by the sequential approach but only need a disjunction in the parallel approach.Hence, the size of networks for which AdamMC can verify updates increases to 38 switches and the size for which it can falsify updates increases to 82 switches.For rather small networks, the tool needs only a few seconds to verify and falsify updates which makes it a great option for operators when updating networks.
Table 2: We compare the explicit and logarithmic encoding of the sequential approach with the parallel approach.The results are the average over five runs from an Intel i7-2700K CPU with 3.50 GHz, 32 GB RAM, and a timeout (TO) of 30 minutes.The runtimes are given in seconds.

Related Work
We refer to [21] for an introduction to SDN.Solutions for correctness of updates of software-defined networks include consistent updates [28,7], dynamic scheduling [17], and incremental updates [18].Both explicit and SMT-based model checking [5,23,22,31,1,26] is used to verify software-defined networks.Closest to our approach are models of networks as Kripke structures to use model checking for synthesis of correct network updates [8,24].The model checking subroutine of the synthesizer assumes that each packet sees at most one updated switch.Our model checking routine does not make such an assumption.There is a significant number of model checking tools (e.g., [32,29]) for Petri nets and an annual model checking contest [20].AdamMC is restricted to safe Petri nets whereas other tools can handle bounded and colored Petri nets.At the same time, only AdamMC accepts LTL formulas with places and transitions as atomic propositions.This is essential to express fairness in our SDN encoding.

Conclusion
We presented the tool AdamMC with its three application domains: checking safe Petri nets with transits against Flow-LTL, checking concurrent updates of software-defined networks against common assumptions and specifications, and checking safe Petri nets against LTL.New algorithms allow AdamMC to model check software-defined networks of realistic size: it can verify updates of networks with up to 38 switches and can falsify updates of networks with up to 82 switches.

(I) The initial marking is given by In
The sets T > , F > , and F > I are defined as the smallest sets fulfilling condition (t).The identifiers with the square brackets and those with a combination c in their index are fresh identifiers.We create an LTL formula ϕ > to the Petri net N > (created by Def. 1 of a Petri net with transits N = (P, T, F, In, Υ )) from a Flow-LTL formula ϕ with n ∈ N flow subformulas ϕ Fi = A ψ i .The intricate part of the construction is to deal with the different timelines.On the one hand, there is the global timeline of the Petri net N.This timeline can be used to check the run part of the formula.On the other hand, there are the different timelines of the possible infinite flow chains.For the flow chains, the global steps not concerning the chain have to be adequately skipped with until operators.Figure 5 gives an overview of a possible sequence of different timelines.
We define the set of transitions tracking a chain of a specific subnet i ∈ {1, . . ., n} by

and the set of all other transitions by
t} collects all corresponding transitions tracking a chain of the subnet.
First, the places of the flow subformulas have to be substituted by the corresponding places tracking the chain, i.e., all occurrences of a place p ∈ P in a flow subformula ϕ Fi are simultaneously replaced by [p] i .Second, the transitions of the flow subformulas have to be substituted such that all steps of the global timeline which do not involve the tracked flow chain are skipped until a transition involving the flow chain is fired, i.e., all occurrences of a transition t ∈ T in a flow subformula ϕ Fi are simultaneously substituted by ( to∈Oi t o ) U ( tm∈Mi(t) t m ).Similarly, the next operator of the flow subformulas have to be substituted such that the steps of the global timeline are skipped until a step involving the tracking subnet is taken.Here two cases have to be considered: either the chain ends, i.e., no transition of the subnet is ever fired again, then the formula has to directly hold in the stuttering part, or there is a transition of the subnet, then the formula has to hold in the direct successor state.This means all occurrences of a subformula φ in a flow subformula ϕ Fi are replaced from the inner-to the outermost occurrence by (( t∈Oi t) U (( For the run part of the formula, we can directly use the global timeline, i.e., the next operator needs no substitution.Further, the places are already correctly named.Only the transitions t ∈ T in the run part of ϕ have to be substituted simultaneously by t ∈{t ∈T > | λ(t )=t} t to allow for all transitions corresponding to t.
Finally, the flow subformulas are simultaneously substituted by [ι] i W(¬ [ι] i ∧ ψ i ) (where ψ i is the result of the above mentioned substitutions within a flow subformula) such that all steps of the global timeline are skipped until a flow chain is created and tracked.Table 3 gives an overview of these substitutions.Table 3: An overview of the necessary substitutions to create ϕ > from ϕ.The next operator is substituted from the innermost to the outermost occurrence, the other subformulas are substituted simultaneously.

Run part of ϕ
Flow subformula A ψi part of ϕ p ∈ P p The size of the constructed formula directly results from the blow-up of the number of transition during the creation of N > and the substitutions introducing the disjunctions over these transition in the creation of ϕ > .
Lemma 2 (Size of the Constructed Formula).The size of the constructed Note that there is only a significant blow-up in the formula when transitions are used as atomic propositions in either the flow or the run part of the formula or when the next operator is used in the flow part of the formula.Moreover, even the usage of transitions as atomic propositions in the run part of the formula only results in a blow-up by all combinations of transits of this transition regarding the subnets.In practical applications, this makes a huge difference compared to the sequential approach, because model checking is exponential in the size of the formula and many examples need fairness assumptions, i.e., transitions in the run part of the formula, and have only few local requirements.
The proof of the correctness of the transformations for the parallel approach is very similar to the one of the sequential approach presented in [11].We again can mutually transform the counterexample to show the contraposition N |= ϕ iff N > |= LTL ϕ > .Here we do not have to pump up the firing sequence serving as counterexample for N |= ϕ, but have to replace each transition by a transition which adequately extends all flow chains of the counterexample.For the other direction, we can replace the transitions of the counterexample by the labels of the transitions and, analog to the sequential approach, iteratively concatenate the transitions and places of the subnets to gain the flow chains serving as counterexamples for the subformula part.The complicated parts of the structural induction, i.e., adequately skipping the global time steps for the flow subformulas, can be done analogously because the formulas of the parallel approach and the sequential approach are similar in this case and fit to the different structure of the net.

B Complete Results
Table 4: We compare the explicit and the logarithmic encoding of the sequential approach with the parallel approach.The results are the average over 5 runs from an Intel i7-2700K CPU with 3.50 GHz, 32 GB RAM, and a timeout of 30 minutes.We report the runtimes of IC3 to verify (T) updates of softwaredefined networks and the runtimes of both BMC2 and BMC3 to falsify (F) updates of software-defined networks all with respect to connectivity between randomly chosen ingress and egress switches and forwarding tables.

Fig. 1 :
Fig. 1: Access control at an airport modeled as Petri net with transits.Colored arrows display the transit relation and define flow chains to model the passengers.

Fig. 5 :
Fig. 5: A possible sequence of the global timeline τ and the timelines of the possible infinite number of flow chains β i .A filled time step for a timeline of a flow chain indicates that the fired transition has a transit which extends this flow chain.
The results regarding the size of the constructed net directly follow from the definition and that there are|P| • |T| • |P| + |T| • |P| transits in the worst-case.Lemma 1 (Size of the Constructed Net).The constructed Petri net N > has O(|N| • n + |N|) places and O(|N| 3n + |N|) transitions.A.2 Construction of the Formula Transformation (Parallel Approach) Overview of the workflow of AdamMC: The application areas of the tool are given by three different input domains: software-defined network / Flow-LTL (Input I), Petri nets with transits / Flow-LTL (Input II), and Petri nets / LTL (Input III).AdamMC performs all unlabeled steps.MCHyper creates the final circuit which ABC checks to answer the initial model checking problem.