AdamMC: A Model Checker for Petri Nets with Transits against Flow-LTL (Full Version)
Bernd Finkbeiner, Manuel Gieseking, Jesko Hecking-Harbusch, Ernst-Rüdiger Olderog
CC o n s i s t e n t * C o m p l e t e * W e l l D o c u m e n t e d * E a s y t o R e u s e * * E v a l u a t e d * C A V * A r t i f a c t * A E C AdamMC : A Model Checker forPetri Nets with Transits against Flow-LTL(Full Version) ∗‡ Bernd Finkbeiner , Manuel Gieseking ,Jesko Hecking-Harbusch , and Ernst-R¨udiger Olderog Saarland University, Saarbr¨ucken, Germany { finkbeiner,hecking-harbusch } @react.uni-saarland.de University of Oldenburg, Oldenburg, Germany { gieseking,olderog } @informatik.uni-oldenburg.de Abstract.
The correctness of networks is often described in terms ofthe individual data flow of components instead of their global behavior.In software-defined networks, it is far more convenient to specify the cor-rect behavior of packets than the global behavior of the entire network.Petri nets with transits extend Petri nets and Flow-LTL extends LTLsuch that the data flows of tokens can be tracked. We present the tool
AdamMC as the first model checker for Petri nets with transits againstFlow-LTL. We describe how
AdamMC can automatically encode con-current updates of software-defined networks as Petri nets with transitsand how common network specifications can be expressed in Flow-LTL.Underlying
AdamMC is a reduction to a circuit model checking prob-lem. We introduce a new reduction method that results in tremendousperformance improvements compared to a previous prototype. Thereby,
AdamMC can handle software-defined networks with up to 82 switches.
In networks, it is difficult to specify correctness in terms of the global behaviorof the entire system. Instead, the individual flow of components is far moreconvenient to specify correct behavior. For example, loop and drop freedom canbe easily specified for the flow of each packet. Petri nets and LTL lack this localview. Petri nets with transits and Flow-LTL have been introduced to overcomethis restriction [10]. A transit relation is introduced to follow the flow inducedby tokens.
Flow-LTL is a temporal logic to specify both the local flow of dataand the global behavior of markings. The global behavior as in Petri nets andLTL is still important for maximality and fairness assumptions. In this paper, ‡ This is the full version of [13]. ∗ This work was supported by the German Research Foundation (DFG) Grant PetriGames (392735815) and the Collaborative Research Center Foundations of Perspicu-ous Software Systems (TRR 248, 389792660), and by the European Research Council(ERC) Grant OSARES (683300). a r X i v : . [ c s . L O ] M a y B. Finkbeiner et al. airportstart queueen cp terminal cp check boothretwork homecomeToWorkidle Fig. 1: Access control at an airport modeled as Petri net with transits. Coloredarrows display the transit relation and define flow chains to model the passengers.we present the tool
AdamMC as the first model checker for Petri nets withtransits 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 thesecurity check at an airport where passengers are checked by a security guard.The number of passengers entering the airport is unknown in advance. Ratherthan introducing the complexity of an infinite number of tokens, we use a fixednumber of tokens to model possibly infinitely many flow chains . This is done bythe transit relation which is depicted with colored arrows.The left-hand side of Fig. 1 models passengers who want to reach the ter-minal. 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 newflow chain as depicted by the green arrow. This models a new person arriving atthe airport . Meanwhile, the double-headed blue arrow maintains all flow chainsthat are still in place airport . Passengers have to en ter the queue and wait untilthe security check is performed. Therefore, transition en continues every flowchain in airport to queue . Checking the passengers is carried out by transition check which becomes enabled if the security guard work s. Thus, passengers re-siding in queue have to wait until the guard check s them. Afterwards, they reachthe terminal . The security guard is modeled on the right-hand side of Fig. 1. Byfiring comeToWork and thus moving the token in place home , her flow chainstarts and she can repeatedly either idle or work , check passengers, and ret urn.Her transit relation is depicted in orange and models exactly one flow chain.In Fig. 1, we define the checkpoints cp and cp and the booth as a securityzone and require that passengers never enter the security zone and eventuallyreach the terminal . The flow formula ϕ = A ( airport → ( ¬ ( cp ∨ cp ∨ booth ) ∧ terminal )) specifies this. AdamMC verifies the example from Fig. 1 againstthe formula check → ϕ specifying that if passengers are checked regularlythen 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-definednetwork and encodes both of them as a Petri nets with transits. Common as- AdamMC is available online at https://uol.de/en/csd/adammc [12]. damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 3 sumptions on fairness and requirements for network correctness are also pro-vided as Flow-LTL formulas. This allows users of the tool to model check thecorrectness of concurrent updates and to prevent packet loss, routing loops, andnetwork congestion. Third,
AdamMC provides algorithms to check safe Petrinets against LTL with both places and transitions as atomic propositions whichmakes it especially easy to specify fairness and maximality assumptions.The tool reduces the model checking problem for safe Petri nets with transitsagainst 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 inparallel instead of sequentially. This approach yields a tremendous speed-up fora few local requirements and realistic fairness assumptions in comparison to thesequential approach of a previous prototype [10]. In general, the parallel approachhas worst-case complexity inferior to the sequential approach even though thecomplexities of both approaches are the same when using only one flow formula.As last step,
AdamMC reduces the model checking problem of safe Petri netsagainst 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 to38 switches (31 more than the prototype) and falsifies concurrent updates ofsoftware-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 transitsand Flow-LTL. In Sec. 3, we outline the three application areas of
AdamMC :checking safe Petri nets with transits against Flow-LTL, checking concurrentupdates of software-defined networks against common assumptions and specifi-cations, and checking safe Petri nets against LTL. In Sec. 4, we algorithmicallyencode concurrent updates of software-defined networks in Petri nets with tran-sits. In Sec. 5, we introduce the parallel approach for the underlying circuitmodel checking problem. In Sec. 6, we present our experimental evaluation.
A safe
Petri net with transits (cid:78) = ( (cid:80) , (cid:84) , (cid:70) , In , Υ ) [10] contains the set of places (cid:80) , the set of transitions (cid:84) , the flow relation (cid:70) ⊆ ( (cid:80) × (cid:84) ) ∪ ( (cid:84) × (cid:80) ), andthe initial marking In ⊆ (cid:80) as in safe Petri nets [27]. In a safe Petri net, reachablemarkings contain at most one token per place. The transit relation Υ is for everytransition t ∈ (cid:84) of type Υ ( t ) ⊆ ( pre (cid:78) ( t ) ∪ { (cid:66) } ) × post (cid:78) ( t ). With p Υ ( t ) q , wedefine that firing transition t transits the flow in place p to place q . The symbol (cid:66) denotes a start and (cid:66) Υ ( t ) q defines that firing transition t starts a new flowfor the token in place q . Note that the transit relation can split, merge, andend flows. A sequence of flows leads to a flow chain which is a sequence of thecurrent place and the fired outgoing transition. Thus, Petri nets with transitscan describe both the global progress of tokens and the local flow of data.Flow-LTL [10] extends Linear-time Temporal Logic (LTL) and uses placesand transitions as atomic propositions. It introduces A as a new operator whichuses LTL to specify the flow of data for all flow chains. For Fig. 1, the formula B. Finkbeiner et al.
CommonNetworkPropertiesTopologyInit. Conf.Update Petri NetwithTransitsFlow-LTLFormula ∨ LTLFormulaSafePetri Net Circuit(System) Circuit (cid:51)(cid:55) (CEX)MCHyper ABC
Input I Input II Input III
Fig. 2: Overview of the workflow of
AdamMC : The application areas of the toolare 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 finalcircuit which ABC checks to answer the initial model checking problem. A ( booth → check ) specifies that the guard performs at least one check. We callformulas starting with A flow formulas . Formulas around flow formulas specifythe global progress of tokens in the form of markings and fired transitions to for-malize maximality and fairness assumptions. These formulas are called run for-mulas . Often, Flow-LTL formulas have the form run formula → flow formula . AdamMC consists of modules for three application areas: checking safe Petrinets with transits against Flow-LTL, checking concurrent updates of software-defined networks against common assumptions and specifications, and checkingsafe Petri nets against LTL. The general architecture and workflow of the modelchecking 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 to-kens and the flow of data. Flow-LTL allows to specify requirements on both. ForPetri nets with transits and Flow-LTL (Input II),
AdamMC extends a parserfor Petri nets provided by APT [30], provides a parser for Flow-LTL, and im-plements 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 net-works are the second application area of
AdamMC . The tool automaticallyencodes an initially configured network topology and a concurrent update as aPetri net with transits. The concurrent update renews the forwarding table. Weprovide parsers for the network topology , the initial configuration , the concurrentupdate , and Flow-LTL (Input I). In Sec. 4, we present the creation of a Petrinet with transits from the input and Flow-LTL formulas for common networkproperties like connectivity , loop freedom , drop freedom , and packet coherence . Petri Nets
AdamMC supports the model checking of safe Petri nets againstLTL with both places and transitions as atomic propositions. It provides ded-icated algorithms to check interleaving-maximal runs of the system. A run is damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 5 interleaving-maximal if a transition is fired whenever a transition is enabled. Fur-thermore,
AdamMC allows a concurrent view on runs and can check concurrency-maximal runs which demand that each subprocess of the system has to progressmaximally 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 asatomic propositions. For Petri net model checking (Input III), we allow Petrinets 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]. MCHy-per [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 hardwareverification algorithms like IC3 and bounded model checking to decide the initialmodel checking question. As output for all three modules,
AdamMC transformsa possible counterexample (CEX) from ABC into a counterexample to the Petrinet (with transits) and visualizes the net with Graphviz and the dot language [9].When no counterexample exists,
AdamMC verified the input successfully.
We show how
AdamMC can check concurrent updates of realistic examples fromsoftware-defined networking (SDN) against typical specifications [19]. SDN [25,6]separates the data plane for forwarding packets and the control plane for therouting configuration. A central controller initiates updates which can causeproblems like routing loops or packet loss.
AdamMC provides an input interfaceto automatically encode software-defined networks and concurrent updates oftheir configuration as Petri nets with transits. The tool checks requirements likeloop and drop freedom to find erroneous updates before they are deployed. A network topology T is an undirected graph T = ( Sw , Con ) with switches asvertices and connections between switches as edges. Packets enter the networkat ingress switches and they leave at egress switches.
Forwarding rules are of theform x.fwd(y) with x , y ∈ Sw . A concurrent update has the following syntax:switch update ::= upd(x.fwd(y/z)) | upd(x.fwd(y/-)) | upd(x.fwd(-/z)) sequential update ::= ( update >> update >> ... >> update ) parallel update ::= ( update || update || ... || update ) update ::= switch update | sequential update | parallel updatewhere 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 removean existing forwarding rule from switch x to switch z . 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
B. Finkbeiner et al. and control plane are encoded as Petri net with transits. Switches are modeledby tokens remaining in corresponding places s whereas the flow of packets ismodeled by the transit relation Υ . Specific transitions i s model ingress switcheswhere new data flows begin. Tokens in places of the form x.fwd(y) configure theforwarding. Data flows are extended by firing transitions (x,y) correspondingto configured forwarding without moving any tokens. Thus, we model any orderof newly generated packets and their forwarding. Assuming that each existingdirection of a connection between two switches is explicitly given in Con , weobtain Algorithm 1 which calls Algorithm 2 to obtain the control plane. input : T = ( Sw , Con ), ingress , forwarding , update output: Petri net with transits (cid:78) = ( (cid:80) , (cid:84) , (cid:70) , In , Υ ) for update of topology T with ingress and forwarding create empty (cid:78) = ( (cid:80) , (cid:84) , (cid:70) , In , Υ ); for switch s ∈ Sw do add place s to (cid:80) ;add place s to In ; if s ∈ ingress then add transition i s to (cid:84) ;add s to pre ( i s ), post ( i s );add creating data flow (cid:66) Υ ( i s ) s to Υ ;add maintaining data flow s Υ ( i s ) s to Υ ; for connection ( x , y ) ∈ Con do add place x.fwd(y) to (cid:80) ; if x.fwd(y) ∈ forwarding then add place x.fwd(y) to In ;add transition ( x , y ) to (cid:84) ;add x , y , x.fwd(y) to pre (( x , y )), post (( x , y ));add connecting data flow x Υ (( x , y )) y to Υ ;add maintaining data flow y Υ (( x , y )) y to Υ ; (cid:78) = call Algorithm 2 with T , update , (cid:78) as input;add place update s to In ; Algorithm 1: Data plane input : T = ( Sw , Con ), update , (cid:78) output: (cid:78) = ( (cid:80) , (cid:84) , (cid:70) , In , Υ ) for switch update u ∈ SwU do // u = upd(x.fwd(y/z)) add places u s , u f to (cid:80) ;add transition u to (cid:84) ;add u s to pre ( u ), u f to post ( u ); if z (cid:54) = - then add x.fwd(z) to pre ( u ); if y (cid:54) = - then add x.fwd(y) to post ( u ); for sequential update s ∈ SeU do // s = [ s , ..., s i , ..., s | s | ]add places s s , s f to (cid:80) ; for i ∈ { , ..., | s |} do add transition s i to (cid:84) ; if i == 0 then add s s to pre ( s i ); else add s fi to pre ( s i ); if i = | s | then add s f to post ( s i ); else add s si +1 to post ( s i ); for parallel update p ∈ PaU do add places p s , p f to (cid:80) ;add transitions p o , p c to (cid:84) ;add p s to pre ( p o ), p f to post ( p c ); for sub-update u i of p do add u si to post ( p o ), u fi to pre ( p c ); Algorithm 2: Control planeFor the update , let
SwU be the set of switch updates in it,
SeU the set ofsequential updates in it, and
PaU the set of parallel updates in it. Dependingon 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 orderof the switch updates is defined by the nesting of sequential and parallel updates. damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 7 (cid:78) >O (cid:78) > (cid:78) >n . . . | (cid:84) | | (cid:84) | + | (cid:84) fl | | (cid:84) | + | (cid:84) fl || (cid:84) | + | (cid:84) fl | Fig. 3: Overview of the sequential approach : Each firing of a transition of theoriginal net is split into first firing a transition in the subnet for the run formulaand subsequently firing a transition in each subnet tracking a flow formula. Theconstructed LTL formula skips the additional steps with until operators.The update is realized by a specific token moving through unique places of theform u s , u f , s s , s f , p s , p f for start and finish of each switch update u ∈ SwU , eachsequential update s ∈ SeU , and each parallel update p ∈ PaU . A parallel updatetemporarily increases the number of tokens and reduces it upon completion toone. Algorithm 2 defines the update behavior between start and finish placesand connects finish and start places depending on the subexpression structure.
We use the run formula pre ( t ) → t to assume weak fairness for ev-ery transition t in our encoding (cid:78) . Transitions, which are always enabled aftersome point, are ensured to fire infinitely often. Thus, packets are eventuallyforwarded and the routing table is eventually updated. We use flow formulas totest specific requirements for all packets. Connectivity ( A ( (cid:87) s ∈ egress s )) ensuresthat all packets reach an egress switch. Packet coherence ( A ( ( (cid:87) s ∈ initial s ) ∨ ( (cid:87) s ∈ final s ))) tests that packets are either routed according to the initial or finalconfiguration. Drop freedom ( A ( (cid:86) e ∈ egress ¬ e → (cid:87) f ∈ Con f )) forbids droppedpackets whereas loop freedom ( A ( (cid:86) s ∈ Sw \ egress s → ( s U ¬ s ))) forbids rout-ing loops. We combine run and flow formula into fairness → requirement . Central to model checking a Petri net with transits (cid:78) against a Flow-LTLformula ϕ is the reduction to a safe Petri net (cid:78) > and an LTL formula ϕ > . Theinfinite state space of the Petri net with transits due to possibly infinitely manyflow chains is reduced to a finite state model. The key idea is to guess and track aviolating flow chain for each flow subformula A ψ i , for i ∈ { , . . . , n } , and to onlyonce check the equivalent future of flow chains merging into a common place. AdamMC provides two approaches for this reduction: Fig. 3 and Fig. 4 givean overview of the sequential approach and the parallel approach, respectively.Both algorithms create one subnet (cid:78) >i for each flow subformula A ψ i to trackthe corresponding flow chain and have one subnet (cid:78) >O to check the run part ofthe formula. The places of (cid:78) >O are copies of the places in (cid:78) such that the cur-rent state of the system can be memorized. The subnets (cid:78) >i also consist of theoriginal places of (cid:78) but only use one token (initially residing on an additional B. Finkbeiner et al. (cid:78) >O (cid:78) > (cid:78) >n . . . | (cid:84) | · ( | (cid:84) fl | + 1) n Fig. 4: Overview of the parallel approach : The n subnets are connected such thatfor every transition t ∈ (cid:84) there are ( | Υ ( t ) | + 1) n transitions, i.e., there is onetransition for every combination of which transit of t (or none) is tracked bywhich subnet. We use until operators in the constructed LTL formula to onlyskip 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 approachesdiffer in how these nets are connected to obtain (cid:78) > . Sequential Approach
The places in each subnet (cid:78) >i are connected with onetransition for each transit ( (cid:84) fl = (cid:83) t ∈ (cid:84) Υ ( t )). An additional token iterates se-quentially through the subnets to activate or deactivate the subnet. This allowseach subnet to track a flow chain corresponding to firing a transition in (cid:78) >O . Theformula ϕ > 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 (cid:78) >i are skipped and, for each subformula A ψ i , all steps are skipped until the nexttransition of the corresponding subnet is fired which transits the tracked flowchain. This technique results in a polynomial increase of the size of the Petrinet and the formula: (cid:78) > has O ( | (cid:78) | · n + | (cid:78) | ) places and O ( | (cid:78) | · n + | (cid:78) | )transitions and the size of ϕ > is in O ( | (cid:78) | · n · | ϕ | + | ϕ | ). We refer to [11] forformal details. Parallel Approach
The n subnets are connected such that the current chainof each subnet is tracked simultaneously while firing an original transition t ∈ (cid:84) .Thus, there are ( | Υ ( t ) | + 1) n transitions. Each of these transitions stands for ex-actly 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 sub-nets. This significantly reduces the complexity of the run part of the constructedformula, because no until operator is needed to skip sequential steps. A disjunc-tion over all transitions corresponding to an original transition suffices to ensurecorrectness of the construction. Transitions and next operators in the flow partsof the formula still have to be replaced by means of the until operator to ensurethat the next step of the tracked flow chain is checked at the corresponding stepof the global timeline of ϕ > . In general, the parallel approach results in an ex-ponential blow-up of the net and the formula: (cid:78) > has O ( | (cid:78) | · n + | (cid:78) | ) placesand O ( | (cid:78) | n + | (cid:78) | ) transitions and the size of ϕ > is in O ( | (cid:78) | n · | ϕ | + | ϕ | ). Forthe practical examples, however, the parallel approach allows for model checkingFlow-LTL with few flow subformulas with a tremendous speed-up in comparisonto the sequential approach. We refer to App. A for formal details. Optimizations
Various optimizations parameters can be applied to the modelchecking routine described in Sec. 3 to tweak the performance. Table 1 gives anoverview of the major parameters. We found that the versions of the sequentialand the parallel approach with inhibitor arcs to track flow chains are generally damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 9
Table 1: Overview of optimization parameters of
AdamMC : The three reductionsteps 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.
1) Petri Net with Transits (cid:32)
Petri Net sequential parallelinhibitor act. token inhibitor act. token2) Petri Net (cid:32)
Circuit explicit logarithmic3) Circuit (cid:32)
Circuit gate optimizations faster than the versions without. Furthermore, the reduction step from a Petrinet into a circuit with logarithmically encoded transitions had oftentimes betterperformance than the same step with explicitly encoded transitions. However,several possibilities to reduce the number of gates of the created circuit worsenedthe performance of some benchmark families and improved the performance ofothers. Consequently, all parameters are selectable by the user and a script isprovided to compare different settings. An overview of the selectable optimiza-tion parameters can be found in the documentation of
AdamMC [12]. Our mainimprovement claims can be retraced by the case study in Sec. 6.
We conduct a case study based on SDN with a corresponding artifact [16]. Theperformance improvements of
AdamMC compared to the prototype [10] aresummarized in Table 2. For realistic software-defined networks [19], one ingressand one egress switch are chosen at random. Two forwarding tables between thetwo switches and an update from the first to the second configuration are chosenat random.
AdamMC verifies that the update maintained connectivity betweeningress and egress switch. The results are depicted in rows starting with T. Forrows starting with F, we required connectivity of a random switch which is notin the forwarding tables.
AdamMC falsified this requirement for the update.The prototype implementation based on an explicit encoding can verify up-dates of networks with 7 switches and falsify updates of networks with 38switches. We optimize the explicit encoding to a logarithmic encoding and thenumber of switches for which updates can be verified increases to 17. More sig-nificantly, the parallel approach in combination with the logarithmic encodingleads to tremendous performance gains. The performance gains of an approachwith inferior worst-case complexity are mainly due to the smaller complexityof the LTL formula created by the reduction. The encoding of SDN requiresfairness assumptions for each transition. These assumptions (encoded in the runpart of the formula) experience a blow-up with until operators by the sequentialapproach but only need a disjunction in the parallel approach. Hence, the sizeof networks for which
AdamMC can verify updates increases to 38 switches andthe size for which it can falsify updates increases to 82 switches. For rather smallnetworks, the tool needs only a few seconds to verify and falsify updates whichmakes it a great option for operators when updating networks.
Table 2: We compare the explicit and logarithmic encoding of the sequentialapproach with the parallel approach. The results are the average over five runsfrom 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. expl. enc. log. enc. parallel appr.T / F Network Sw Alg. Time | = Alg. Time | = Alg. Time | =T Arpanet196912 4 IC3 12.08 (cid:51) IC3 9.89 (cid:51)
IC3 (cid:51)
T Napnet 6 IC3 146.49 (cid:51)
IC3 96.06 (cid:51)
IC3 (cid:51) · · · · · · · · · · · ·
T Heanet 7 IC3 806.81 (cid:51)
IC3 84.62 (cid:51)
IC3 (cid:51)
T HiberniaIreland 7 - TO ? - TO ? IC3 (cid:51)
T Arpanet19706 9 - TO ? IC3 362.21 (cid:51)
IC3 (cid:51)
T Nordu2005 9 - TO ? - TO ? IC3 (cid:51) · · · · · · · · · · · ·
T Fatman 17 - TO ? IC3 1543.34 (cid:51)
IC3 (cid:51) · · · · · · · · · · · ·
T Myren 37 - TO ? - TO ? IC3 (cid:51)
T KentmanJan2011 38 - TO ? - TO ? IC3 (cid:51)
F Arpanet196912 4 BMC3 2.18 (cid:55)
BMC3 (cid:55)
BMC3 1.97 (cid:55)
F Napnet 6 BMC2 4.17 (cid:55)
BMC2 5.22 (cid:55)
BMC3 (cid:55) · · · · · · · · · · · ·
F Fatman 17 BMC3 168.78 (cid:55)
BMC3 169.82 (cid:55)
BMC3 (cid:55) · · · · · · · · · · · ·
F Belnet2009 21 BMC2 1146.26 (cid:55)
BMC2 611.81 (cid:55)
BMC3 (cid:55) · · · · · · · · · · · ·
F KentmanJan2011 38 BMC3 167.92 (cid:55)
BMC3 86.44 (cid:55)
BMC2 (cid:55) · · · · · · · · · · · ·
F Latnet 69 - TO ? - TO ? BMC2 (cid:55)
F Ulaknet 82 - TO ? - TO ? BMC2 (cid:55)
Sum of runtimes (in hours): 82.99 79.15 30.31Nb of TOs (of 230 exper.): 146 138 6
We refer to [21] for an introduction to SDN. Solutions for correctness of updatesof software-defined networks include consistent updates [28,7], dynamic schedul-ing [17], and incremental updates [18]. Both explicit and SMT-based modelchecking [5,23,22,31,1,26] is used to verify software-defined networks. Closest toour approach are models of networks as Kripke structures to use model checkingfor synthesis of correct network updates [8,24]. The model checking subroutineof 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 Petrinets and an annual model checking contest [20].
AdamMC is restricted to safePetri nets whereas other tools can handle bounded and colored Petri nets. At thesame time, only
AdamMC accepts LTL formulas with places and transitions asatomic propositions. This is essential to express fairness in our SDN encoding. damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 11
We presented the tool
AdamMC with its three application domains: checkingsafe Petri nets with transits against Flow-LTL, checking concurrent updates ofsoftware-defined networks against common assumptions and specifications, andchecking safe Petri nets against LTL. New algorithms allow
AdamMC to modelcheck software-defined networks of realistic size: it can verify updates of networkswith up to 38 switches and can falsify updates of networks with up to 82 switches.
References ∼ (10), 86–95 (2014), http://doi.acm.org/10.1145/2661061.26610637. Cern´y, P., Foster, N., Jagnik, N., McClurg, J.: Optimal consistent network updatesin polynomial time. In: Proceedings of DISC. pp. 114–128 (2016), https://doi.org/10.1007/978-3-662-53426-7 98. El-Hassany, A., Tsankov, P., Vanbever, L., Vechev, M.T.: Network-wide configu-ration synthesis. In: Proceedings of CAV. pp. 261–281 (2017), https://doi.org/10.1007/978-3-319-63390-9 149. Ellson, J., Gansner, E.R., Koutsofios, E., North, S.C., Woodhull, G.: Graphviz anddynagraph - static and dynamic graph drawing tools. In: Graph Drawing Software,pp. 127–148. Springer (2004), https://doi.org/10.1007/978-3-642-18638-7 610. Finkbeiner, B., Gieseking, M., Hecking-Harbusch, J., Olderog, E.: Model checkingdata flows in concurrent network updates. In: Proceedings of ATVA. pp. 515–533(2019), https://doi.org/10.1007/978-3-030-31784-3 3011. Finkbeiner, B., Gieseking, M., Hecking-Harbusch, J., Olderog, E.: Model checkingdata flows in concurrent network updates (full version). Tech. rep. (2019), http://arxiv.org/abs/1907.1106112. Finkbeiner, B., Gieseking, M., Hecking-Harbusch, J., Olderog, E.: AdamMC –A Model Checker for Petri Nets with Transits against Flow-LTL. University ofOldenburg and Saarland University. https://uol.de/en/csd/adammc (2020)13. Finkbeiner, B., Gieseking, M., Hecking-Harbusch, J., Olderog, E.: AdamMC: Amodel checker for petri nets with transits against Flow-LTL. In: Proceedings ofCAV (2020)2 B. Finkbeiner et al.14. Finkbeiner, B., Gieseking, M., Olderog, E.: Adam: Causality-based synthesis ofdistributed systems. In: Proceedings of CAV. pp. 433–439 (2015), https://doi.org/10.1007/978-3-319-21690-4 2515. Finkbeiner, B., Rabe, M.N., S´anchez, C.: Algorithms for model checking HyperLTLand HyperCTL ∗ . In: Proceedings of CAV. pp. 30–48 (2015), https://doi.org/10.1007/978-3-319-21690-4 316. Gieseking, M., Hecking-Harbusch, J.: AdamMC: A Model Checker for Petri Netswith Transits against Flow-LTL (Artifact) (2020), https://doi.org/10.6084/m9.figshare.1167617117. Jin, X., Liu, H.H., Gandhi, R., Kandula, S., Mahajan, R., Zhang, M., Rexford,J., Wattenhofer, R.: Dynamic scheduling of network updates. In: Proceedings ofSIGCOMM. pp. 539–550 (2014), https://doi.org/10.1145/2619239.262630718. Katta, N.P., Rexford, J., Walker, D.: Incremental consistent updates. In: Proceed-ings of HotSDN. pp. 49–54 (2013), https://doi.org/10.1145/2491185.249119119. Knight, S., Nguyen, H.X., Falkner, N., Bowden, R.A., Roughan, M.: The internettopology zoo. IEEE Journal on Selected Areas in Communications (9), 1765–1775 (2011), https://doi.org/10.1109/JSAC.2011.11100220. Kordon, F., Garavel, H., Hillah, L.M., Hulin-Hubard, F., Amparore, E., Beccuti,M., Berthomieu, B., Ciardo, G., Dal Zilio, S., Liebke, T., Li, S., Meijer, J., Miner,A., Srba, J., Thierry-Mieg, Y., van de Pol, J., van Dirk, T., Wolf, K.: CompleteResults for the 2019 Edition of the Model Checking Contest. http://mcc.lip6.fr/2019/results.php (April 2019)21. Kreutz, D., Ramos, F.M.V., Ver´ıssimo, P.J.E., Rothenberg, C.E., Azodolmolky,S., Uhlig, S.: Software-defined networking: A comprehensive survey. Proceedingsof the IEEE (1), 14–76 (2015), https://doi.org/10.1109/JPROC.2014.237199922. Mai, H., Khurshid, A., Agarwal, R., Caesar, M., Godfrey, B., King, S.T.: Debuggingthe data plane with anteater. In: Proceedings ofSIGCOMM. pp. 290–301 (2011),https://doi.org/10.1145/2018436.201847023. Majumdar, R., Tetali, S.D., Wang, Z.: Kuai: A model checker for software-definednetworks. In: Proceedings of FMCAD. pp. 163–170 (2014), https://doi.org/10.1109/FMCAD.2014.698760924. McClurg, J., Hojjat, H., Cern´y, P.: Synchronization synthesis for network pro-grams. In: Proceedings of CAV. pp. 301–321 (2017), https://doi.org/10.1007/978-3-319-63390-9 1625. McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G.M., Peterson, L.L.,Rexford, J., Shenker, S., Turner, J.S.: Openflow: enabling innovation in campusnetworks. Computer Communication Review (2), 69–74 (2008), http://doi.acm.org/10.1145/1355734.135574626. Padon, O., Immerman, N., Karbyshev, A., Lahav, O., Sagiv, M., Shoham, S.:Decentralizing SDN policies. In: Proceedings of POPL. pp. 663–676 (2015), https://doi.org/10.1145/2676726.267699027. Reisig, W.: Petri Nets: An Introduction. Springer (1985), https://doi.org/10.1007/978-3-642-69968-928. Reitblatt, M., Foster, N., Rexford, J., Schlesinger, C., Walker, D.: Abstractions fornetwork update. In: Proceedings of SIGCOMM. pp. 323–334 (2012), http://doi.acm.org/10.1145/2342356.234242729. Thierry-Mieg, Y.: Symbolic model-checking using ITS-tools. In: Proceedings ofTACAS. pp. 231–237 (2015), https://doi.org/10.1007/978-3-662-46681-0 2030. University of Oldenburg: APT – Analyse von Petri-Netzen und Transitionssyste-men. https://github.com/CvO-Theory/apt (2012) damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 1331. Wang, A., Moarref, S., Loo, B.T., Topcu, U., Scedrov, A.: Automated synthesis ofreactive controllers for software-defined networks. In: Proceedings of ICNP. pp. 1–6(2013), https://doi.org/10.1109/ICNP.2013.673366632. Wolf, K.: Petri net model checking with LoLA 2. In: Proceedings of PETRI NETS.pp. 351–362 (2018), https://doi.org/10.1007/978-3-319-91268-4 18 AppendixA Technical Details
In this part of the appendix, details of the parallel approach, i.e., the constructionof the Petri net (cid:78) > and the construction of the LTL formula ϕ > , are given. A.1 Construction of the Net Transformation (Parallel Approach)
Let ID be a set of unique identifiers and ν (cid:78) : (cid:80) ∪ (cid:84) → ID an injective namingfunction which uniquely identifies every place and transition of a given Petrinet (cid:78) (or of a Petri net with transits). We omit the subscript if the net is clearfrom the context. To keep the presentation clear, we often directly use identifier for a node n ∈ (cid:80) ∪ (cid:84) with ν ( n ) = identifier .The construction of a Petri net with transits to a standard P/T Petri netwith inhibitor arcs is given by the following definition. Definition 1 (Petri Net with Transits to a P/T Petri Net).
For a Petrinet with transits (cid:78) = ( (cid:80) , (cid:84) , (cid:70) , In , Υ ) and a Flow-LTL formula ϕ with n subfor-mulas, a Petri net (cid:78) > = ( (cid:80) > , (cid:84) > , (cid:70) > , (cid:70) >I , In > ) with inhibitor arcs (denotedby (cid:70) >I ) and a labeling function λ : (cid:84) > → (cid:84) are defined as follows:(p) The places of the original net (cid:78) are copied n + 1 times: (cid:80) > = (cid:80) ∪ (cid:91) { ,...,n } ( { [ ι ] i } ∪ { [ p ] i | p ∈ (cid:80) } ) (t) For every transition t ∈ (cid:84) and every combination of which subnet is trackingwhich transit (or no transit with marker ◦ ), there is one transition in (cid:78) > .Each transition is connected to the original part of the net according to t . Forthe subnet part, it either a) moves the token from the initial place accordingto the transit, b) moves the token from the corresponding ingoing place of thetransit according to the transit, or, in the case that the subnet is not involvedin any of the transits, c) is connected by inhibitor arcs to all ingoing placesof the transition t . ∀ t ∈ (cid:84) : ∀ c = (( x , p ) , . . . , ( x n , p n )) ∈ ( Υ ( t ) ∪ {◦} ) n : ∃ t > ∈ (cid:84) > : ∀ ( p, t ) , ( t, q ) ∈ (cid:70) : ( p, t > ) , ( t > , q ) ∈ (cid:70) > ∧ ν ( t > ) = ν ( t ) c ∧ λ ( t > ) = ν ( t ) ∧∀ i ∈ { , . . . , n } : x i = (cid:66) = ⇒ ([ ι ] i , t > ) , ( t > , [ p i ] i ) ∈ (cid:70) > ∧ x i , p i ∈ (cid:80) = ⇒ ([ x i ] i , t > ) , ( t > , [ p i ] i ) ∈ (cid:70) > ∧ ( x i , p i ) = ◦ = ⇒ ∀ ( p, t ) ∈ (cid:70) : ([ p i ] i , t > ) ∈ (cid:70) >I time steps τβ ... β i ... Fig. 5: A possible sequence of the global timeline τ and the timelines of thepossible infinite number of flow chains β i . A filled time step for a timeline ofa flow chain indicates that the fired transition has a transit which extends thisflow chain. (I) The initial marking is given by In > = In ∪ { [ ι ] i | i ∈ { , . . . , n }} .The sets (cid:84) > , (cid:70) > , and (cid:70) >I are defined as the smallest sets fulfilling condition (t).The identifiers with the square brackets and those with a combination c in theirindex are fresh identifiers. The results regarding the size of the constructed net directly follow from thedefinition and that there are | (cid:80) | · | (cid:84) | · | (cid:80) | + | (cid:84) | · | (cid:80) | transits in the worst-case. Lemma 1 (Size of the Constructed Net).
The constructed Petri net (cid:78) > has O ( | (cid:78) | · n + | (cid:78) | ) places and O ( | (cid:78) | n + | (cid:78) | ) transitions. A.2 Construction of the Formula Transformation (ParallelApproach)
We create an LTL formula ϕ > to the Petri net (cid:78) > (created by Def. 1 of a Petrinet with transits (cid:78) = ( (cid:80) , (cid:84) , (cid:70) , In , Υ )) from a Flow-LTL formula ϕ with n ∈ N flow subformulas ϕ F i = A ψ i . The intricate part of the construction is to dealwith the different timelines. On the one hand, there is the global timeline of thePetri net (cid:78) . 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 flowchains. For the flow chains, the global steps not concerning the chain have to beadequately skipped with until operators. Figure 5 gives an overview of a possiblesequence of different timelines.We define the set of transitions tracking a chain of a specific subnet i ∈{ , . . . , n } by (cid:84) >i = { t ∈ (cid:84) > | ∃ p ∈ (cid:80) : ([ p ] i , t ) ∈ (cid:70) > ∨ ( t, [ p ] i ) ∈ (cid:70) > } andthe set of all other transitions by O i = (cid:84) > \ (cid:84) >i . For a transition t ∈ (cid:84) , theset M i ( t ) = (cid:84) >i ∩ { t > ∈ (cid:84) > | λ ( t > ) = t } collects all corresponding transitionstracking a chain of the subnet.First, the places of the flow subformulas have to be substituted by the cor-responding places tracking the chain, i.e., all occurrences of a place p ∈ (cid:80) in a damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 15 flow subformula ϕ F i are simultaneously replaced by [ p ] i . Second, the transitions of the flow subformulas have to be substituted such that all steps of the globaltimeline which do not involve the tracked flow chain are skipped until a transitioninvolving the flow chain is fired, i.e., all occurrences of a transition t ∈ (cid:84) in a flowsubformula ϕ F i are simultaneously substituted by ( (cid:87) t o ∈ O i t o ) U ( (cid:87) t m ∈ M i ( t ) t m ).Similarly, the next operator of the flow subformulas have to be substituted suchthat the steps of the global timeline are skipped until a step involving the track-ing 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 di-rectly hold in the stuttering part, or there is a transition of the subnet, then theformula has to hold in the direct successor state. This means all occurrences ofa subformula φ in a flow subformula ϕ F i are replaced from the inner- to theoutermost occurrence by (( (cid:87) t ∈ O i t ) U (( (cid:87) t ∈ (cid:84) >i t ) ∧ φ )) ∨ ( ( ¬ ( (cid:87) t ∈ (cid:84) >i t )) ∧ φ ).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 alreadycorrectly named. Only the transitions t ∈ (cid:84) in the run part of ϕ have to besubstituted simultaneously by (cid:87) t (cid:48) ∈{ t (cid:48) ∈ (cid:84) > | λ ( t (cid:48) )= t } t (cid:48) to allow for all transitionscorresponding to t .Finally, the flow subformulas are simultaneously substituted by [ ι ] i (cid:87) ( ¬ [ ι ] i ∧ ψ (cid:48) i ) (where ψ (cid:48) i is the result of the above mentioned substitutions within a flowsubformula) such that all steps of the global timeline are skipped until a flowchain is created and tracked. Table 3 gives an overview of these substitutions.Table 3: An overview of the necessary substitutions to create ϕ > from ϕ . Thenext 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 ∈ (cid:80) p [ p ] i t ∈ (cid:84) (cid:87) t (cid:48) ∈{ t (cid:48) ∈ (cid:84) > | λ ( t (cid:48) )= t } t (cid:48) ( (cid:87) t o ∈ O i t o ) U ( (cid:87) t m ∈ M i ( t ) t m ) φ φ (( (cid:87) t ∈ O i t ) U (( (cid:87) t ∈ (cid:84) >i t ) ∧ φ )) ∨ ( ( ¬ ( (cid:87) t ∈ (cid:84) >i t )) ∧ φ ) A ψ i [ ι ] i (cid:87) ( ¬ [ ι ] i ∧ ψ (cid:48) i ) – The size of the constructed formula directly results from the blow-up of thenumber of transition during the creation of (cid:78) > and the substitutions introducingthe disjunctions over these transition in the creation of ϕ > . Lemma 2 (Size of the Constructed Formula).
The size of the constructedLTL formula ϕ > is in O ( | (cid:78) | n · | ϕ | + | ϕ | ) . Note that there is only a significant blow-up in the formula when transitionsare used as atomic propositions in either the flow or the run part of the formulaor when the next operator is used in the flow part of the formula. Moreover, eventhe usage of transitions as atomic propositions in the run part of the formula onlyresults in a blow-up by all combinations of transits of this transition regardingthe subnets. In practical applications, this makes a huge difference compared tothe sequential approach, because model checking is exponential in the size of the formula and many examples need fairness assumptions, i.e., transitions in therun part of the formula, and have only few local requirements.The proof of the correctness of the transformations for the parallel approachis very similar to the one of the sequential approach presented in [11]. Weagain can mutually transform the counterexample to show the contraposition (cid:78) (cid:54)| = ϕ iff (cid:78) > (cid:54)| = LTL ϕ > . Here we do not have to pump up the firing sequenceserving as counterexample for (cid:78) | = ϕ , but have to replace each transition bya transition which adequately extends all flow chains of the counterexample.For the other direction, we can replace the transitions of the counterexample bythe labels of the transitions and, analog to the sequential approach, iterativelyconcatenate the transitions and places of the subnets to gain the flow chainsserving as counterexamples for the subformula part. The complicated parts ofthe structural induction, i.e., adequately skipping the global time steps for theflow subformulas, can be done analogously because the formulas of the paral-lel approach and the sequential approach are similar in this case and fit to thedifferent structure of the net. B Complete Results
Table 4: We compare the explicit and the logarithmic encoding of the sequentialapproach with the parallel approach. The results are the average over 5 runsfrom an Intel i7-2700K CPU with 3.50 GHz, 32 GB RAM, and a timeout of30 minutes. We report the runtimes of IC3 to verify (T) updates of software-defined networks and the runtimes of both BMC2 and BMC3 to falsify (F)updates of software-defined networks all with respect to connectivity betweenrandomly chosen ingress and egress switches and forwarding tables.expl. enc. log. enc. parallel appr.T / F Network Sw Alg. Time | = Alg. Time | = Alg. Time | =T Arpanet196912 4 IC3 12.0760 (cid:51) IC3 9.8872 (cid:51)
IC3 2.1760 (cid:51)
T Napnet 6 IC3 146.4920 (cid:51)
IC3 96.0640 (cid:51)
IC3 4.7448 (cid:51)
T Epoch 6 IC3 240.5720 (cid:51)
IC3 214.6960 (cid:51)
IC3 6.7800 (cid:51)
T Telecomserbia 6 IC3 1182.4320 (cid:51)
IC3 912.7560 (cid:51)
IC3 12.1232 (cid:51)
T Layer42 6 IC3 133.1992 (cid:51)
IC3 131.6824 (cid:51)
IC3 6.2624 (cid:51)
T Dataxchange 6 - TO ? IC3 380.1976 (cid:51)
IC3 19.9968 (cid:51)
T Sanren 7 IC3 304.6368 (cid:51)
IC3 437.0128 (cid:51)
IC3 16.6776 (cid:51)
T Getnet 7 IC3 940.4160 (cid:51)
IC3 103.0960 (cid:51)
IC3 11.0480 (cid:51)
T Netrail 7 IC3 171.5952 (cid:51)
IC3 531.5576 (cid:51)
IC3 31.9800 (cid:51)
T Heanet 7 IC3 806.8144 (cid:51)
IC3 84.6160 (cid:51)
IC3 30.3008 (cid:51)
T HiberniaIreland 7 - TO ? - TO ? IC3 26.5824 (cid:51)
T Arpanet19706 9 - TO ? IC3 362.2056 (cid:51)
IC3 11.3304 (cid:51)
T Nordu2005 9 - TO ? - TO ? IC3 12.6688 (cid:51)
T Nsfcnet 10 - TO ? - TO ? IC3 5.5448 (cid:51) damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 17
T Sprint 11 - TO ? - TO ? IC3 745.7408 (cid:51)
T TLex 12 - TO ? - TO ? IC3 17.1296 (cid:51)
T Compuserve 13 - TO ? - TO ? IC3 107.9464 (cid:51)
T Eenet 13 - TO ? - TO ? IC3 40.3456 (cid:51)
T HiberniaCanada 13 - TO ? - TO ? IC3 107.6000 (cid:51)
T Navigata 13 - TO ? - TO ? IC3 360.5248 (cid:51)
T Nsfnet 13 - TO ? - TO ? IC3 181.3240 (cid:51)
T Uninet 13 - TO ? - TO ? IC3 1336.1420 (cid:51)
T Eunetworks 14 - TO ? - TO ? IC3 80.3952 (cid:51)
T Ilan 14 - TO ? - TO ? IC3 137.8408 (cid:51)
T Claranet 15 - TO ? - TO ? IC3 128.0024 (cid:51)
T HiberniaUk 15 - TO ? - TO ? IC3 184.5888 (cid:51)
T Spiralight 15 - TO ? - TO ? IC3 153.2312 (cid:51)
T Garr199901 16 - TO ? - TO ? IC3 164.5248 (cid:51)
T KentmanJul2005 16 - TO ? - TO ? IC3 163.2448 (cid:51)
T Marwan 16 - TO ? - TO ? IC3 136.5992 (cid:51)
T Peer1 16 - TO ? - TO ? IC3 357.0224 (cid:51)
T Rhnet 16 - TO ? - TO ? IC3 62.6520 (cid:51)
T Fatman 17 - TO ? IC3 1543.3360 (cid:51)
IC3 162.1672 (cid:51)
T Nextgen 17 - TO ? - TO ? IC3 403.3296 (cid:51)
T Nordu2010 18 - TO ? - TO ? IC3 50.1136 (cid:51)
T Pacificwave 18 - TO ? - TO ? IC3 932.5960 (cid:51)
T Ans 18 - TO ? - TO ? IC3 1511.3020 (cid:51)
T Arpanet19719 18 - TO ? - TO ? IC3 840.6400 (cid:51)
T BsonetEurope 18 - TO ? - TO ? IC3 496.2936 (cid:51)
T HiberniaNireland 18 - TO ? - TO ? IC3 229.0768 (cid:51)
T Noel 19 - TO ? - TO ? IC3 402.8256 (cid:51)
T Restena 19 - TO ? - TO ? IC3 698.4024 (cid:51)
T Savvis 19 - TO ? - TO ? IC3 1382.3480 (cid:51)
T Twaren 20 - TO ? IC3 1167.9080 (cid:51)
IC3 1388.6660 (cid:51)
T Janetlense 20 - TO ? - TO ? IC3 730.6448 (cid:51)
T BtAsiaPac 20 - TO ? - TO ? IC3 1311.1100 (cid:51)
T Oxford 20 - TO ? - TO ? IC3 678.3344 (cid:51)
T Harnet 21 - TO ? - TO ? IC3 347.0536 (cid:51)
T Belnet2009 21 - TO ? - TO ? IC3 1604.5860 (cid:51)
T GtsRomania 21 - TO ? - TO ? IC3 236.7912 (cid:51)
T Packetexchange 21 - TO ? - TO ? IC3 688.5176 (cid:51)
T Garr200404 22 - TO ? - TO ? IC3 184.8440 (cid:51)
T Belnet2010 22 - TO ? - TO ? IC3 346.6064 (cid:51)
T Garr200109 22 - TO ? - TO ? IC3 1499.7620 (cid:51)
T KentmanApr2007 22 - TO ? - TO ? IC3 429.7848 (cid:51)
T Istar 23 - TO ? - TO ? IC3 169.0848 (cid:51)
T Garr199905 23 - TO ? - TO ? IC3 440.1864 (cid:51)
T Garr199904 23 - TO ? - TO ? IC3 590.0240 (cid:51)
T Cesnet2001 23 - TO ? - TO ? IC3 308.9808 (cid:51)
T Fccn 23 - TO ? - TO ? IC3 752.9816 (cid:51)
T Uran 24 - TO ? - TO ? IC3 82.6056 (cid:51)
T Garr200112 24 - TO ? - TO ? IC3 1731.2440 (cid:51)
T Psinet 24 - TO ? - TO ? IC3 226.0680 (cid:51)
T Arpanet19723 25 - TO ? - TO ? IC3 218.3872 (cid:51)
T Vinaren 25 - TO ? - TO ? IC3 1084.5340 (cid:51)
T KentmanFeb2008 26 - TO ? - TO ? IC3 421.7424 (cid:51)
T Garr200212 27 - TO ? - TO ? IC3 1205.4020 (cid:51)
T Bbnplanet 27 - TO ? - TO ? IC3 896.9776 (cid:51)
T Darkstrand 27 - TO ? - TO ? IC3 1466.4960 (cid:51)
T KentmanAug2005 28 - TO ? - TO ? IC3 278.9248 (cid:51)
T Myren 37 - TO ? - TO ? IC3 1309.2280 (cid:51)
T KentmanJan2011 38 - TO ? - TO ? IC3 1261.3220 (cid:51)
F Arpanet196912 4 BMC2 2.3528 (cid:55)
BMC2 2.0952 (cid:55)
BMC2 1.1992 (cid:55)
F Arpanet196912 4 BMC3 2.1768 (cid:55)
BMC3 1.8528 (cid:55)
BMC3 1.1968 (cid:55)
F Napnet 6 BMC2 4.1688 (cid:55)
BMC2 5.2240 (cid:55)
BMC2 1.6408 (cid:55)
F Napnet 6 BMC3 5.7072 (cid:55)
BMC3 5.4368 (cid:55)
BMC3 1.4808 (cid:55)
F Epoch 6 BMC2 20.7584 (cid:55)
BMC2 14.3200 (cid:55)
BMC2 2.6328 (cid:55)
F Epoch 6 BMC3 15.4112 (cid:55)
BMC3 13.5632 (cid:55)
BMC3 2.3912 (cid:55)
F Telecomserbia 6 BMC2 45.1120 (cid:55)
BMC2 39.7160 (cid:55)
BMC2 13.2600 (cid:55)
F Telecomserbia 6 BMC3 37.5104 (cid:55)
BMC3 41.4688 (cid:55)
BMC3 12.8704 (cid:55)
F Layer42 6 BMC2 9.4880 (cid:55)
BMC2 11.8768 (cid:55)
BMC2 2.0744 (cid:55)
F Layer42 6 BMC3 11.4400 (cid:55)
BMC3 6.7544 (cid:55)
BMC3 2.5560 (cid:55)
F Sanren 7 BMC2 64.8976 (cid:55)
BMC2 134.8184 (cid:55)
BMC2 8.2312 (cid:55)
F Sanren 7 BMC3 173.9256 (cid:55)
BMC3 81.2960 (cid:55)
BMC3 3.8832 (cid:55)
F Getnet 7 BMC2 7.3792 (cid:55)
BMC2 9.2480 (cid:55)
BMC2 1.6872 (cid:55)
F Getnet 7 BMC3 7.5144 (cid:55)
BMC3 7.2872 (cid:55)
BMC3 1.5248 (cid:55)
F Netrail 7 BMC2 80.8968 (cid:55)
BMC2 50.0872 (cid:55)
BMC2 5.6976 (cid:55)
F Netrail 7 BMC3 63.8416 (cid:55)
BMC3 72.6552 (cid:55)
BMC3 3.5632 (cid:55)
F Heanet 7 BMC2 57.2528 (cid:55)
BMC2 66.6016 (cid:55)
BMC2 5.6632 (cid:55)
F Heanet 7 BMC3 54.5128 (cid:55)
BMC3 27.9272 (cid:55)
BMC3 5.5848 (cid:55)
F Arpanet19706 9 BMC2 52.5888 (cid:55)
BMC2 44.3200 (cid:55)
BMC2 7.7576 (cid:55)
F Arpanet19706 9 BMC3 58.1392 (cid:55)
BMC3 33.6264 (cid:55)
BMC3 4.5640 (cid:55)
F Nordu2005 9 BMC2 35.9496 (cid:55)
BMC2 33.2320 (cid:55)
BMC2 6.0872 (cid:55)
F Nordu2005 9 BMC3 38.6664 (cid:55)
BMC3 25.6184 (cid:55)
BMC3 3.2904 (cid:55)
F Nsfcnet 10 BMC2 14.3520 (cid:55)
BMC2 13.2688 (cid:55)
BMC2 2.1520 (cid:55)
F Nsfcnet 10 BMC3 13.5312 (cid:55)
BMC3 4.8568 (cid:55)
BMC3 2.0184 (cid:55) damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 19
F Sprint 11 - TO ? - TO ? BMC2 567.1048 (cid:55)
F Sprint 11 - TO ? - TO ? BMC3 582.5752 (cid:55)
F TLex 12 BMC2 92.9472 (cid:55)
BMC2 81.4936 (cid:55)
BMC2 4.9240 (cid:55)
F TLex 12 BMC3 89.6536 (cid:55)
BMC3 49.1896 (cid:55)
BMC3 7.0464 (cid:55)
F Compuserve 13 - TO ? - TO ? BMC2 544.4312 (cid:55)
F Compuserve 13 - TO ? - TO ? BMC3 460.1632 (cid:55)
F Eenet 13 BMC2 249.1056 (cid:55)
BMC2 238.0224 (cid:55)
BMC2 21.8432 (cid:55)
F Eenet 13 BMC3 271.4032 (cid:55)
BMC3 218.4312 (cid:55)
BMC3 19.5312 (cid:55)
F HiberniaCanada 13 BMC2 1309.4440 (cid:55)
BMC2 935.0480 (cid:55)
BMC2 149.3392 (cid:55)
F HiberniaCanada 13 BMC3 1304.8740 (cid:55)
BMC3 1097.0560 (cid:55)
BMC3 53.5256 (cid:55)
F Navigata 13 - TO ? - TO ? BMC2 440.9632 (cid:55)
F Navigata 13 - TO ? - TO ? BMC3 319.2552 (cid:55)
F Nsfnet 13 - TO ? - TO ? BMC2 159.0920 (cid:55)
F Nsfnet 13 - TO ? BMC3 1621.8300 (cid:55)
BMC3 177.6008 (cid:55)
F Eunetworks 14 BMC2 1039.4640 (cid:55)
BMC2 1104.7060 (cid:55)
BMC2 38.2784 (cid:55)
F Eunetworks 14 BMC3 1417.8800 (cid:55)
BMC3 1056.0080 (cid:55)
BMC3 35.9568 (cid:55)
F Claranet 15 BMC2 189.4912 (cid:55)
BMC2 165.1504 (cid:55)
BMC2 10.2744 (cid:55)
F Claranet 15 BMC3 160.3808 (cid:55)
BMC3 150.6000 (cid:55)
BMC3 7.9720 (cid:55)
F Spiralight 15 - TO ? - TO ? BMC2 1249.4900 (cid:55)
F Spiralight 15 - TO ? - TO ? BMC3 1734.8840 (cid:55)
F Garr199901 16 BMC2 625.8648 (cid:55)
BMC2 432.1856 (cid:55)
BMC2 31.3360 (cid:55)
F Garr199901 16 BMC3 743.3096 (cid:55)
BMC3 370.4792 (cid:55)
BMC3 61.6488 (cid:55)
F KentmanJul2005 16 BMC2 1391.2280 (cid:55)
BMC2 1243.6260 (cid:55)
BMC2 175.4600 (cid:55)
F KentmanJul2005 16 BMC3 1405.8180 (cid:55)
BMC3 1030.0400 (cid:55)
BMC3 171.0152 (cid:55)
F Marwan 16 - TO ? - TO ? BMC2 696.8736 (cid:55)
F Marwan 16 - TO ? - TO ? BMC3 799.7816 (cid:55)
F Peer1 16 - TO ? - TO ? - TO ?F Peer1 16 - TO ? - TO ? BMC3 1551.8120 (cid:55)
F Rhnet 16 - TO ? - TO ? BMC2 105.4688 (cid:55)
F Rhnet 16 - TO ? - TO ? BMC3 49.9360 (cid:55)
F Fatman 17 BMC2 193.7456 (cid:55)
BMC2 200.3976 (cid:55)
BMC2 18.1704 (cid:55)
F Fatman 17 BMC3 168.7768 (cid:55)
BMC3 169.8224 (cid:55)
BMC3 6.7232 (cid:55)
F Goodnet 17 - TO ? - TO ? BMC2 410.3936 (cid:55)
F Goodnet 17 - TO ? - TO ? BMC3 378.1480 (cid:55)
F Nextgen 17 - TO ? - TO ? - TO ?F Nextgen 17 - TO ? - TO ? BMC3 5014.4240 (cid:55)
F Nordu2010 18 BMC2 183.4608 (cid:55)
BMC2 140.1384 (cid:55)
BMC2 13.6824 (cid:55)
F Nordu2010 18 BMC3 116.1192 (cid:55)
BMC3 80.7856 (cid:55)
BMC3 6.9120 (cid:55)
F Pacificwave 18 BMC2 1761.4720 (cid:55)
BMC2 1035.8420 (cid:55)
BMC2 95.0104 (cid:55)
F Pacificwave 18 BMC3 1166.0460 (cid:55)
BMC3 1545.4200 (cid:55)
BMC3 64.5768 (cid:55)
F BsonetEurope 18 - TO ? - TO ? BMC2 770.6568 (cid:55)
F BsonetEurope 18 - TO ? - TO ? BMC3 1195.4540 (cid:55)
F Highwinds 18 - TO ? - TO ? BMC2 671.2392 (cid:55)
F Highwinds 18 - TO ? - TO ? BMC3 1045.0800 (cid:55)
F Noel 19 - TO ? - TO ? BMC2 1356.7820 (cid:55)
F Noel 19 - TO ? - TO ? BMC3 611.0792 (cid:55)
F Restena 19 - TO ? - TO ? BMC2 630.9496 (cid:55)
F Restena 19 - TO ? - TO ? BMC3 192.2696 (cid:55)
F Twaren 20 BMC2 560.8456 (cid:55)
BMC2 429.7516 (cid:55)
BMC2 66.7208 (cid:55)
F Twaren 20 BMC3 650.5672 (cid:55)
BMC3 349.0816 (cid:55)
BMC3 31.4976 (cid:55)
F Marnet 20 BMC2 858.9728 (cid:55)
BMC2 557.1536 (cid:55)
BMC2 18.9960 (cid:55)
F Marnet 20 BMC3 846.0584 (cid:55)
BMC3 475.7168 (cid:55)
BMC3 26.4488 (cid:55)
F Janetlense 20 BMC2 735.1432 (cid:55)
BMC2 721.8584 (cid:55)
BMC2 28.1296 (cid:55)
F Janetlense 20 BMC3 492.5848 (cid:55)
BMC3 616.7248 (cid:55)
BMC3 28.6504 (cid:55)
F BtAsiaPac 20 - TO ? - TO ? BMC2 1298.5280 (cid:55)
F BtAsiaPac 20 - TO ? - TO ? BMC3 897.9200 (cid:55)
F Oxford 20 - TO ? - TO ? BMC2 645.1712 (cid:55)
F Oxford 20 - TO ? - TO ? BMC3 521.4232 (cid:55)
F Harnet 21 BMC2 961.5872 (cid:55)
BMC2 873.2056 (cid:55)
BMC2 60.4784 (cid:55)
F Harnet 21 BMC3 1410.2540 (cid:55)
BMC3 735.7256 (cid:55)
BMC3 58.4040 (cid:55)
F Belnet2009 21 BMC2 1146.2600 (cid:55)
BMC2 611.8096 (cid:55)
BMC2 43.8104 (cid:55)
F Belnet2009 21 - TO ? BMC3 1294.5020 (cid:55)
BMC3 24.2568 (cid:55)
F Garr200404 22 BMC2 61.5632 (cid:55)
BMC2 70.9440 (cid:55)
BMC2 6.1848 (cid:55)
F Garr200404 22 BMC3 45.9016 (cid:55)
BMC3 49.3768 (cid:55)
BMC3 4.6952 (cid:55)
F Bandcon 22 - TO ? - TO ? - TO ?F Bandcon 22 - TO ? - TO ? BMC3 1619.6780 (cid:55)
F KentmanApr2007 22 - TO ? - TO ? BMC2 914.6352 (cid:55)
F KentmanApr2007 22 - TO ? - TO ? BMC3 414.7120 (cid:55)
F Istar 23 BMC2 574.5056 (cid:55)
BMC2 302.8448 (cid:55)
BMC2 29.0296 (cid:55)
F Istar 23 BMC3 221.1632 (cid:55)
BMC3 236.4752 (cid:55)
BMC3 22.8224 (cid:55)
F Garr199905 23 BMC2 188.2176 (cid:55)
BMC2 155.1984 (cid:55)
BMC2 13.4320 (cid:55)
F Garr199905 23 BMC3 272.3944 (cid:55)
BMC3 78.0928 (cid:55)
BMC3 10.9904 (cid:55)
F Garr199904 23 BMC2 478.9360 (cid:55)
BMC2 342.0088 (cid:55)
BMC2 65.7056 (cid:55)
F Garr199904 23 BMC3 304.7032 (cid:55)
BMC3 385.6456 (cid:55)
BMC3 33.4232 (cid:55)
F Aconet 23 - TO ? - TO ? BMC2 366.4816 (cid:55)
F Aconet 23 - TO ? - TO ? BMC3 642.5488 (cid:55)
F Belnet2003 23 - TO ? - TO ? BMC2 135.0384 (cid:55)
F Belnet2003 23 - TO ? - TO ? BMC3 126.2848 (cid:55)
F Belnet2005 23 - TO ? - TO ? BMC2 795.6688 (cid:55)
F Belnet2005 23 - TO ? - TO ? BMC3 558.2600 (cid:55) damMC : A Model Checker for Petri Nets with Transits against Flow-LTL 21
F Cesnet2001 23 - TO ? BMC2 1439.4880 (cid:55)
BMC2 277.3880 (cid:55)
F Cesnet2001 23 - TO ? BMC3 1508.9240 (cid:55)
BMC3 169.1864 (cid:55)
F Fccn 23 - TO ? - TO ? BMC2 772.9776 (cid:55)
F Fccn 23 - TO ? - TO ? BMC3 785.8392 (cid:55)
F Uran 24 BMC2 87.9600 (cid:55)
BMC2 126.0488 (cid:55)
BMC2 4.0680 (cid:55)
F Uran 24 BMC3 71.7760 (cid:55)
BMC3 72.4816 (cid:55)
BMC3 3.8056 (cid:55)
F BtEurope 24 - TO ? - TO ? BMC2 5035.2740 (cid:55)
F BtEurope 24 - TO ? - TO ? BMC3 5030.4000 (cid:55)
F Garr200112 24 - TO ? - TO ? BMC2 538.3072 (cid:55)
F Garr200112 24 - TO ? - TO ? BMC3 294.9824 (cid:55)
F Arpanet19723 25 - TO ? - TO ? BMC2 1774.0800 (cid:55)
F Arpanet19723 25 - TO ? - TO ? BMC3 1079.5160 (cid:55)
F Vinaren 25 BMC2 1537.2920 (cid:55)
BMC2 799.1280 (cid:55)
BMC2 138.3432 (cid:55)
F Vinaren 25 BMC3 1093.3200 (cid:55)
BMC3 1171.3140 (cid:55)
BMC3 93.6536 (cid:55)
F KentmanFeb2008 26 BMC2 152.6880 (cid:55)
BMC2 230.8040 (cid:55)
BMC2 7.1976 (cid:55)
F KentmanFeb2008 26 BMC3 83.3048 (cid:55)
BMC3 89.7208 (cid:55)
BMC3 4.4288 (cid:55)
F Garr200212 27 BMC2 416.9272 (cid:55)
BMC2 405.2304 (cid:55)
BMC2 29.7792 (cid:55)
F Garr200212 27 BMC3 418.8768 (cid:55)
BMC3 301.6184 (cid:55)
BMC3 14.4280 (cid:55)
F Gambia 28 - TO ? - TO ? BMC2 916.3864 (cid:55)
F Gambia 28 - TO ? - TO ? BMC3 586.2224 (cid:55)
F KentmanAug2005 28 - TO ? - TO ? BMC2 799.1960 (cid:55)
F KentmanAug2005 28 - TO ? - TO ? BMC3 935.1016 (cid:55)
F Ernet 30 - TO ? - TO ? BMC2 462.7160 (cid:55)
F Ernet 30 - TO ? - TO ? BMC3 361.0344 (cid:55)
F WideJpn 30 - TO ? - TO ? - TO ?F WideJpn 30 - TO ? - TO ? BMC3 336.8296 (cid:55)
F Iinet 31 BMC2 1380.3760 (cid:55)
BMC2 1217.9420 (cid:55)
BMC2 76.8728 (cid:55)
F Iinet 31 BMC3 1468.8020 (cid:55)
BMC3 701.2528 (cid:55)
BMC3 97.9888 (cid:55)
F CrlNetworkServices 33 - TO ? - TO ? BMC2 1534.4540 (cid:55)
F CrlNetworkServices 33 - TO ? - TO ? BMC3 591.3928 (cid:55)
F GtsSlovakia 35 - TO ? - TO ? BMC2 938.1456 (cid:55)
F GtsSlovakia 35 - TO ? - TO ? BMC3 1014.7040 (cid:55)
F Bren 37 - TO ? - TO ? BMC2 346.8384 (cid:55)
F Bren 37 - TO ? - TO ? BMC3 799.3200 (cid:55)
F Myren 37 BMC2 183.0128 (cid:55)
BMC2 154.1552 (cid:55)
BMC2 10.1816 (cid:55)
F Myren 37 BMC3 142.0280 (cid:55)
BMC3 75.9296 (cid:55)
BMC3 12.9468 (cid:55)
F KentmanJan2011 38 BMC2 237.3152 (cid:55)
BMC2 192.5768 (cid:55)
BMC2 9.3536 (cid:55)
F KentmanJan2011 38 BMC3 167.9208 (cid:55)
BMC3 86.4384 (cid:55)
BMC3 10.5464 (cid:55)
F Cesnet200511 39 - TO ? - TO ? BMC2 496.0712 (cid:55)
F Cesnet200511 39 - TO ? - TO ? BMC3 249.1456 (cid:55)
F Litnet 43 - TO ? - TO ? BMC2 234.4000 (cid:55)
F Litnet 43 - TO ? - TO ? BMC3 223.7856 (cid:55)
F Bellsouth 51 - TO ? - TO ? BMC2 173.6720 (cid:55)
F Bellsouth 51 - TO ? - TO ? BMC3 184.7136 (cid:55)
F BtLatinAmerica 51 - TO ? - TO ? - TO ?F BtLatinAmerica 51 - TO ? - TO ? BMC3 1346.7440 (cid:55)
F Garr201103 58 - TO ? - TO ? BMC2 164.2792 (cid:55)
F Garr201103 58 - TO ? - TO ? BMC3 89.1304 (cid:55)
F Forthnet 62 - TO ? - TO ? BMC2 1040.0800 (cid:55)
F Forthnet 62 - TO ? - TO ? BMC3 752.8008 (cid:55)
F Latnet 69 - TO ? - TO ? BMC2 209.1984 (cid:55)
F Latnet 69 - TO ? - TO ? BMC3 235.7168 (cid:55)
F Ulaknet 82 - TO ? - TO ? BMC2 1043.7440 (cid:55)(cid:55)